일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- hadoop
- leadership
- Software Engineering
- history
- erlang
- Book
- django
- ubuntu
- hbase
- Linux
- psychology
- management
- Python
- UK
- Italy
- Java
- comic agile
- MySQL
- Programming
- RFID
- Kuala Lumpur
- agile
- Spain
- Malaysia
- France
- QT
- programming_book
- Book review
- web
- program
- Today
- Total
칸반과 스크럼 본문
가장 중요한 것은 팀의 협력과 커뮤니케이션
1부 비교
1 도대체 스크럼과 칸반은 무엇인가?
스크럼은 세 가지 역할을 정의하고 있다. 바로 제품의 비전과 우선순위를 부여하는 제품 책임자, 제품을 구현하는 팀, 장애물을 제거하고 프로세스 리더십을 제공하는 스크럼 마스터다.
칸반은 어떠한 역할도 정의하지 않는다.
스크럼과 칸반의 공통적인 마음가짐은 '간결할수록 좋다'
스크럼은 시간이 고정된 이터레이션에 기반을 둔다... 동일한 이터레이션 길이를 유지함으로써 리듬을 만드는 것이 일반적인 아이디어다.
칸반에서는 시간이 고정된 이터레이션을 언급하지 않는다.
칸반이 WIP을 직접 제한하는 데 반해 스크럼은 간접적으로 WIP을 제한
스크럼 팀은 대개 '속도(velocity)'라는 지표를 측정
일부 팀은 이러한 유형의 고민을 회피하고, 예측하는 데 들어가는 시간 소모를 줄이려고 아이템들을 얼추 같은 크기로 쪼개는 데 노력을 기울인다. 아이템들이 거의 동일한 크기라면 부드럽게 흘러가는 시스템을 만들기 쉽다.
핵심 요소는 '피드백 루프'다. 무엇인가 변경한다 → 어떻게 되는지 관찰한다 → 학습한다 → 다시 변경한다. 일반적으로 피드백 루프가 짧을수록 프로세스를 빨리 적응시킬 수 있다
스크럼에서는 스프린트가 기본 피드백 루프
칸반은 매우 유용한 몇 가지 실시간 지표를 제공
• 평균 리드 타임: 아이템이 '완료'(아니면 어떻게 부르든 맨 오른쪽 칼럼)에 도달할 때마다 갱신한다.
• 병목지점: X+1 칼럼이 비어 있는데도 칼럼 X에 아이템이 잔뜩 들어 있는 전형적인 증상이다. 여러분의 보드에서 '공기 방울을 찾아보라.
피드백 루프가 너무 길면 프로세스 개선 속도가 늦어지고, 피드백 루프가 너무 짧으면 각 변화에 따른 프로세스 안정화 기간이 부족하여 프로세스가 망가질 수도 있다.
7 스크럼은 이터레이션 내에 변경을 허용하지 않는다.
칸반 팀의 응답 시간(우선순위 변경에 반응하는 데 걸리는 시간은 여력이 생기는 데 걸리는 시간으로, '한 아이템 빠져나감 - 한 아이템 들어옴'이라는 일반적인 원칙(WIP 리밋에 의거하여)을 따른다.
스크럼에서는 제품 책임자가 스크럼 보드를 건드릴 수 없는데, 이는 해당 이터레이션 내에 특정 아이템 집합을 진행하기로 팀에 약속했기 때문이다. 칸반에서는 누가 보드의 내용을 변경하도록 할 것인지 고유한 기본 규칙을 설정해야 한다. 전형적으로 제품 책임자는 '할일' 또는 '준비', '백로그', '제안' 같은 맨 왼쪽 칼럼을 할당받는데, 이 칼럼은 원할 때마다 변경할 수 있는 곳이다.
8 스크럼 보드는 이터레이션마다 초기화된다
칸반에서 보드는 일반적으로 변함이 없다. 즉 초기화하고 다시 시작할 필요가 없다.
스크럼 보드는 정확히 특정 스크럼 팀에 속한다. 스크럼 팀은 교차기능 팀으로 이터레이션 내에 모든 아이템을 완료하는 데 필요한 기술을 전부 보유하고 있다.
칸반에서는 교차 기능 팀이 선택 사항이며 보드를 특정 팀만 소유할 필요도 없다.
스크럼 팀은 한 이터레이션 내에 완료 기준에 의거하여 완료할 수 있다고 생각하는 아이템들만 하기로 약속
칸반 팀은 리드 타임을 최소화하고 흐름을 유지하려고 하는데, 이는 간접적으로 아이템들을 상대적으로 작은 조각으로 쪼개도록 유도
12 둘다 여러 제품의 동시 개발을 허용한다
일반적으로 스크럼과 칸반은 모두 린과 애자일의 원칙과 가치에 잘 부합
• 스크럼과 칸반은 모두 당김 스케줄링 방식. 팀이 준비가 되었을 때 일을 '당겨온다'
• 스크럼과 칸반은 지속적이며 경험주의적 프로세스 최적화에 기반. '카이젠'
• 스크럼과 칸반은 계획을 따르기보다는 변화에 대응할 것을 강조
스크럼은 우선순위가 부여된 제품 백로그를 규정
팀이 어떤 아이템을 가장 먼저 당겨올지 결정하는 규칙이 필요
• 항상 맨 위에 아이템을 가져간다.
• 가장 오래된 아이템을 가져간다(따라서 각 아이템에는 시간이 기록돼 있다).• 아무 아이템이나 가져간다.
스크럼에서는 일일 미팅을 규정
칸반에서는 일일 스탠드업을 규정하고 있지 않지만, 어쨌든 칸반팀들은 대부분 실시한다. 어떤 프로세스를 사용하는지와 상관없이 일일 스탠드업은 뛰어난 기법이다.
칸반이 유일하게 규정하는 것은 작업 흐름이 눈에 보여야 한다는 점과 WIP이 제한되어야 한다는 점
16 스크럼과 칸반비교 요약
2부 사례 연구
관리자들 관점에서는 스크럼의 스프린트는 그다지 잘 맞지 않았다. 관리자들은 업무 간 우선순위를 매일 재조정하기 때문
변화는 더 나아지기 위한 것... 팀이 완료할 수 없는 일에 대해 “못한다"라고 말하고, 품질을 중요시하며 팀의 백로그에서 우선순위가 낮은 일들을 제거하기 시작할 것이라는 의미
스토리 포인트에 WIP 리밋을 두는 것은 쓸모없다는 점이다. 이력을 추적하기가 정말 어렵기 때문이다. 이력 추적을 할 수 있을 만큼 쉬운 WIP 리밋은 단순히 아이템 개수(즉,동시 진행 중인 작업 개수)를 세는 것뿐이었다.
WIP 리밋을 존중하는 것이 이론적으로는 쉽게 들리지만 실제로 이를 지키기는 어렵다. 어떤 단계에서는 "아니오"라고 말해야 함을 뜻하기 때문이다.
30 무엇을 측정할 것인가?
31 변화는 어떻게 시작되었나?
실험하고 실패하는 것을 두려워하지 말라
마지막으로 명심할 것
회고부터 시작하라!
절대로 실험을 멈추지 말라!