1. 애자일 방법론이란?
- 애자일 방법론 : 미리 모든 것을 계획하고 개발을 시작하는 전통적 개발 방법론(Waterfall)과 다르게, 최소 기능 제품을 빠르게 개발하여 유저들의 피드백을 받고, 해당 피드백을 바탕으로 지속적으로 개선해나가는 개발 방법론
< 장점 >
- 잘못된 제품을 개발하는데 사용하는 시간을 최소화 할 수 있음
- 더 자주 유저의 피드백을 얻을 수 있기 때문에, 실패할 확률을 낮출 수 있음
- 계획 혹은 기능에 대한 수정과 변경에 유연하게 대처할 수 있음
- 요즘 시장상황이 매일매일 급격하게 변하고 유저들의 취향들도 계속적으로 변화하고 있음
- 제품을 개발하는 동안 훨씬 훌륭한 제품이 갑자기 시장에 출시될 수도 있음
- 이러한 상황 속에서 애자일 방법론을 통해 계획 혹은 기능에 대한 수정과 변경에 유연하게 대처한다면 충분히 낭비와 실패에 대한 확률을 줄이면서 제품 개발을 할 수 있음
< 단점 >
- 요구사항이 명확할 경우, 오히려 속도가 늦춰질 수 있음
- 최종 제품이 요구사항과 달라질 수 있음
- 고객에게 제공하는 가치에 집중하기 때문에, 기술적 완성도가 떨어질 수 있음
2. 애자일에서의 일을 쪼개는 단위
- 애자일에서 일을 쪼개는 단위 : Theme → Epic → Story → Task
1) Theme
- Epic들이 모여서 Theme를 이루게 됨
- 유저는 배달 음식점의 메뉴를 다양한 방식으로 조회할 수 있다, 유저는 다양한 결제 수단을 통해서 배달음식을 모바일 주문할 수 있다.. 등등의 Epic이 모이면 모바일 배달음식 플랫폼이라는 거대한 테마를 이루게 됨
- ex. 모바일 배달음식 플랫폼
2) Epic
- Epic은 서사 또는 장편 서사 영화 또는 서사 시 등을 표현하는 영어 단어임
- 하나의 서사 시가 다양한 이야기들로 구성되듯이 다양한 유저 Story들이 모여서 큰 Epic을 구성함
- ex. “고객은 배달 음식점의 리뷰를 본인에 맞춰 개인화하여 확인할 수 있다.”
3) Story
- 애자일에서는 유저에게 제공할 가치 기반으로 기능을 개발하고 해당 기능을 배포해서 유저에게 피드백을 얻는 것이 중요하기 때문에 유저에게 제공할 수 있는 가치 기반으로 일을 쪼갬
- 고객의 행동을 나타내야 하기 때문에 고객이 주어가 되는 유저 중심으로 서술함
- 애자일 방법론은 일의 기본 단위가 기능이 아니라 사용자의 경험임
- 이러한 Story가 모여서 고객을 만족시키는 큰 Story가 되고 이를 Epic이라고 부름
- ex. “고객은 배달음식점의 사진리뷰만 모아 볼 수 있다.”
4) Task
- Story를 가능하게 하기 위해서 직접 수행해야 하는 업무
- Task를 기반으로 실제 일을 진행함
- 애자일 프로덕트팀은 매일 각 Task가 어떻게 진행되고 있고 그 Task를 완료하는데 있어서 어려움은 없는지 어떠한 도움이 필요한지 등을 서로 논의하면서 제품, 개발, 회의를 진행함
- Task가 더 작은 Task들로 쪼개야 하는 필요성이 있을 경우에는 Task를 sub Task 단위로 쪼개기도 함
- ex. 사진리뷰 필터 구현
< PO의 역할 >
- 특정 기간 동안 어떠한 Story를 개발할 것인지를 정하기
- 해당 Story를 완성하기 위해 필요한 작업을 파악하여 Task를 생성하고 담당 개발자들에게 할당하기
- 정기적인 미팅을 통해 각 Task들의 진행상황을 지속적으로 파악하기
- Task를 완료 상태로 만들어 하나의 유저 Story로 완성하기
- 이 유저 Story를 유저에게 배포하기
- 유저 Story가 실제 유저에게 배포된 후에 유저에게 어떤 가치를 줬는지 실제로 제품은 얼만큼 좋아졌고 수치들은 얼마만큼 개선됐는지를 파악해서 개발팀에게 공유하기
- 위와 같은 과정들 지속적으로 반복됨
< 작성 예시 >
3. 스크럼이란?
- 스크럼 : 1995년 Ken Schwaber와 Jeff Sutherland가 착안한 소프트웨어 개발 방법론
- 전통적인 소프트웨어 개발 방법론과는 달리 애자일 방법론에서는 각 반복 주기가 종료될 때마다 부분적으로 완성된 결과물들이 만들어지고 이를 통해서 유저에게 가치가 전달됨
- 애자일에서는 이 반복 주기를 Iteration이라고 하고, 스크럼에서는 Sprint라고 부름
- 스크럼은 이 스프린트를 반복적으로 진행하면서 제품을 개발해 나가는 방법론임
- 스크럼은 관리 도구가 아니라 진행 도구임
- 데드라인에 맞춰서 프로젝트를 순차적으로 진행하는 워터폴 방식에서는 관리자가 주어진 일을 개별 팀원들에게 나눠서 최대한 효율적으로 진행되기 위해서 지속적으로 관리할 수 있는 관리 도구가 필요함
- 반면에 애자일 방식의 도구들은 팀 전체가 협동해서 일정한 속도로 지속적으로 유저에게 가치를 전달해 나가고 그를 통해 피드백을 받는 것이 매우 중요하기 때문에 관리 도구 보다는 진행 도구의 관점으로 방법론들이 개발되어 옴
- 스크럼의 어원 : 스크롬은 럭비 용어로서 각 단계별로 한 작업을 마친 후 다음으로 전달하는 전통적 개발 방법론에 비해서, 모든 팀원들이 한 덩어리로 뭉쳐서 서로 공을 주거니 받거니 하며 함께 밀고나가는 럭비 경기와 같은 형태가 바람직하다고 느껴서 사용하게 됨
< 스크럼 활용시점 >
- y축 : 요구사항을 명확하게 아는 정도
- x축 : 어떻게 어떤 기술을 사용해서 구현할지 아는 정도
- (0, 0) : 워터폴 방식 (요구사항, 기술 명확)
- (0.5, 0) / (0, 0.5) : 워터폴, 애자일
- (0.5, 0.5) : 스크럼
- (1, 1) : 칸반 방법론
4. 스크럼의 과정
1) 프로덕트 백로그 관리
< Product Backlog란? >
- 제품 개선을 위해 진행되어야 할 다양한 요구사항
- 제품 관련 다양한 인원들로부터 수집
- 사업개발팀, 고객관리팀, 운영팀, 개발팀, QA팀
- 요청자, 백로그 생성 이유, 추정시간, 요구명세 등 다양한 내용을 포함
- 필수작성조건이 자세하면 좋지만 너무 많아지면 다양한 인원들로부터 쉽게 의견을 얻을 수 없게 되므로 부담감은 줄이되 필요사항은 최대한 받을 수 있는 방식으로 구성하는 것이 좋음
- 우선순위는 반드시 포함
- PO는 지속적으로 다양한 백로그를 관리하면서 시장 상황, 팀 상황, 비즈니스 중요도를 고려해서 백로그의 우선순위들을 관리해 나가야 함
< Product Backlog 작성법 >
- 요구사항을 작성하되 구체적인 실행방안에 대해서는 작성하지 않아도 됨
- 백로그는 현재 유저가 겪고 있는 문제점, 문제점을 해결할 수 있는 가설 정도로 작성하면 됨
- 실행방안은 프로덕트팀이 직접 솔루션을 찾아내는 것이 효율적임
- 백로그 진행이 중요한 이유에 대해서 자세히 작성할수록 우선순위 산정 및 제품 개발에 용이함
< 프로덕트 백로그 우선순위 설정법 >
- 비즈니스, 테크적 중요도를 파악해서 각 백로그 별 우선순위를 정해야 함
- 우선순위가 높은 백로그일수록 최대한 구체화하고 더 작은 단위로 쪼개서 당장 다음 스프린트에서도 개발이 진행 가능한 상태로 만들어둬야 함
- 우선순위가 낮은 백로그일수록 큰 단위임 (ex. epic)
- 좋은 PO는 회사에 가장 도움이 되는 방향으로 프로덕트 백로그의 우선순위를 설정할 수 있어야 함
- 우선순위가 설정된 이유에 대해서 프로덕트팀, 외부 팀원들에게 논리적으로 설명할 수 있어야 함
2) 스프린트 플래닝 미팅 & 3) 스프린트 백로그 선정
- Sprint란?
- 통상 1~4주 정도의 Time box 성격을 가진 개발주기
- 각 Sprint 단계 종료 시 새로운 기능이 추가되어 제품에 반영되는 것을 목표로 함
- Scrum은 Sprint를 반복하며 제품을 개발 및 개선해 나가는 과정
- Sprint Planning Meeting이란?
- Backlog들 중에 이번 스프린트에 어떠한 백로그를 진행할지 모든 팀원들이 함께 논의하는 회의
- PO는 독단적으로 목표를 설정해서는 안됨
- Sprint Planning Meeting을 통해서 Sprint Backlog를 선정
- 보통 Sprint Backlog는 일단 Sprint가 시작된 이후에는 변경하지 않는 것을 원칙으로 함
- 중요도, 수행가능성, 일의 크기 등을 종합적으로 판단해서 팀원들이 깊이있게 토의하는 것이 중요함
4) 스프린트
- 스프린트 진행은 스크럼 마스터가 주도적으로 운영하는 역할을 하고 있음
- 스크럼 마스터의 역할
- Sprint의 진행상황을 검토하고, 목표 달성에 위협이 되는 사항들을 확인하여 해결하는 역할
- 팀원들 간 커뮤니케이션 이슈, 예상보다 어려운 개발 난이도, 개발하면서 발견된 기획의 빈틈, 갑작스러운 팀원의 건강상의 이슈 등 모든 문제들을 조정하는 역할
- 이러한 역할을 수행하려면 Servant Leadership(섬기는 리더십)이 필요함 ⇒ 경청, 공감, 치유하면서 서포트
- 보통 Scrum Master를 따로 두고 있는 기업은 드물고, PO 또는 PM이 이 역할을 병행
5) 스프린트가 진행되는 도중에 매일 진행되는 데일리 스크럼
- Daily Scrum Meeting
- 날마다 약 15분씩 진행되는 짧은 미팅
- 일일 스크럼을 통해 스프린트가 목표에 맞게 진행이 되고 있는지, 또 스프린트 백로그에 있는 작업이 잘 완성되고 있는지 검토
- 일일 스크럼은 개발팀이 스프린트 목표를 달성할 수 있는 확률을 최적화함
- 데일리 스크럼은 보고를 위한 자리가 아닌 목표 달성 확률을 최적화하기 위해 팀원들에게 공유하고 팀원들의 도움이 필요할 경우에는 빠르게 요청할 수 있는 자리임
- 전체 개발팀이나 팀원들은 종종 일일 스크럼 미팅이 끝나자마자 더 상세한 의논을 하거나 스프린트 작업에 대한 조정 및 재계획을 하기 위하여 추가적인 미팅을 할 수 있음
- 스크럼에서 주요 확인 사항
- 나는 어제 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 했는지?
- 나는 오늘 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 할 것인지?
- 나 혹은 개발팀이 스프린트 목표 달성을 하는데 방해요소가 있는지?
6) 스프린트 리뷰
- Sprint를 통해 무엇이 완료되었는지를 팀원과 이해관계자들이 모여 확인
- 리뷰 결과와 스프린트 수행 중 변경된 백로그를 고려하여 다음에 무엇을 할지 함께 의논
- 경과보고를 위한 미팅이 아닌, 스프린트를 통해 완료된 개선사항을 발표함으로써 피드백을 받고 협력을 촉진하기 위한 회의
- PO는 스프린트 리뷰가 진행되는 동안 팀원들이 해낸 사항들에 있어서 가장 쉽고 명확하게 전달할 수 있는 것이 중요함
- 팀이 해결한 문제가 얼마나 중요한 문제였고 이를 통해 어떤 성과를 얻었고 향후에 어떤 성과를 얻어 나갈 것인지에 대해서 명확하게 설명하여 팀원들의 사기를 진작시킬 수 있어야 함
- 피드백을 받은 후에는 이 피드백들을 논리적으로 정리하고 이를 바탕으로 액션 아이템들을 뽑아낼 수 있는 능력을 갖춰야 함
7) 스프린트 회고
- 스프린트 회고 미팅은 팀이 다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 기회를 제공
- 스프린트 리뷰 미팅 후 / 스프린트 플래닝 미팅 전에 수행함
- 스프린트 리뷰와 회고 세션을 따로 두는 이유는 회고가 스크럼팀의 유기적 협업과 효율성 극대화에 도움이 되기 때문
- 회고 세션을 통해 팀원이 개인 성과주의에서 벗어나 팀 전체 목표를 향해서 팀원으로서 수행해야 할 업무들, 팀 자체가 변경되어야 할 사항들에 대해서 심도깊게 논의하는 자리를 가짐으로써 팀워크와 생산성을 높일 수 있음
< 회고의 목적 >
- 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토
- 잘 된 것들과 개선의 여지가 있는 항목을 알아내고 우선순위 설정
- 개선을 실천할 수 있도록 계획 수립
< 회고 방법론 예시 >
- KPT 회고 방법론
- KPT 방법론은 3가지 부분에서 팀원들이 고민할 수 있는 기회를 제공함 ⇒ 좋았던 부분, 안 좋았던 부분(문제점이라고 생각하는 부분), 시도해볼 수 있는 부분
- PO는 팀원들이 포스트잇에 Keep, Problem에 대해 관한 내용을 충분히 고민해보도록 해서 최대한 많은 양의 피드백이 나올 수 있도록 독려해야 함
- 많은 이야기를 나눌수록 회고가 깊이 진행되고 이를 통해 발견되는 해결책 또한 가치가 높아지기 때문임
- 각자 작성한 Keep, Problem 내용을 팀원들에게 공유한 후 Try를 작성함
- Try는 구체적이고 실행 가능해야 함
- 모두가 각자 작성한 Try를 공유하고 PO는 각 Try를 동일한 내용끼리 그룹화하는 작업을 진행해야 함
- 이후 팀원들과 이야기를 나누면서 Try별 우선순위를 정해야 함
'ACTIVITY > PM 스쿨 일지' 카테고리의 다른 글
| Chap 08. 서비스 기획 업무 A~Z (4) MVP, 와이어프레임, 프로토타입 (0) | 2023.10.18 |
|---|---|
| Chap 08. 서비스 기획 업무 A~Z (3) 애자일 방법론 中 칸반 (0) | 2023.10.18 |
| Chap 08. 서비스 기획 업무 A~Z (1) 린캔버스 (0) | 2023.10.18 |
| Chap 05. 그로스 해킹 (0) | 2023.10.09 |
| Chap 02. 서비스 기획자, PM, PO는 왜 필요한가 (0) | 2023.10.09 |