I. 개발공정의 시각화를 통한 제어, 칸반의 개요
가. 칸반(Kanban)의 정의
- 작업흐름을 표현하는 칸반보드를 통해 개발공정을 시각화하고, 작업제한 및 소요시간 최적화 기법으로 적시개발을 지원하는 애자일 방법론
나. 칸반의 특징
1) 작업흐름(Workflow)의 시각화 : 분할된 작업을 칸반보드에 게시하여, 연속적인 흐름을 시각적으로 표현
2) WIP(Work In Process) 제한 : 프로세스 별 동시 진행가능한 작업의 수를 제한하여 병목 및 쏠림 방지
3) 리드타임 측정 및 최적화 : 리드타임을 가능한 짧고 예측 가능하게 만들 수 있도록 프로세스 최적화
II. 칸반의 구성도 및 구성요소
가. 칸반의 구성도
-To-Do 리스트에서 작업을 선택한 후 개발, 테스트, 배포, 완료 등 작업흐름을 순차적으로 시각화
나. 칸반의 구성요소
|
구성요소 |
설 명 |
산출물 |
|
칸반보드 (Kanban Board) |
- 전체 프로세스를 기재한 보드에 스토리카드를 이용하여 업무흐름 제어 |
스토리카드 |
|
프로세스 (Process) |
- 실제 업무가 이루어지는 단계 및 업무수행을 통한 산출물 작성 |
업무성과 |
|
작업 큐 (Work Queue) |
- 개발, 테스트, 배포 등 대기과정 |
Work Queue List |
|
총사이클타임 (Total Cycle Time) |
- 총 작업의 수행시간으로, 개별업무의 사이틀타임의 합 |
총 사이클 타임 |
III. 칸반과 스크럼(SCRUM)의 비교
가. 칸반과 스크럼의 특징비교
|
항 목 |
칸반 |
스크럼 |
|
|
수행원리 |
작업흐름를 통한 연속적 개발 |
스프린트 기반의 반복적 개발 |
|
|
반복 (Iteration) |
선택적 적용 |
사전정의 필수 |
|
|
작업량 승인 |
팀승인 선택적 |
스트린트 내 팀승인 필수 |
|
|
계획과 프로세스 |
리드타임 사용 생산 시작부터 완성까지의 시간 |
속도(Velocity) 사용 |
|
|
규칙 |
작업흐름의 시각화 WIP 제한 리드타임 측정 및 최적화 |
제품기능목록, 스프린트 계획 회의 스프린트 구현목록 일일스크럼회의 |
소멸차트 스프린트 리뷰 스프린트 회고
|
|
팀 구성 |
특정 분야의 전문가 |
Cross Functional Team (기획자, 개발지, 디자이너, 테스터 등) |
|
|
작업분할 |
규모에 대한 정의 없음 |
스프린트에서 수행가능한 수준 |
|
|
일정관리 |
없음 |
소멸차트 (Burndown Chart) |
|
|
WIP 제한 |
작업흐름 상태 별 직접제한 |
스프린트 단위의 간접제한 |
|
|
진행중 요구사항추가 |
여력이 있는 경우 가능 |
진행중 스프린트 내 추가 불가 |
|
|
역할지정 |
사전 정의된 역할 없음 |
제품책임자, 스크럼마스터 등 사전 정의 |
|
나. 칸반과 스크럼의 적용프로세스 비교
|
항 목 |
칸반 |
스크럼 |
|
진척관리 |
스토리카드가 한 번의 반복과정으로 완성 |
타임박스(스프린트) 구간 내 반복수행 |
|
총사이클타임을 활용해 성과측정 |
소멸차트를 사용한 성과측정 |
|
|
역할과 업무협의 |
별도 정의된 역할과 회의 없음 |
특정 역할부여와 회의 존재 |
|
조직 내 익숙한 방식 사용 |
스크럼 마스터의 업무 및 권한 부여 |
|
|
기존 방법론에서 전환 |
기존 프로세스에서 이행 용이 |
SCRUM 자체의 체계로 이행 어려움 |
다. 칸반과 스크럼의 비교에 따른 상호보완방안
|
항 목 |
설 명 |
|
|
보완방향 |
한가지 개발방법론이 다른 것을 완전히 대체하는 방향은 긍정적이지 않음 |
|
|
빈번한 배포가 요구되는 상황을 고려, 스크럼의 부정적 이슈 해소를 위해 칸반 도입 |
||
|
보완내용 |
잦은 회의의 부담 |
- 개선으로 회고를 대체, 진취적으로 프로세스 개선 |
|
스토리 추정의 불확실성 |
- 예상보다 큰 작업은 스프린트에 부담을 초래하므로 WIP 조정, 리드타임 최적화 등 불확실성 대응 |
|
|
스프린트 변경의 경직성 |
- 작업흐름에 따라 WIP를 조정해 유연성부여 |
|
|
속도에 대한 압박 |
- 스프린트의 완료압박을 없애고, 칸반보드 기반의 공정관리를 통해 빠른 개발 및 배포 |
|
