SW 개발 방법론 - 애자일 - 칸반(Kanban)

칸반(Kanban)

정의: Workflow상의 공정가시화를 통하여 프로세스를 적정선으로 관리하여 적시개발(Just in time) 및 품질과 생산성을 높이는 개발방법론

진행 중 업무(WIP, work-in-progress)를 제한하고 낭비가 되는 효과 또는 작업 전환을 감소

리틀의 법칙

WIP = Th * CT

• WIP(진행 중 업무) = 개발 시스템에서 완료되지 않은 항목(버그, 사용자 스토리, 변경 요청 등)의 평균량
• Th(처리량) = 단위 시간 동안 팀의 출력
• CT(사이클 타임) = 팀이 한 항목을 마치는 데 걸리는 평균 시간

그림 1. 처리량과 WIP의 관계

그림 2. WIP 증가에 대한 팀의 반응

WIP가 늘어나면 팀이 최대 가용 처리량(초록색 영역)에 도달하기 전까지 업무를 최적화하고 출시 프로세스의 낭비를 제거하게 만들 수 있다.(노란색 영역) 그 이후에도 WIP가 계속 늘어난다면 더 이상의 개선이 이루어지긴 어렵다. 오히려 스트레스와 작업 전환으로 인해 팀의 처리량이 감소할 것이다.(빨간색 영역)

1. 팀 수용량을 살펴보고 팀이 그 수용량을 넘어선 과도한 업무에 시달리지 않도록 한다. WIP와 처리량을 그래프로 그려보면 팀이 견뎌낼 수 있는 최대 WIP를 알 수 있다.
2. 개발 프로세스를 안정화시키려면 한 가지 이상의 변수를 제어해야 할 수도 있다. 두 번째 사례에서는 WIP와 팀 수용량을 제어해서 안정적 사이클 타임을 얻을 수 있었다.
3. 긴급 처리 레인의 함정을 인식해야 한다. 본질적으로 긴급 처리 레인은 프로세스 위반의 백도어(back door)다. 신중하게 사용하지 않으면 팀 생산성이 악화될 수 있다.

https://congruentagile.com/2014/08/01/how-kanban-works/

https://www.infoq.com/articles/how-kanban-works/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=Process%252520&%252520Practices&utm_reader=feedly

칸반(Kanban)

정의 : “칸반 방법은 지식 작업을 위한 흐름 시스템을 설계, 관리, 개선하기 위한 수단이다. 또한 조직은 칸반을 통해 기존 워크플로에서 시작해서 진화적 변화를 이끌 수 있다. 그 방법은 작업 흐름을 시각화하고, 진행 중인 작업(WIP)을 제한하고 시작하기를 멈추고 마무리에 착수하는 것이다. 칸반 방법의 이름은 무형의 작업물에 대한 진행 중인 작업을 제어하기 위한 시각적 신호 메커니즘인 칸반(Kanban)을 사용하는 데서 따왔다.”

효과적인 이유 : 칸반은 언제 작업이 들어올지 모르는 지원 티켓 관리와 같은 시나리오에 효과적이다. 특히 예를 들어 해결된 결함과 같은, 가치/생산성을 측정하는 대안 방법이 있는 경우 유용하다. 또한 칸반은 일일 스탠드업, 데모, 레트로스펙티브와 같은 “오버헤드” 활동에 시간을 덜 소비할 수 있게 해준다.

효과를 거두지 못하는 경우 : 칸반은 애자일을 새로 접하는 팀에는 어려울 수 있다. 다른 방법론과 달리 프로세스가 명확하게 정의되어 있지 않기 때문이다. 데모가 없으므로 팀은 제대로 된 결과물을 제공하고 있는지에 관해 비즈니스로부터 피드백을 받을 수 없다. 또한 스프린트 레트로스펙티브가 없으므로 프로세스를 개선하기가 어려울 수 있다. 좋지 않은 프로세스에 무기한으로 빠지기 쉽다.

(http://www.itworld.co.kr/news/109011)

각 프로세스마다 각 이슈를 표시해 전 프로세스 또는 다음 프로세스와의 연속적인 흐름을 유기적으로, 그리고 시각적으로 만들어 전체 프로세스를 유연하게 만들고자 하는 방법론

여기서 이슈가 간판을 의미하며, 카드(card)라도고 부릅니다.

위의 그림처럼 to-do, dev, test로 표시된 행을 수영 레인(swimlane)으로 불리며, 각 프로세스를 나타냅니다. 각 수영 레인에 표시되어 있는 숫자는 WIP(Work In Process)로 불리며, 각 프로세스마다 동시에 진행할 수 있는 이슈의 제한 수를 의미합니다. 알파벳으로 되어 있는 이슈(또는 카드)들은 왼쪽에서 오른쪽으로 연속적으로 진행하게 되며, 해당 이슈에는 담당하게 되는 멤버나, 해당 이슈의 작업 일수(또는 시간)등을 표시하여 좀 더 구체적으로 표현할 수 있습니다.

 

해당 칸반 보드를 통해 한 프로젝트에서 관리되는 모든 이슈를 한 번에 확인할 수 있으며, WIP을 통해 개발 프로세스에 병목현상이나 지나친 업무 쏠림을 방지할 수 있습니다. 또한 각 프로세스에 위치한 이슈들을 확인함으로써 전 단계, 또는 다음 단계에 대한 유기적인 흐름까지 파악할 수 있습니다.

 

기본적으로 소프트웨어 개발론에서의 칸반은 해당 프로젝트에 참여한 모든 멤버가 알 수 있도록 시각화하는 것이 가장 큰 목표입니다만, 아래의 핵심 요소가 포함되어야 비로소 완성이 된다고 할 수 있습니다.

시각화

WIP을 통한 제한

흐름의 관리

정책의 명시화

피드백 루프 실행

모든 멤버의 참여로 인한 개선, 실험

(https://www.software.kr/um/um03/um0304/um030401/um030401View.do?postId=44723)

#3가지 규칙

 - 워크플로우 가시화 : 작업을 분할(backlog)로하여 작업지시서(카드)에 기록하여 작업보드에 게시

 - WIP(Work in progress) 제한 : 워크플로우상의 적정한 프로세스를 관리 > 병목현상(Bottle neck) 관리를 통한 품질저하 방지

 - workflow 측정 및 최적화 : 평균시간, 사이클 타임을 산정하여 소요시간 최소화를 위한 프로세스 최적화