칸반 이란?

칸반이란?

칸반은 연속적 흐름 처리 방식입니다. 이슈는 큐에 입력되고, 개발 프로세스의 단계에 따라 “당겨”집니다. 칸반은 칸반 보드로 시각화되고 각각 단계는 열로 표시됩니다. 이슈들은 “수영 레인(Swimlane)”으로 불리는 행으로 나눌 수 있습니다. 이슈들의 우선순위를 나타내기 위해 수영 레인을 이용하기로 결정하고  우선순위가 낮은 이슈들을 아래에 배치합니다. 칸반의 핵심은 Work-In-Process(WIP)가 동시에 개발이 진행 될 수 있는 아이템의 수를 제한하는 것입니다. 작업자는 WIP에 여유가 있을때만 작업을 왼쪽에서 오른쪽으로 당길 수 있습니다. 스크럼이 스프린트에 이용할 수 있는 작업 시간을 제한함으로써 생산성을 제어하는 반면, 칸반은 동시에 처리할 수 있는 이슈의 수를 제한함으로써 생산성과 벨로시티를 제어합니다. 추정은 더이상 프로세스의 일부가 아닙니다.

벨로시티는 여전히 중요 목표지만 지금 우리는 이슈 레벨에 따라 최적화 시켰고, 사이클 타임이라고 부르고 있습니다. 보드의 오른쪽에 있는 아이템은 그 뒤의 아이템들보다 더 높은 우선순위를 가집니다. 이것은 팀의 중요한 핵심 가치를 만들어 냅니다. 더 많은 작업을 하기 전에, 지금 하고 있는 작업부터 끝내야합니다. 또한 멀티 테스킹을 그만두고 이 일 저 일을 번갈아가면서 하는 것을 지양합니다.

칸반을 사용하면 사업적 요구에 따른 우선순위의 변동이 사라집니다. 사업팀은 “To Do” 열을 소유하고, 기술팀은 나머지 모든 열을 소유합니다. 사업팀은 작업들이 To Do에 있는 동안 야생 동물처럼 날뛰게 할 수 있지만, 다른 열로 이동된 이후에는 큰 노력 없이 그것들을 바꿀 수 없습니다. 결과적으로, 개발자들은 작업을 선택하는 순간 사업적인 영역과 단절됩니다.

 

칸반 간략 설명

칸반 장점

스크럼은 개발자에게 규범적이고 유연하지 못한 규칙을 부과하여 관리되는 것 처럼 느껴지게 만들었지만, 칸반은 탄력적이고 절차 지향적이고 기술 조직에 의해 관리됩니다. 게다가, 연속적인 흐름 모델은 “데드라인”이 없다는 것을 의미합니다. 그러나 “속도”에 대한 압박은 늘 존재합니다. 개발속도에 대한 압박은 존재하지만 데드라인이 없어 전체적인 생산성은 더 향상될 수 있습니다. 스크럼과 대비하여 전체 팀 플래닝 스프린트로 격주에 한번씩 반나절을 허비하지 않았을 수 있고 스프린트와 일치시키기 위해 개발 범위를 속이지 않을 수 있습니다. 칸반은 생산성과 코드 품질 모두를 향상시킬 수 있는 방법론이고, 한번에 여러 업무를 진행하는데서 오는 혼란을 감소 시킵니다. 거기다, 모두가 칸반 보드만 보면 무엇이 누구에 의해, 얼마정도 진행되고 있는지, 다음 작업을 위해서 무엇이 필요한지, 병목이 어디인지 알 수 있기 때문에, 프로젝트 관리 오버헤드를 감소시킬 수 있습니다.

품질에 대한 조직적 목표

계획적이지 않은 칸반의 주요 이점은 소프트웨어 품질에 초점을 맞출수 있게 해주는 것입니다. 스크럼에서는, 스프린트 내에 있는 것을 하기 위하여 코드리뷰를 건너뛰고, 코드 커버리지 표준인 95%에 못미치는 70%를 승인하는 등 기술적 부채를 늘려가는 경우가 많았습니다. 칸반에서는, 코드 품질 보증 단계는 프로세스에 포함됩니다. 거의 데드라인이 없기 때문에, 이런 단계를 건너 뛰어야 할 만한 압박이 없어집니다.

개선 VS 회고

스크럼 회고는 칸반에서 개선 회의로 대체됩니다. 개발자와 PO는 오버헤드를 감소시키면서, 속도와 품질을 향상시키기 위해 프로세스가 어떻게 수정되어야 하는지 논의합니다. 한 것을 뒤돌아보고 비판하는 대신, 진취적으로 프로세스를 개선하는데 모든 에너지를 쏟습니다. 방어적인 태도는 줄어들고, 협동력은 향상됩니다. 프로세스 안의 모든 것은 좋은 목표이고 새로운 아이디어들은 테스트 하기 위한 실험들로 간주됩니다. 대부분의 아이디어들은 시도해볼 수 있고, 매우 일부만 탈락합니다. 그 결과, 개선 회의에서는 긍정적이고, 창조적인 느낌을 받을 수 있고, 프로세스는 아주 부드럽게 수행됩니다.

칸반을 위한 소프트웨어 도구들의 미흡

Atlassian Jira와 Greenhopper가 칸반을 위한 좋은 기능들을 가지고 있지만, 이것들의 칸반 보드는 상대적으로 새롭고, 기대하는 것에 비해 유연스럽지 못합니다.(예를 들면, 수영 레인에서 WIP 한계를 가질 수 있도록).그 결과, 프로세스 일부를 Jira와 Greenhopper에서 가능하도록 맞춰야합니다. 칸반 보드를 팀의 특별한 요구에 따라 모델링 할 수 있다면, 칸반을 통해서 더 많은 이점을 얻을 수 있지만 이러한 도구가 미흡합니다.

신속함에 대한 조직의 동기부여 상실

스크럼에서는, 스프린트 시계가 큰소리로 똑딱거립니다. 모두가 스프린트 안에서 일을 완료하기 위해 압박을 느끼고 마음을 급박하게 만듭니다. 칸반에서는, 신속성은 더 추상적이고 그러한 감정적인 압박이 없기 때문에 문화부터 관리에 걸쳐 계속 열심히 해야 조직이 건강하게 유지될 수 있다는 긴장감을 부여해야만 합니다.

 

칸반이 완벽한 개발방법론은 아니지만 도입해보기엔 충분히 매력적입니다.

 

[애자일 개발] - 애자일 소프트웨어 개발 선언

[애자일 개발] - 스크럼 개발 적용

[애자일 개발] - 칸반 이란?

[애자일 개발] - 칸반 개발