칸반(Kanban)
정의: Workflow상의 공정가시화를 통하여 프로세스를 적정선으로 관리하여 적시개발(Just in time) 및 품질과 생산성을 높이는 개발방법론
칸반(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 측정 및 최적화 : 평균시간, 사이클 타임을 산정하여 소요시간 최소화를 위한 프로세스 최적화
'02.SW' 카테고리의 다른 글
SW 아키텍처 - 패턴 (0) | 2020.06.16 |
---|---|
SW 개발 방법론 - 애자일 - BDD (Behavior-driven development) (0) | 2020.06.16 |
SW 개발 방법론 - 애자일 (Agile) (0) | 2020.06.16 |
SW 개발 방법론 - 애자일(Agile) - SAFe (Scaled Agile Framework) (0) | 2020.06.16 |
SW 유지보수 (리만 Lehman 소프트웨어 변화의 원리) (0) | 2020.06.11 |