스크럼(Scrum)
관리도구가 아닌 진행도구!
어원- 럭비용어, 모든 팀원들이 한 덩어리로 뭉쳐서 서로 공을 주거나 받거나 하며 함께 밀고 나가는 럭비 경기와 같은 형태가 바람직하다고 느껴 스크럼이라는 용어가 쓰이게 됨 각 반복 주기가 종료될 때마다 부분적으로 완성된 결과물이 만들어지고 유저에게 가치가 전달된다.
이 반복 주기를 스프린트라고 한다. (애자일에서는 이터레이션) (애자일 활용시점)
- not fully knowable but reasonably predictable, the unknown unknowns : Unknow Unknowns (알려지지 않은 불확실한 일)
-Neither requirements nor the execution are clear
무엇을 할지 명확하다면 워터폴 방법이 더 유용하다.
스크럼 과정 정리!
프로덕트 백로그 관리 - 스프린트 플래닝 미팅 - 백로그 선정 - 스프린트 - 데일리스크럼 - 리뷰 및 회고
1)스프린트 시작하기 전 프로세스
프로덕트 백로그 관리 (by PO)
product backlog란?
-제품 개선을 위해 진행되어야 할 다양한 요구사항
-관련한 다양한 인원들로부터 수집
-요청자, 백로그 생성 이유, 추정시간, 요구명세 등 다양한 내용 포함
-우선순위는 반드시 포함
작성방법?
요구사항을 작성하되, 구체적 실행방안에 대해서는 작성하지 않아도 된다.
백로그 진행이 중요한 이유에 대해서 자세히 작성할 수록 우선 순위 산정 및 제품 개발에 용이하다.
우선순위 설정
비즈니스, 테크적 중요도를 파악해 각 백로그 별 우선순위를 정해야 한다.
우선순위가 높을수록 최대한 구체화, 세분화해서(story) 다음 스프린트에서 개발 진행 가능한 상황으로 만들어 둬야 한다.
우선순위가 설정된 이유에 대해 프로덕트팀이나 이해관계자들에게 논리적 설명이 가능해야 한다.
스프린트 플래닝 미팅 > 스프린트 백로그 선정 (by Team)
스프린트란?
-통상 1~4주정도 타임 박스 성격을 가진 개발주기(팀의 생산성에 따라 기간 변경)
-각 스프린트 단계 종료 시 새로운 기능이 추가되어 제품에 반영되는 것을 목표로 함
-스크럼은 스프린트를 반복하며 제품을 개발 및 개선해 나가는 과정
-명확한 기간, 목표를 이루기 위한 노력 등이 달리기의 스프린트와 닮아서 용어 사용
스프린트 플래닝 미팅이란?
-백로그를 통해 이번 스프린트에 어떤 백로그를 진행할 지 모든 팀원들이 함께 논의하는 자리 (프로덕트 백로그 중 미팅을 통해 스프린트 백로그를 선정하는 것)
-독단적으로 목표 설정해서는 안된다. 달성 가능하면서 생산성을 효율적으로 이용할 수 있는 적절한 백로그 선정하여 스프린트 백로그로 지정하는 것 중요
-보통 스프린트 백로그는 일단 스프린트가 시작된 이후에는 변경하지 않는 것을 원칙으로 한다.
-중요도,수행 가능성,일의 크기 등을 종합적으로 판단해서 팀원들이 함께 깊이있게 토론
2) 스프린트 스프린트 진행 (By Scrum master) - 모든 스프린트 백로그 처리, 배포까지 포함
-PO는 진행 상황 검토, 목표 달성 위협하는 사항들을 확인해 해결하는 역할
-커뮤니케이션 이슈, 우선순위 선정에 대한 이견 등 모든 문제들을 조정하는 역할
-보통 스크럼 마스터를 따로 두고 있는 기업은 드물고, po 또는 pm이 역할을 병행
-‘서번트 리더십’이 필수적이다!
경청, 공감, 치유(문제 해결) 일일 스크럼 Daily scrum meeting (By Team)
-날마다 약 15분씩 진행되는 짧은 미팅 (길어지지 않게 주의, 일할 수 있는 시간 뺏지말기)
-일일 스크럼을 통해 스프린트가 목표에 맞게 진행되고 있는지, 스프린트 백로그 작업이 잘 수행되고 있는지 검토
-개발팀이 스프린트 목표를 달성할 수 있는 확률 최적화가 목표
-전체 개발팀이나 팀원들은 종종 데일리 스크럼 미팅이 끝나자마자 더 상세한 의논을 하거나 스프린트 작업에 대한 조정 및 재계획을 하기 위해 추가 미팅을 할 수 있다. (필요사항 관련 인원만)
-보고가 아닌 공유와 협업 요청이 목적
주요 확인사항
-나는 어제 하루 동안 스프린트 목표 달성을 위해 무엇을 했는지
-나는 오늘 스프린트 목표 달성을 위해 무엇을 할 것인지
-나 또는 개발팀에 스프린트 목표 달성 방해 요소가 있는지
3)스프린트 후 프로세스
리뷰와 회고 (by team)
리뷰
-스프린트를 통해 무엇이 완료되었는지 팀원과 이해관계자들이 모여 확인
-누구나 이해할 수 있게 쉽게 설명, 유저에게 제공될 수 있는 결과값 데모, 시연
-리뷰 결과와 스프린트 수행 중 변경된 백로그를 고려해 다음에 무엇을 할지 함께 의논
-경과 보고를 위한 미팅이 아닌, 스프린트를 통해 완료된 개선사항을 발표함으로써 피드백을 받고 협력을 촉진하기 위한 회의, 최대한 많은 피드백 받는 것이 좋다.
팀원들이 해낸 사항들을 가장 쉽고 명확하게 전달할 수 있는 것이 중요하다.
어떤 문제를 어떻게 해냈고 향후 어떻게 해나갈 지!
피드백을 통한 액션 아이템 도출
회고
-스프린트 회고 미팅은 팀이 다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 기회를 제공
-스프린트 리뷰 미팅 후 / 스프린트 플래닝 미팅 전에 수행함
회고의 목적?
지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토
잘된 것들과 개선 여지가 있는 항목을 알아내고 우선순위 설정
개선을 실천할 수 있도록 계획 수립
회고 방법론
-KPT (Keep Problem Try)
화이트보드에 각 영역을 나눠서 적기
유지했으면 하는 점, 개선되어야 할 점, 문제를 해결할 수 있도록 실천할 수 있는 점
팀원들에게 충분히 고민할 시간을 주고 많은 포스트잇이 붙을 수 있도록 하기
PO가 먼저 다양한 의견 개진하면서 팀원들 독려 ***try는 구체적이고 실행 가능해야 한다. > 정리된 try에서 우선순위 정해서 다음 스프린트 때 실행, 수행되고 있는지 공유
ex) 기획자가 개발 진행 전에 기획문서를 디자이너와 개발자에게 기획서를 충분히 리뷰 받는 프로세스를 만들어보자
칸반
칸반의 유래
간판을 뜻하는 일본어 칸반에서 유래.
도요타 자동차 생산 관리 시스템에서 사용된 칸반에서 유래했는데, 생산 도중 추가로 부품이 필요할 때 이 카드(물리적 주문서)를 작성해 전 단계로 보내면 카드에 적혀진 만큼만 전단계 부품을 생산했음
->적시 생산방식 (just in time), 재고 최소화
세탁기가 대형에 좋은 성능이라도 건조기의 성능이 부족하면 젖은 빨래만 더 생산된다.
젖은 빨래는 원래 빨래보다 처리가 어려워지기 때문에 일을 안하는 것이 더 나은 상태가 됨.(악성재고)
세탁기 성능을 일부만 사용하더라도, 작업량을 제한해 최적의 양만 세탁을 하거나 건조기의 성능을 늘려야 한다.
이것을 소프트웨어 개발 방법론에 사용한 것이 바로 칸반 개발 방법론!
특정 단계 작업이 완료됐을 때 전 단계 작업을 끌어당기며(pull signal) done 상태의 작업을 최대한 빨리 많이 만들어 유저에게 가치 제공
칸반 실천법
1.시각화
-칸반 보드는 시작, 끝 지점이 열로 나눠져 왼쪽부터 오른쪽으로 흘러가도록 구성
끝 지점에 작업 내용이 유저에게 전달, 의미 있는 가치로서 제공되어야 한다.
-카드는 작업 단위(story,tesk,sub tesk), 카드가 속해있는 열은 해당 카드의 프로세스 단계를 나타냄 / 행으로 자르기도 하는데 스윔레인, 각 업무 담당자가 나누기도 함(이해 어려웅…)
-각 단계 사이 진행 중 업무 WIP 제한이 표기되어 있어야 함
-어떤 열에서 다음 열로 옮기기 전에 완료되어야 하는 일이 무엇인지 명확히 정책을 만들어 둬야 한다.
2.진행 중 업무를 제한(WIP)
-WIP제한으로 인해 Push 가 아닌 Pull 형으로 업무방식이 변경됨
-하나의 열에 제한 기준 만큼의 카드가 있을 경우 카드를 완료하여 다음 단계로 보내기 전까지 새로운 카드를 당겨올 수 없게 됨.
-이를 통해 부분적으로 완료한 업무가 많아져 발생하는 (젖은빨래) 낭비를 줄이고 완성된 제품을 배포할 때까지의 리드타임을 줄여 더 자주 고객에게 배포하고 피드백을 얻을 수 있게 됨
[추천 저서: 컨그루언트 애자일 조승빈 대표님]
3.흐름 관리
-업무 흐름이 완성된 가치 생산(건조된 빨래)을 최대화하도록 지속적으로 관리함
-완성 제품이 생산될 때까지의 리드타임을 줄이고 가능하면 예측 가능해야 함
-특정 업무가 전체 흐름을 막고 있을 경우(낮은 성능의 건조대) 해당 업무를 개선해 흐름을 개선해야 한다.(세탁소 직원들이 모여서 논의해 개선 방향 결정)
4.정책을 명시화
-정책을 명시화해 모든 구성원이 동일한 방식으로 일하는 것이 중요하다.
-다만, 해당 정책은 토론을 통해 언제든지 변경 가능해야 지속적으로 개선되는 칸반 실천을 할 수 있다.
-WIP의 제한, 각 열의 완료의 정의 또한 정책 중 하나이다. 변경 가능하다.
5.피트백 루프 실행
-지속적으로 리뷰 세선을 거쳐서 칸반을 우리 팀에 맞추고 칸반 시스템이 제대로 활용되도록 개선하기 위한 리뷰를 진행하라.
-전략, 운영, 위험, 서비스 제공, 재보충, 칸반, 제공 계획의 7가지 리뷰 제안
전략리뷰: 프로젝트 전략 관련 리뷰, 지속적으로 외내부 상황 등을 파악해 옳은 프로덕트 만들고 있는지 확인하며 체크, 분기별 확인
위험리뷰: 칸반을 진행하며 특정 워크 프로세스가 흐름을 막고 있다면 이유가 무엇인지 파악하고 개선해 나가기 위해 진행되는 회의, 먼슬리 권장
재보충 회의: 신규 업무를 to do 에 넣어서 칸반보드에서 작업을 진행할지 팀원들과 함께 고민하여 넣어가는 회의, 스프린트 플래닝 미팅과 거의 동일, 위클리 권장
칸반 미팅: 데일리 스크럼과 거의 동일, 매일 완료된 업무와 함께 어떤 열에서 병목 현상이 발견되는지 파악해서 팀이 서로 문제를 파악해서 도움을 줄 수 있게끔 기회 제공하는 회의, 30분 넘지 않는 시간 권장
6.함께 개선
-칸반 시스템을 조직에 맞춰나가는 점진적 개선을 사용하는 것 권장
-규범에 얽매이지 않고 조직의 상황에 적응하며 발전, 경험을 통해 조직에 맞는 최선을 찾는 것이 중요하다.
스크럼과 칸반의 차이점
칸반은
1)역할을 지정하지 않음
-제품 책임자, 스크럼 마스터 등의 역할이 따로 존재하지 않고 유연하게 진행
2)이터레이션(스프린트) 진행되지 않음
-기간을 따로 고정하지 않음
-기능이 완성될 때마다 배포하고, 새로운 기능 개발이 가능한 시점에서 끌어와 개발을 시작하는 방식으로 진행해 맺고 끊음 없이 지속적으로 흐름 유지됨
3)WIP를 제한한다
-스크럼은 스프린트 백로그의 양을 조정하며 팀 제품 개발 속도를 측정하지만, 칸반은 이터레이션을 사용하지 않기 때문에 워크플로우 상태에 WIP를 지정해 일의 속도를 조절 및 파악
4)스프린트 백로그 변경 가능여부
-칸반은 언제든지 작업 추가 및 수정 가능
5)보드 초기화 여부
-스크럼에서는 매 스프린트마다 보드가 생성, 해당 스프린트에 진행할 사항들을 보드에 넣어두고 그 전에 끝내지 못한 사항들은 다시 백로그로 보내는 작업을 하지만, 칸반은 지속적으로 보드가 유지된다.
MVP
minimum viable product
최소의, 생존 가능한, 제품
최소의 노력을 들여 고객에 대한 최대의 배움을 얻게 해주는 프로덕트
MVP가 왜 필요한가?
출시>측정>배움>피벗 또는 개선 으로 이어지는 피드백 루프를 가장 효율적으로 형성하는 방법
피벗: 기존에 하던 비즈니스 모델 또는 프로덕트의 성공 가능성이 낮다고 판단됐을 때 새로운 비즈니스 모델로 전환
-MVP는 단순히 제한적 기능을 가진 프로덕트가 아님
-적은 기능을 갖고 있되, 핵심 기능은 온전히 동작해야 하며(이해 가능하거나) 디자인, UX 등을 통해 고객의 근본 니즈나 욕구를 충족시킬 수 있는 제품을 의미함
-단 제품 없이도 고객을 이해시키고, 그들의 니즈를 파악할 수 있다면 굳이 제품(product)이 아니어도 무관함
활용 사례
Dropbox
제품 개발 전에 클라우드 서비스의 시장 니즈 파악을 위해 약 3분 가량의 영상(MVP) 업로드
하룻밤 만에 75,000건의 베타 서비스 이용 신청자를 만들어내서 열렬한 시장 니즈 파악
창업자는 막대한 자금이 드는 클라우드 서비스를 구축 전에, 유저들의 뜨거운 반응을 파악할 수 있었고, 이를 통해 시간과 자원을 절약할 수 있었음
PO의 MVP 활용하기
-다음 2가지는 반드시 고려해야 한다.
어떠한 가설을 검증하려 하는가?
그 가설을 검증하기 위해서 필요한 핵심 기능은 무엇인가?
-제품 개발 관련 인원은 모두 각자의 욕구가 뚜렷하기 때문에 균형점을 찾아야 한다.
(PO는 다양한 기능 또는 최신의 UX를 포함한 최고의 제품을 기획하고자 하고, 개발팀은 안정적이고 유지보수가 용이한 프로덕트를 개발하고자 하고, 디자이너는 아름다운 제품을 디자인하고자 한다)
-MVP는 내고 끝내는 것이 아닌, 고객 반응을 통해서 배움을 얻고 이를 통해 지속적으로 개선해 나가야 한다! 정량적 정성적 데이터 분석 > 인사이트 도출
Wireframe과 Prototype
-시제품이 나오기 전 제품의 초기 버전
-기획자, 개발자, 디자이너 사이의 이해의 간격을 좁혀주는 역할
-MVP와는 다르게 프로덕트팀, 비즈니스 관계자들에게 보여줘서 개발 방향성을 결정하는 내부 의사 결정을 위한 도구, 실제 제품과 동일하게 프로토 타입 만들 시에는 유저테스트에 사용하기도 한다.
와이어 프레임
-디자이너가 작업을 시작할 수 있는 기초 역할을 함
-세부 묘사에 치우치지 않고 핵심 요소만 최대한 추상화해 표현하는 것이 일반적
-애니메이션이 적용된 효과, 복잡한 전환 등 복합적 디자인 아이디어를 설명하는 경우에는 프로토 타입이 더 나은 선택이다.
프로토타입
-실제와 비슷하게 구현된 상태로 간단한 인터렉션을 포함
-피델리티 레벨에 따라서 로우 피델리티 / 하이 피델리티 프로토 타입으로 나뉨 (프로토타입 목적에 따라서)
-하이 피델리티는 실제 제품과 거의 동일하게 동작하기 때문에 커뮤니케이션을 최소화할 수 있으나 제작에 오랜 기간이 소요될 수 있다.
인력 구성, 개발 긴급도, 프로젝트 강조점 등을 종합적으로 판단해 피델리티 레벨 결정
프로토타입 툴 활용 가능
키노트, 루시차트, 발사믹, 어도비XD 등 (툴에 집착할 필요 없다)
wireframe, prototype의 의의
-모두 결국에는 의사소통의 도구
-궁극적으로 기획 컨셉을 디자이너와 개발자가 제대로 이해할 수만 있으면 된다.
자신이 가장 쉽고 편하게 다룰 수 있는 툴을 통해서 빠르게 만들고 더 자주, 더 깊은 커뮤니케이션을 하는 것이 중요하다. 사이드 프로젝트를 통해 경험치를 쌓을 것을 강력 추천!
'PM study log' 카테고리의 다른 글
| study log.16 (0) | 2023.02.24 |
|---|---|
| study log.15 AB Test (0) | 2023.02.22 |
| study log.13 PM스쿨 3주차 시작 (0) | 2023.02.20 |
| study log 12. 프로젝트 관리 (2) (0) | 2023.02.19 |
| study log.11 프로젝트 관리(1) (0) | 2023.02.18 |
