타당성 검토
->계획
->요구사항 분석
->설계
->구현
->테스트
->유지보수
순으로 단계가 진행이 된다.대응하지 못한 이슈들이 엉키게 되면 아래와 같은 문제점들이 발생하여 프로젝트에 참여한 모든 구성원들이 어려움을 겪게 된다.
칸반 방식의 핵심은 WIP(Work In Progress) 제한이다.
칸반과 스크럼의 가장 두드러지는 차이는 칸반은 스크럼처럼 스프린트처럼 약속된 업무 종료일이 없다는 것이다.
칸반도 스크럼과 마찬가지로 새롭게 들어온 이슈카드에 대해 시간을 추정하는 작업을 한다.
그러나 스크럼과는 달리 플래닝을 하는 날이 따로 정해져 있지 않고 매일 오전 약 15분 정도 진행되는 데일리 미팅에서 새롭게 들어온 이슈카드의 기능을 구현하기 위한 요구사항을 분석하고 시간이 얼마나 걸릴지 플래닝을 진행한다.
Backlog
에 쌓이게 되고, 연속적인 일의 흐름에서 급한 작업단위의 순서대로 In progress
에 이슈카드를 넣고 처리한다.In progress
에 동시에 넣고 진행할 수 없으며, 이는 실제 작업하는 방식을 고려하더라도 불가능하다.In Progress
에 넣을 수 있는 이슈카드의 개수가 제한되는데, 이를 WIP(Work In Progress) 제한이라고 부른다.Backlog
에서 이슈카드를 In Progress
로 옮겨와 작업을 진행할 수 있다.Hotfix
는 지금 당장 수정해서 실제 돌아가는 Production 서비스에 바로 배포를 내보내야 하는 플래닝 시점에 미리 예측되지 않았던 긴급한 버그나 오류 이슈를 뜻한다.Hotfix
를 다루는 관점이 다르다.Hotfix
수정을 하고 배포를 하는 sustainment 업무를 돌아가며 맡기도 한다.Hotfix
가 아니라면, 스프린트 진행 중 발생하는 모든 Hotfix
는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 스프린트의 업무가 된다.Hotfix
를 바로바로 처리할 수 있다.