[Software Engineering] 보다 경험적인 Agile Scrum에 대하여

📕 목차

1. 개요
2. R&R
3. 백로그 관리
4. 스크럼 회의
5. 질문과 답변

---

1. 개요

 

💡 회사가 아닌 학부생 수준의 프로젝트에서 진행했기 때문에 참고로만 읽어주시면 감사드리겠습니다.

 

[Software Engineering] What is Agile Scrum

 

3학년 때 애자일이라는 방법론의 존재를 안 순간부터 항상 애자일스럽게 일한다는 건 무엇일까 고민을 했었다.

그래서 본격적으로 팀원을 구하고, 방학 동안 애자일에 대해 공부하여 현재 디자인팀 2명, 웹뷰팀 2명, iOS 개발팀 2명, 백엔드 개발팀 3명으로 구성된 프로젝트의 PM이자, Scrum Master의 직책을 가지게 되었다. (Backend도 한다.)

 

하지만 현실과 이상은 언제나 들어맞질 않는다.

개인 역량이 됐건, 개발팀의 역량이 됐건, 혹은 현실적인 자원의 문제가 되었건 완벽히 이상적인 애자일 방식을 준수한다는 것은 불가능하다는 것을 알게 되었다.

 

그래서 직접 교수님께 현재 진행 중인 방법에 대해 말씀드리고, 조언을 구하게 된 내용을 공유하고자 한다.

우선 이론적으로 정리한 내용이 아니라 실제로 우리 팀에서 진행하는 방법에 대해서 다시 서술하려 한다.

 

---

2. R&R

 

📌 제품 책임자 (PO)

• 비지니스 목표를 충족시키는 제품을 만들기 위한 제품 백로그 관리 및 Product 검토
• 제품 백로그(요구사항) 관리 및 설명
• 제품 백로그 우선순위 관리
• QA를 통해 개발 완성도 확인

 

📌 스크럼 마스터

• PO와 개발팀이 가치와 원칙으로 성공적 제품을 만들 수 있도록 돕는다.
• 팀 보호와 장애 요소 해결
• 일일 스크럼 회의 진행
• 모니터링 및 Tracking

 

📌 개발팀

• 최선의 기술로 백로그를 개발하여 고객을 만족시킨다.
• 스프린트 기간 동안 진행할 작업 할당량을 정한다.

 

---

3. 백로그 관리

 

 

 

📌 백로그 구성

💡 백로그는 총 3단계로 구성되어 있습니다.

1. 제품 요구 사항: Epic
2. Sprint Backlog를 위한 사용자 스토리
   • User Story: 사용자 관점에서 어떤 가치를 제공할 것인지
   • Feature: 사용자 관점이 아닌 인프라 작업 등의 개발 요구 사항
   • Error: 잘못된 작업에 대한 조치가 필요한 항목
   • Document: 개발과 무관한 문서 작업
3. 하위 작업 : Sub Task
   • 하나의 User Story를 완성하기 위한 세부 작업 단위
   • 각 개발팀별로 작성하며, 각각 하나의 PR이 된다.
   • 작은 PR 규칙을 준수하기 위해 작업을 세분화한다.

 

📌 제품 백로그

🟡 Epic

• PO가 결정하며, 해당 기능이 구현되어야 할 작업 기간을 명시한다.
• MVP(Minimum Viable Product, 최소 존속 가능 제품)을 따르며, 최소 기준에 부합한 경우 런칭한다.
  • v1.0 : 사용자 인증, 사용자 기본 기능, 지출 내역 관리 기능, (약식)백 오피스 기능
  • v2.0 : 채팅 서비스, 백 오피스 기능 강화
  • v3.0 : 피드 서비스, 백 오피스 기능 강화

 

🟡 User Stories for a Sprint

• 사용자 관점에서 어떠한 가치를 제공하는지 집중한다.
• PO는 해당 기능이 누구에게 무슨 가치를 제공하는지 개발팀에 충분히 이해시킨다.
  • As a <role> (who)
  • I want <goal> (what)
  • So that <benefit> (why)
• 해당 기능을 개발하는 개발자는 Value를 제공하기 위한 기술적 R&R을 갖는다.
  • 개발자는 who가 goal을 달성하여 benefit을 얻을 수 있도록 개발해야 한다.
• User Story를 완료시키기 위한 인수 기준을 명시한다.
  • given, when, then → TDD 기준

 

📌 스프린트 백로그

• PO는 우선 순위만 정하고, 작업할 양을 정하는 권리는 온전히 개발팀에 양도한다.
• 해당 스프린트에 포함된 작업 외의 요구사항은 스프린트 기간 동안 완전히 무시한다.

 

📌 스크럼 보드

• 각 개발팀에서 요구사항을 구현하기 위한 작업 단위를 결정한다.
• 작은 PR 단위를 따르며, 하루 이내에 작업 가능한 수준으로 나눈다.

 

---

4. 스크럼 회의

 

💡 현재 설정한 스프린트 단위는 주 5일입니다.
요구되는 기술 수준이 높아져 5일 내에 하나의 요구사항을 만족시키는 것도 어려워질 경우, 적응적으로 스프린트 기간을 변경합니다.

 

📌 스프린트 계획 회의 (매주 월요일 2시간)

🟡 회의 목적

• 스프린트 목표 정의: 왜 이 스프린트가 가치 있는가?
• 스프린트 완료(Done) 정의: 스프린트의 완료 기준은 무엇인가?
• 인수 기준 정의: 선정한 일은 어떻게 완료할 것인가?
• 스프린트 백로그 설정
• 데모 시연할 리스트 선정

 

🟡 진행 순서

1. PO가 이번 주 진행할 요구 사항을 설명한다. (User Story가 작업 단위)
2. PO가 요구 사항이 개발되어야 하는 이유와 완료 기준을 설명한다.
3. 개발팀이 스프린트 백로그를 결정한다.
4. 개발팀이 해당 요구사항을 구현하기 위한 Sub Task를 결정한다.
5. PO와 개발팀이 리뷰 회의에 데모 시연할 항목을 결정한다.

 

📌 데일리 스크럼 회의 (매주 화, 수, 목 15분)

🟡 회의 목적

• 매일 진행 상황과 문제 공유 (보고 X)
• 어제 한일, 발생한 이슈, 내일 진행할 일을 공유
• 장애 요소는 지속적으로 메모하여 관리
• 회의에 참여하는 누구나 동일한 규칙을 준수해야 한다.

 

🟡 진행 순서

1. 인원 별로 작업한 내용, 발생한 이슈, 진행할 작업을 이야기한다.
2. 발생한 이슈가 PO나 Scrum Master가 해결해주어야 할 일이라면, 메모한 후에 개선 방안을 고려하여 리뷰 회의에서 논의한다.

 

📌 스프린트 리뷰 회의 (매주 금요일 1시간)

🟡 회의 목적

• 각 스프린트의 목표 달성 정도를 확인한다.
• 스프린트 기간 동안 구현한 요구 사항에 대해 시연한다.
  • 시연할 내용은 회의 전에 PO와 이야기 하여 결정한다.
  • 시연할 결과물이 없다면 진행 중인 작업이라도 시연한다.
• 다음 스프린트에서 해야 할 일을 파악하고, PM은 필요 시 제품 백로그를 수정한다.

 

🟡 진행 순서

1. 스프린트 종료 및 격려
2. 각 스프린트 목표의 달성 정도를 확인한다.
3. 완료 스토리 데모 시연
   • 각 스토리 시연으로 진행
   • 스프린트 목표, 제품 변경, 테스트 시나리오 또는 사용자 환경을 나타내는 프로토타입에 대한 진행 상황 공유
   • 참석한 팀과 이해관계자는 질문 및 피드백을 제공하여 QA
4. 미완성 스토리 점검
   • 누락된 스프린트 목표와 완료되지 않은 스토리를 반영하여 향후 개선 사항 도출
   • 장애, 위험, 잘못된 가정, 우선 순위 변경, 부정확한 추정 또는 과도한 약속을 찾아내 원인 제거
   • 완료되지 않은 스프린트는 향후 스프린트에서 고려하도록 백로그로 이동
5. 필요 시 백로그 조정

 

📌 스프린트 회고 회의 (매주 금요일 1시간)

🟡 회의 목적

• 개발 기능과 무관한 스프린트 과정에 대해 리뷰
• 개선 방향을 스프린트 백로그에 반영
• 단계 설정
  • 우리가 어떻게 일해왔는지 이야기하는 시간을 갖는 이유는 우리가 어떻게 개선할 수 있는지 알아보기 위함이다.
  • 우리는 모두가 자신의 지식과 도구를 제공하기 위해 최선을 다했다는 것을 이해하고 참여한다.
  • 공유된 내용은 누구에게도 불리하게 작용하지 않는다.
  • 비난이 아닌 탐구를 위함이다.

 

🟡 진행 순서

1. 생각 정리 (15분)
   • 불필요한 전자기기 사용과 잡담을 금지한다. (가벼운 이야기는 가능)
   • 좋아하는 것, 원하는 것, 싫어하는 것, 배운 점을 기록한다.
   • 특정 누군가를 비난하는 것만 아니라면 그 어떤 내용도 자유롭게 작성할 수 있다. (사고의 자유를 막는 것을 방지하기 위해)
2. 생각 검토 (20분)
   • Scrum Mater가 작성한 내용을 차례로 읽는다.
   • 내용 중 공유가 필요한 내용은 작성자에게 자세한 설명을 요구한다.
   • 스프린트 개선을 위해 필요한 내용이라 판단되면 별도로 메모한다.
3. 행동 및 개선 방법 브레인 스토밍 (10~15분)
   • 생각 검토에서 도출한 메모를 어떻게 유지/개선할 지 논의한다.
4. 투표 및 토론 종료 (5~10분)
   • 행동 및 개선 방법에서 도출한 아이디어 중 의견이 여러 개라면 투표를 통해 다음 스프린트에 반영할 방법을 선정한다.
   • 사전에 Github Discussions에 게시된 논의 사항이 있다면, 해당 사항을 투표한다.

 

📌 디자인팀 별도 회의 (매주 금요일 1시간 이내)

이건 디자인팀이 있긴 하지만 스크럼 회의에 참가가 어려워 발생한 부가적인 회의에 해당한다.

 

---

5. 질문과 답변

 

• 작업 할당
• 격려 혹은 질책?
• 문서
• 디자인팀과 애자일
• 더 가치있는 리뷰 회의와 회고 회의를 위해서
• 진행 중인 스프린트 백로그의 수정 허용 범위

 

📌 작업 할당

🤔 Question

• 현재 진행 방식: PO가 제품 백로그 우선순위 지정, 개발팀이 스프린트 기간 내 작업할 양을 지정
• 만약, PO가 봤을 때 작업량이 너무 적어 데드라인 내에 요구사항이 완수되지 못 할 것 같다면, 개발팀에 추가 작업량을 요구하는 것은 월권이 되는 것입니까? (이때, 강제가 아니라 충분한 설득의 과정을 수반한다고 가정합니다.)

 

✒️ Answer

 

모든 PM의 고충이다.

충분히 협의가 된다면 추가 작업량을 요구하는 것 자체는 문제가 되지 않는다.

혹은 PM이 작업을 더 세분화하여 우선순위 별로 작업을 요구하는 것이 대안이 될 수 있다.

 

📌 격려 혹은 질책?

🤔 Question

• As-is: 애자일의 핵심 가치 중 하나인 “상호 존중”의 범위가 어디까지인지 궁금합니다. 팀원이 지속적으로 같은 실수를 반복하거나, 업무를 게을리 한다면 PO는 이를 독려하기 위해 고민해야 하는지, 해당 개발자를 질책해야 하는 것인지 모호합니다.
• 현직 개발자 분들은 PM은 개발자들에게 재촉하는 역할이기 때문에 질책하는 것이 맞다고 하지만, 한국의 기형적인 애자일보다는 진정한 애자일의 이념을 따랐을 때의 대처 방법이 궁금합니다.

 

✒️ Answer

사실 애자일에서 말하는 상호 존중은 개발팀 간의 상호존중이 아니다. 개발팀과 클라이언트 간의 상호존중이 원칙이다.
다만, 애자일을 하는 사람들이 개발팀 간에도 상호 존중하려고 노력하는 것이다.

PM과 개발팀이 서로를 존중할 수는 있지만 분명히 책임과 역할이 다른 것은 사실이다.
PM의 책임이 있기 때문에 반복된 실수를 하는 팀원을 지적하거나, 스프린트 자체의 문제점을 파악해서 개선하려는 행위는 잘못된 것이 아니다.

그게 PM의 역할이다.

✒️ 추가 답변

(교수님께서 무려 새벽 2시가 넘은 시간에 현직 개발자 분과 이야기 한 내용을 메일로 전해주셨다..)

고객과 개발조직간의 상호존중은 실무에서 원래 당연한 것이다.
따라서 Scrum에서 이야기하는 상호존중은 조직 내의 관점으로 보는 경향이 많다고 한다.

상호존중이란 서로 의견을 주고 받고, 도출한 아이디어에 대해 가장 좋은 결과물을 내기 위해 노력하는 등 서로의 능력을 믿고 개별 조직원들의 의견을 동등한 수준에서 검토하는 것을 말한다.
즉, 한두명이 의견을 내고 그것이 최적의 방안이니, 그것을 그대로 따라서 진행하는 등의 조직 구성원이 개인적인 의견을 내어도 무시하는 활동이 아니라는 의미다.
각 조직 구성원이 본인이 생각한 내용을 편하게 던질 수 있는 환경을 마련해주는 것이 중요하다.

하지만 SW 개발팀은 정해진 일정까지 최적의 결과물을 만들어 내야만 한다는 의무가 있다.
그러기 위해 상호존중은 최적의 결과물을 달성해내기 위한 수단이지, 목표가 될 이유는 없다.

상호 존중의 범위는 최적의 결과물을 만들어 내기 위한 분위기를 만들어주는 것이지, 개발자들에게 개발 목표 일정을 마음껏 늘려준다던가, 개발 목표를 축소시켜 주는 등의 의미가 아니다.
상호 존중하되, 이러한 분위기를 바탕으로 정해진 일정까지 최적의 결과물을 도출하도록 이끄는 것이 PM의 역할이다.

개발자들이 Sub Task를 정했다면, 그건 담당 개발자가 정해진 일정까지 무슨 짓을 해서라도 반드시 끝내야 한다.
즉, 이건 상호존중이고 뭐고 개발자 책임이 된다.
이런 부분은 질책이 필요하고, 질책하지 않으면 개발팀 전반적으로 영향을 미치게 된다.
따라서 이런 문제점에 대해 PM이 담당 개발자를 질책하는 것은 상호 존중과는 별개의 이야기이다.

현업에서도 며칠 기간을 연장해줄 수는 있어도, 다음 작업이 시작되는 시점이 이미 픽스되었다면 그 전까지는 무조건 끝내는 쪽으로 가이드 한다고 한다.

물론 이는 원론적인 이야기이고, 학생들끼리 하는 프로젝트에서 이렇게 빡빡하게 일정을 강요하기는 어려울 것이다. 적당한 선에서 PM이 결정하여 운용하면 된다.
프로젝트가 잘 되면 PM은 참여한 팀원들에게 공을 주어 칭찬해주어야 하지만, 프로젝트가 잘못되면 모든 책임을 덮어쓰고 가는 어려운 직책이다.

 

📌 문서

🤔 Question

• As-is: 애자일의 핵심 이념 중 하나가 문서에서 벗어나는 것이라 배웠지만, 현실적으로 완전히 제거하는 것은 불가능하다고 생각합니다. 반드시 유지보수 되어야하는 문서가 있다는 것을 알게 되었기 때문입니다.
• To-be: 우선 순위가 높은 요구 사항만 우선적으로 Usecase 문서와 Sequence Diagram을 작업하고, 개발이 진행됨에 따라 개발팀 혹은 디자인팀과 이야기하여 지속적으로 문서를 수정하는 방식을 채택 중입니다.
  • 시간 관계상 클래스 다이어그램과 같은 부분은 각 팀에서 그릴 것을 요구하고 있습니다.
  • PO는 아키텍처나 함수를 제시해주는 정도의 역할을 수행합니다.
• 이 방식이 애자일의 “변화에 빠르게 대응하자”라는 취지에 맞는 행동인지, 혹은 단순히 프로젝트가 중심을 잃고 방황하고 있는 것인지 궁금합니다.
• 또한 아무리 애자일이라 하더라도 반드시 작성되어야 할 문서가 존재한다는 제 생각이 틀린 것인지 궁금합니다.
  • 개인적 소견: 모든 기능을 분석하고 문서를 작성하는 것은 애자일이 아니지만, 개발이 진행되어야 할 기능에 대해서는 문서가 작성되어야 한다. 단, 적응적으로 수정될 수 있어야 하며, 문서 중심이 아니라 요구 사항의 변경에 맞게 문서가 수정될 수 있어야 한다.

 

✒️ Answer

애자일을 도입하려는 사람들 의도가 대부분 문서 쓰기 싫어서..
이론 상으로는 제품 백로그와 스프린트 백로그, 그리고 회의하면서 정리한 문서들만 관리하면 된다.
Usecase 문서와 Sequence 다이어그램 문서 같은 것들은 그저 옵션일 뿐이다.

하지만 실제로 해보니 문서의 중요성을 오히려 더 알게 되었을 것이다.
지금처럼 진행하면 된다.

다만 문서 중심으로 작업이 진행되는 것에 주의해야 한다.

 

📌 디자인팀과 애자일

🤔 Question

• As-is: 디자인팀은 해당 팀의 일정으로 인해 애자일과는 거리가 먼 방식을 채택하고 있습니다. 요구 사항이 완료되기 전에 이미 와이어프레임이 완성된 상태이며, 현재는 별도 정기 회의를 통해 지속적으로 디자인이 요구 사항을 반영하고 있는지 확인하는 기형적인 사이클을 이루고 있습니다.
• To-be: 임시방편 대안책
  • 디자인팀은 사전에 제공한 IA(정보구조도) 기반으로 별도 사이클로 디자인 시작.
  • 매주 금요일마다 PO와 회의를 통해 요구사항이 반영되어 있는지 검토.
• 이러한 차선책이 효율적인지, 혹은 더 나은 방법이 있을 지 궁금합니다.
• 추가적으로 온전히 디자인팀까지 애자일 사이클 내로 흡수했을 경우가 궁금합니다.
  • 프론트팀 개발은 디자인팀의 작업이 끝나야 작업이 진행될 수 있는데, 그러면 작업이 딜레이 되지 않을지?
  • 혹은 디자인팀의 “디자인 씽킹”과 개발팀의 “애자일”이 조화를 이루도록 하는 방법을 채택하게 되는 것인지? (정답이 없음을 알지만, 기존의 애자일 방식이 디자인팀의 사이클까지 품을 수 있는 것인지 궁금합니다.)

 

✒️ Answer


실제로 저 방식으로 진행하는 경우는 보지 못했다. (지금은 하는 곳이 있을 수도 있겠지만)
이렇게 독자적인 사이클을 가지고 있으면, 과연 작업이 원활하게 진행될 수 있을까?

일반적인 방식은 디자인 팀도 회의에 같이 참여하도록 하는 것이다.
디자인팀이 개발을 알지 못 하지만, 주워듣는 것들을 통해서 UI에 반영하기도 한다.
그리고 작업 상황을 함께 공유하면서 빠르게 변경 사항에 대응할 수 있다는 이점도 있다.

일단 가장 중요한 것은 개발 전에는 UI가 존재해야 한다는 것.
UI 변경 사항은 계속해서 일어나기 때문에 어쩔 수 없는 영역이다.

 

📌 더 가치있는 리뷰 회의와 회고 회의를 위해서

 

🤔 Question

• 리뷰 회의에서 백엔드 팀이 테스트 케이스의 성공 여부를 시연하는 것도 의미가 있는 시간인지 궁금합니다. (API 테스트 정도는 유의미한 시간을 도출할 수 있을 거 같습니다.)
• 회고 회의에서는 기능과 관련된 내용만 아니라면 무엇이든 자유롭게 작성할 수 있도록 허용하고 있습니다. 제한 사항이 많아질 수록 오히려 사고가 한 번 더 단계를 거치게 되어, 의미있는 결과를 도출할 수 없다고 생각하기 때문입니다. 이러한 판단이 옳은 것인지, 혹은 너무 스프린트와 무관한 내용은 작성하지 않도록 하는 것이 옳은지 궁금합니다.

 

✒️ Answer

그러면 지금 백엔드 팀은 리뷰 회의에서 무엇을 하는가?
(나: 하는 게 없어서 좀 더 가치있는 시간이 되도록 하고 싶은데, 그러면 API 테스트라도 하는 것이 맞을지? 성공한 케이스보다 예외적인 케이스인 에러 응답 등을 이야기 해주는 시간을 가지려 한다.)

선택 사항이긴 하지만 종종 백엔드 개발자도 뭐라도 하려고 리뷰 회의에서 테스트 케이스를 보여주는 경우가 있다.
본인이 말한 것처럼 복잡한 API의 경우에는 테스트 케이스를 시연해주는 게 의미있는 시간이 될 수 있을 것이다.

일반적으로도 회고 회의를 자유로운 분위기에서 진행한다.
다만 나중에 다시 확인하는 경우가 있을 수 있으므로, 스프린트와 관련된 회고 내용은 컬러를 주던지 굵기를 조정해서 강조해두는 게 좋다.

 

📌 진행 중인 스프린트 백로그의 수정 허용 범위

🤔 Question

• As-is
  • 애자일 스크럼 방식은 모두가 처음이기 때문에 계획 회의에 논의한 스프린트 백로그가 수정되는 경우가 빈번히 발생할 수 있음을 인지하고 있습니다.
  • 현재는 제품 백로그 단위의 작업이 추가되어야 한다면 다음 스프린트에 반영하고, Sub Task 수준의 작업이 추가되어야 하는 경우엔 PO에게 이야기한 후 Backlog에 반영하는 것은 허용하고 있습니다.
  • 하지만 이를 무한정 허용하면 초기 스프린트 목표 성과치가 예측 불가능해지며, 작업이 지연된다는 문제를 가집니다.
• To-be
  • 현재 채택하는 방식은 서로가 미숙하다는 점을 인정하고, 성과치 달성보다는 스크럼 방법론 자체에 적응하는 단계로써 되도록 Sub Task를 제한없이 수정할 수 있음을 허용하고 있습니다.
  • 경험을 쌓으며 점차 오차 범위를 줄여가는 지금의 방식이 적절한지, 혹은 더 나은 대안 전략이 있을지 궁금합니다.

 

✒️ Answer

원래 스크럼의 기본 전제는 개발팀에서 Sub Task를 시작부터 잘 계획한다는 것으로 둔다.
그렇기 때문에 이것에 대한 대안책은 존재하지 않는다. 그저 스크럼을 잘 다루지 못 하는 것이다.

하지만 경험치가 적은 상태고, 현재 공부하는 단계이기 때문에 어쩔 수 없는 현상이기도 하다.
Sub Task를 막아두면 너무 빡빡하지 않겠나? 지금처럼 하는 게 최선일 듯 하다.

다만 계획 회의 단계에서 Sub Task를 나눌 때 PM으로서 “좀 더 Sub Task를 나눌 수 있지 않겠나?”라는 질문 등을 해주면 좀 더 개선될 수 있을 것이다.

(나: 현재 하루에 끝낼 수 있는 작업량을 기준으로 잡되, 개발자마다 역량이 다르기 때문에 작은 PR 규칙에 기반하여 Sub Task를 정하는데 별도의 기준이 더 있는가?)
일반적으로 하루에 끝낼 수 있는 작업량으로 잡는 게 맞다. 그 외에 별도의 기준은 스크럼에서 따로 존재하지 않는다.
지금 하는 방식대로 하면 된다.

 

📌 추가 조언

원래 PM은 개발을 하면 안 된다.

전체를 봐야 하는데, 하나에 몰입하면 바빠져서 전체를 관리하지 못 하게 된다.

PM은 기본적으로 편해야 한다.

 

(이건 현직자 분께도 들었던 이야기지만, 나는 학생이라 당연히 개발 공부를 해야 하는 현실적인 문제로 지킬 수 없는 분야이다.)