08. 서비스 기획 업무 A~Z 알아보기(2)
9. 스크럼 스플린트 후 프로세스
1) 스프린트 종료(Finished Work)
- 스프린트 리뷰와 스프린트 회고 로 구성.
2) 스프린트 리뷰 (스프린트 결과물에 대한 피드백)
- 스프린트 결과 확인: 팀원과 이해관계자들이 모여 스프린트를 통해 무엇이 완료되었는지 확인
- 결과물 설명: 개발된 기능을 이해할 수 있도록 설명하며, 개발된 제품의 데모를 보여주는 것이 가장 좋다.
- 다음 단계 의논: 리뷰 결과와 스프린트 중 변경된 백로그를 고려하여 다음에 무엇을 할지 함께 의논.
- 피드백 수렴: 변경된 서비스에 대한 피드백을 수렴하고, 이를 바탕으로 '액션 아이템'을 뽑아낸다.
3) 스프린트 회고 (스프린트 진행 과정에 대한 토론)
- 개선 계획: 스프린트 회고 미팅은 팀이 다음 스프린트 동안 무엇을 개선할 수 있을지 계획하는 기회를 제공.
- 회고의 목적: 지난 스프린트가 어떻게 진행되었는지 검토하고, 잘된 것과 개선의 여지가 있는 항목을 알아내어 우선순위를 설정하고, 개선을 실천할 수 있도록 계획을 수립.
4) KPT 회고 방법론
- Keep (좋았던 부분): 계속 유지되었어야 하는 부분을 나열.
- Problem (문제점): 개선이 필요한 부분을 나열.
- Try (시도해 볼 부분): 구체적이고 실현 가능한 개선 방안을 나열합니다. 이 '액션 아이템'은 다음 스프린트에서 진행되며, 다음 회고 시간에 리뷰.
Ex) 개발에 필요한 부분이 빠져서 발생한 속도 지연 → 기획자는 개발 진행 전, 기획문서를 디자이너 & 개발자에서 충분히 리뷰받는 프로세스를 추가
10. 스크럼 최종 정리
1) Product Backlog (제품 백로그):
PO가 유저, 고객, 비즈니스 이해관계자들로부터 백로그를 받습니다. 우선순위가 높은 백로그는 개발이 진행될 수 있도록 세부적으로 구체화됩니다.
2) Sprint Planning Meeting (스프린트 계획 회의):
Scrum Master가 주도하는 회의.
3) Sprint Backlog (스프린트 백로그):
팀원들이 모여 스프린트 백로그를 선정하고, 우선순위를 결정.
4) Sprint Process (스프린트 프로세스):
1~4주 동안 정해진 스프린트 백로그를 진행하며, 이 과정에서 발생하는 이슈들을 지속적으로 추적. 스프린트 원칙에 따라, 스프린트 기간 동안 백로그의 추가나 기간 연장은 피한다.
5) Daily Scrum Meeting (데일리 스크럼 회의):
매일 15~30분 동안 진행되는 미팅으로, 필요한 경우에는 유관 팀원들만 추가로 논의를 진행.
6) print Review (스프린트 리뷰):
스프린트 동안 개선된 제품을 시연하고, 이에 대한 피드백을 받는 시간.
7) Sprint Retrospective (스프린트 회고):
스프린트의 프로세스 개선사항을 팀원들과 논의하는 시간. 여기서는 좋았던 점, 문제점, 개선사항을 정리.
- 이 전체 과정이 반복되며, 제품은 지속적으로 개선되고, 유저의 피드백을 반영하여 제품을 발전시키는 것이 스크럼의 전체적인 프로세스입니다.
11. 칸반(Kanban)의 유래
1) 칸반의 유래:
칸반이라는 용어는 일본어로 '간판'을 의미하며, 이 방법론은 도요타의 자동차 생산관리 시스템에서 유래.
- (전 단계의 부품이 재고로 쌓이는 것을 막기위해서) 필요한 만큼의 부품을, 적시에 만들기 위한 노력이었고 이를 JIT (just in time) 이라 부름
2) 칸반의 예시:
작업량을 제한하여 최적의 양만 처리하거나, 성능을 늘리는 방식을 사용.
- 성능이 세탁기 > 건조기인 사래를 예로 들면, 세탁기는 작업량을 제한하고, 건조기는 성능을 늘려서 두 기계의 작업량을 맞춘다.
3) 칸반 방법론의 개념:
칸반은 일을 밀어넘기는 'Push' 방식과 달리, 일이 완료되었을 때 전 단계의 작업을 지시하는 'Pull' 방식을 사용. 이 방식은 '할 일'이 제한되어 있을 때 효과적.
1) 칸반의 작업 흐름:
- 'To do'에서 시작하여 → 개발, 코드 리뷰, 테스트, 배포를 거쳐 → 'Done' 단계로 이동.
- 작업이 완료되면 'Pull Signal'로 전 단계의 작업 지시를 받는다.
12. 칸반 실천법
1) 시각화
- 칸반 보드: 현재 상황을 이해하고 개선점을 파악하는 도구로, 화이트보드나 포스트잇 대신 지라, 아사나, 트렐로 등을 사용.
- 칸반 보드와 카드: 작업을 시각적으로 표현하며, 카드는 작업 단위를, 카드가 속한 열은 해당 작업의 프로세스 단계를 나타낸다.
- 열과 행: 열은 작업단위를 나타내고, 행은 '스윔레인'으로 User Story를 묶는 'Epic'을 나타낸다.
- 정책: 각 열에서 다음 열로 이동하기 전에 완료해야 하는 작업을 명확히 정의.
2) 진행 중 업무 제한 (WIP, Work In Progress)
- WIP 제한: 하나의 열에 WIP 제한 기준만큼의 카드가 있을 경우, 새로운 카드를 당겨 올 수 없다.
- Pull 방식: WIP 제한을 통해 'Push'가 아닌, 'Pull' 형으로 업무 방식이 변경.
- 리드타임 감소: 부분 완료된 업무를 줄이고, 리드타임을 줄여 고객에게 더 자주 제품을 배포하고 피드백을 얻는다.
3) 흐름을 관리
- 지속적 관리: 업무 흐름이 완성된 가치 생산을 최대화하도록 지속적으로 관리.
- 흐름 개선: 특정 업무가 전체 흐름을 막을 경우, 해당 업무를 개선하여 흐름을 개선.
- 리드타임 최소화: 완성 제품이 생산될 때까지의 리드 타임을 줄이고, 가능하면 예측 가능해야 한다.
4) 정책을 명시화
- 정책 명시: 칸반 방법론에서 모든 구성원이 동일한 방식으로 일하는 것이 중요하며, 정책은 언제든지 변경될 수 있어야 한다.
- WIP 제한과 완료의 정의: WIP의 제한과 각 열의 완료의 정의는 모두 정책의 일부.
5) 피드백 루프 실행
- 7가지 리뷰: 전략, 운영, 위험, 서비스 제공, 재보충, 칸반, 제공계획 리뷰를 진행.
- 주기적 리뷰: 주기적인 리뷰 세션을 통해 칸반 방법론이 더 나은 방향으로 개선.
6) 함께 개선하고 실험을 통해 발전
- 규범에 얽매이지 않음: 칸반은 규범에 얽메이지 않고, 최소한의 규범 안에서 조직의 상황에 적응하며 발전해야 한다.
- 지속적 개선: 칸반이 조직의 현상태에서 시작하여 지속적이고 점진적인 개선을 추구.
- 경험을 통한 최선의 찾기: 조직에 맞는 최선의 방법을 찾는 것이 중요.
13. 칸반의 장단점
1) 칸반의 장점
- 규범이 적음: 스크럼이나 XP와 비교했을 때, 규범이 적어 조직에 도입하기 용이.
- 연속적인 흐름 관리: 스프린트와 같은 데드라인은 없지만, 작업의 속도에 대한 압박이 존재.
- 시간 절약: 스크럼의 다양한 미팅으로 인한 시간 리소스 낭비를 줄일 수 있다.
- 병목 지점 파악 용이: 병목 지점을 명확히 파악할 수 있어, 개선에 용이.
- 저품질 배포 최소화: 스프린트 내에서 일을 마무리해야 하는 스크럼의 저품질 상태의 배포가 최소화된다.
2) 칸반의 단점
- 규범 부족으로 인한 무질서 상태 가능성: 규범이 없어서 팀원의 자유성이 극도화되면, 무질서한 상태가 발생할 수 있다.
- 자발적 실천 문화 약화와 프리라이더 존재: 스프린트 안에서 일을 완료해야 한다는 압박감이 없어, 자발적인 실천 문화가 약하거나, 프리라이더가 많을 경우에는 긴장감이 떨어지고 전체적인 생산성이 떨어질 수 있다.
14. 칸반과 스크럼의 차이점
1) 역할 지정
- 칸반: 특정 역할을 지정하지 않고, 팀원 개개인이 자신의 기능에 맞춰서, 역할을 자유롭게 지정하고 실행.
- 스크럼: 제품 책임자, 개발팀, 스크럼 마스터 등의 역할을 지정.
2) 이터레이션(Interation)의 유무
- 칸반: 이터레이션이 없으며, 기간을 고정하지 않고, 배포 가능한 기능이 완성될 때마다 배포하고, 새로운 기능 개발이 가능한 시점에서 끌어와 개발을 시작.
- 스크럼: 스프린트라는 정해진 기간의 이터레이션을 반복.
3) 작업 속도 조절 방법
- 칸반: 워크플로우 상태에서 진행 중인 작업(WIP)을 제한하여 일의 속도를 조절하고 파악.
- 스크럼: 스프린트 백로그의 양을 조정하여 팀의 제품 개발 속도를 측정.
4. 백로그 변경 가능 여부
- 칸반: 언제든지 작업을 추가하거나 수정할 수 있다.
- 스크럼: 일단 스프린트가 시작되면 스프린트 백로그를 변경하지 않는 것이 원칙입.
5. 보드 초기화 여부
- 칸반: 이터레이션이 없기 때문에 보드가 지속적으로 유지되며 각 카드가 [done]으로 이동할 때까지 지속적으로 진행.
- 스크럼: 매 스프린트마다 보드가 생성되고 해당 스프린트에 진행할 사항들을 보드에 넣어두며, 그 전에 끝내지 못한 사항들은 다시 백로그로 보낸다.
15. 애자일 방법론 기반으로 프로젝트 진행하기 (칸반)
- 칸반 운용 조직에서 발생하는 일 (칸반나라)
1) 과제목록
- 제품 책임자(PO)가 백로그의 우선순위를 결정하며, 이 단계에서는 진행 중인 작업의 개수(WIP)에 대한 제한이 없다.
2) 우선 과제
- PO가 완성된 기획서를 바탕으로 할 일 리스트를 생성하고, 이를 우선 과제로 이동시킨다. 이 단계에서는 WIP를 2개로 제한하여 한 번에 처리할 수 있는 작업 범위를 제한한다.
3) 개발 - 진행 중/완료
- 개발이 시작되어 완료될 때까지의 과정이다. 이 단계에서도 WIP를 2개로 제한하여, 빠르게 2개의 작업을 완료하는 것을 중요시한다.
4) 배포
- 개발이 완료된 작업이 배포되는 단계이다.
5) 라이브
- 작업이 가치를 제공할 수 있는 단계로써, 이 단계를 통해 프로젝트 개선이 이루어진다.
- 이렇게 칸반 운용에서는 작업의 흐름을 명확하게 시각화하고, 작업의 양을 합리적으로 조절하여 효율적인 작업 진행을 가능하게 한다. 조직 내 다른 팀원들도 필요에 따라 업무를 도와줄 수 있다는 특징이 있다.
'PM(Product Manager) > 학습일지 3주차' 카테고리의 다른 글
| 5 day 2024.01.19. (0) | 2024.01.19 |
|---|---|
| 4 day 2024.01.18. (0) | 2024.01.18 |
| 3 day 2024.01.17. (0) | 2024.01.17 |
| 1 day 2024.01.15. (1) | 2024.01.16 |
