2018년 11월 28일
칸반(KANBAN)
I. 적시 개발을 지원하는 간판, KANBAN의 개요
가. KANBAN의 정의
적시 개발(Just-in-time Development)을 지원하는 방법론으로 매우 적은 규칙을 가지고 있는 Agile 방법론
나. KANBAN의 특징
- 워크플로우 가시화: 일을 작게 분할하여 카드에 기록하여 보드에 게시
- WIP 제한: Work-in-process 제한하여 동시에 진행될 수 있는 항목 제한
- 플로우의 측정: 한 항목을 완료 소요 평균 시간 산정하여 최적화
II. KANBAN의 개념도
 |
TO-DO 리스트(Backlog)를 보고 작업자가 해당 작업을 선택하고 개발 진행, 배포, 서비스 등 순차적으로 워크플로우를 가시화
III. KANBAN 개념도 및 SCRUM과의 연관관계
가. KANBAN과 SCRUM의 연관관계
 |
- KANBAN은 SCRUM과 스토리 혹은 과업이 할당되고 측정되는 세부 방식에 차이가 있더라도 SCRUM과 함께 사용될 수 있음
- SCRUM과 KANBAN 모두 테스트 주도(Test-drive) 개발 혹은 지속적 통합(CI)과 같은 Agile이 고려된 기법을 사용할 수 있음
- SCRUM의 워크플로우 파악이 SCRUM Meeting을 통해 파악이 되나, KANBAN과 융합함으로 워크플로우의 가시화가 가능함
나. KANBAN과 SCRUM 비교
| 구분 | KANBAN | SCRUM |
|---|---|---|
| Iteration | 선택적 적용 | 사전 정의 필수 |
| 작업량 승인 | 팀 승인 선택적 | Iteration내작업에 팀승인필수 |
| 계획과 프로세스 | 리드타임(lead time) 사용 생산 시작부터 완성까지 시간 | Velocity 사용 |
| 팀 구성 | 특정분야의 전문가로 구성 | Cross Functional Team |
| 작업 분할 | 규모에 대한 정의 되지 않음 | Sprint에 수행 가능한 수준 |
| 일정 관리 툴 | 사전 정의된 다이어그램 없음 | Burn down chart |
| WIP 제한 | Workflow 상태 별 직접 제한 | Sprint 단위로 간접적 제한 |
| 작업항목공유 | 여러 팀이나 개인에 공유 | Sprint backlog별 특정팀 소유 |
| 작업 추가 | 여력이 있을 경우 추가 가능 | 진행중Iteration에 추가불가능 |
| 역할 지정 | 사전에 정의된 역할 없음 | PO, SM, Team 등 사전에 정의 |
| 유사성 | Agile 방법론, pull scheduling에 의한 플로우 최적화, WIP의 제한, 신뢰성 있는 SW 전달, 조기에 자주 전달, 가가 조직적인 팀, 작업 분할, 지표에 기반한 지속적인 프로세스 최적화 | |
IV. KANBAN과 SCRUM 적용 프로세스 측면 비교
| 구분 | KANBAN | SCRUM |
|---|---|---|
| 진척 관리 | 하나의 스토리가 한번의 반복 과정에서 완성(WIP) | time-box 구간 내에서 반복 수행(sprint) |
| total cycle time을 활용하여 성과 측정 | bun down chart 사용 팀 성과 측정 | |
| 역할과 업무 협의 | 별도로 정의된 역할과 미팅이 없음 | 특정 역할과 업무 협의(meeting) |
| 조직 내에서 익숙한 방법을 사용 | 정의(스크럼마스터, 제품책임자) | |
| 기존 SCRUM사용 조직은 그대로 사용 | 스프린트 계획미팅(스토리 내 스프린트 결정) | |
| 기존 방법론에서 이행 | 기존 프로세스와 함께 시작하면서 지속적 개선 | SCRUM자체의 체계와 기 사용 중인 방법론에서 전환 어려움 |
About The Author
