Edge of Chaos | Agile Development Blog 에 Kanban 의 Cumulative Flow Chart 활용 예[1]가 실려서 옮겨본다.
(Kanban 에 대한 배경 지식이 전혀 없다면 One day in Kanban land [2] 를 먼저 읽어보고 오자. 흥미가 생긴다면 Lean and Kanban[3]의 글들을 시간을 두고 찬찬히 읽어보길 권한다.)
Cumulative Flow 다이어그램을 잘 활용하면
라인 정지(stop-the-line)[4] 나 애자일 회고(retrospective)를 시작해야할 시점을 쉽게 발견할 수 있다. 여기
TargetProcess[5] 개발 과제로부터 실례가 있다.
차트를 보면 우리가 12월 초에 병목을 겪었음을 볼 수 있다. 꾀 복잡한 유저 스토리 하나가 원인이었다. 이론적으론 유저 스토리 하나가 개발 주기에 심각한 영향을 미치거나 병목을 발생시키면 안되지만, 규칙을 조금 어기면 실제 그런 일이 일어날 수도 있다.
문제의 유저 스토리는 jQuery 자바스크립트 프레임워크를 ExtJS 프레임워크[6] 로 교체하는 것이었다. 이 작업은 개발자 한 명이 별도의 브랜치에서 1개월에 걸쳐 구현하였다. 그 한 달 동안 나머지 멤버들은 몇 차례의 릴리스를 성공적으로 마쳤다. 테스터들은 그 유저 스토리에서 별 문제점을 발견하지 못했고, 인수 테스트(acceptance test) 역시 모두 통과하였다. 이 코드를 메인 코드 브랜치에 반영하는 것은 당연한 수순이었고, 그렇게 했다.
불행히도, 코드 반영 후 스모크 테스트 중 꾀 많은 빌드 에러들이 발생하였다. 버그를 다 잡는데는 1주일 이상이 소요되었고, 그 동안 우리는 아무것도 릴리스하지 못했다. 이미 반영된 코드를 다시 롤백하는 것 역시 만만치 않았기 때문에 뾰족한 수가 없었다.
여기서 얻은 교훈은 근본적으로 보다 복잡한 유저 스토리에는 테스트에 더 많은 노력을 들이라는 것이다. 이런류의 스토리는 어플리케이션에 다방면에 걸쳐 영항을 미치고, 보통의 스모크 테스트만으론 충분치 않다. 그래서 우리는 병합 전에 더 세심한 테스팅과 검증이 필요함을 의미하는 새로운 부류의 서비스를 제공할 것이다. 일단 “기술적으로 복잡한 스토리”라고 불러보자.
일반적으로, Cumulative Flow 차트는 과거 데이터를 분석하는데 훌륭한 툴이긴 하지만, 긴급한 병목을 식별해 내는데는 Kanban Board 가 훨씬 효과적이다. Kanban Board 에서 최대 허용 작업 수(limit)에 도달함은 곧 무엇가 문제가 있음을 뜻한다.
References
- Cumulative Flow Chart in Kanban: Real Usage Example (Edge of Chaos | Agile Development Blog)
- One day in Kanban land (wegra.org)
- Lean and Kanban
- Stop-the-line (Thoughts in the Wilderness)
- TargetProcess
- ExtJS framework (Ext JS)
