칸반시스템의 일정관리
상품출시 이후 유지보수 및 운영모드로 전환하면 출시된 상품에 대한 개선점 또는 결함수정이 수시로 발생한다. 때문에 운영단계에서는 보통 결함은 우선 조치하고 나머지 상품 개선사항은 상품관리자가 결정하는 우선순위에 따라 개발하는 것이 일반적이다. 따라서 운영단계에서는 개발할 범위를 정한 뒤 이를 스프린트에 할당하는 것이 아니라, 백로그에 있는 우선순위 중 이번 달(또는 금주)에 무엇을 개발할 것인가를 결정하는 방식의 개발이 적합할 수 있다.
칸반시스템 일정관리의 특징은 다음과 같다.
- 진행중 업무개수를 제한한다.
진행중 업무개수를 제한하는 이유를 이해하기 위해서는 리틀의 법칙(Little’s Law)을 이해해야 한다. 리틀의 법칙은 다음과 같다.
공간 내에 머무는 객체수(L) = 객체의 공간유입량(r) X 객체가 머무는 시간(W)
상품개발에 비유하면 L은 진행중 작업, r은 개발가능한 용량(capacity), w는 리드타임이다. 리드타임을 줄이기 위해서는 그림 *과 같이 진행중 작업의 개수를 줄이거나 단위시간당 처리용량을 늘려야 한다.
리틀의 법칙을 적용한 리드타임 단축 방안리틀의 법칙에 관한 이해를 돕기 위해 ‘고속도로 차량 주행시간’, ‘대학교 수강신청 응답시간’, ‘상품요구사항 개발 리드타임’을 단축하는 방안을 설명하면 아래 표와 같다.
리드타임 단축 예적정수준의 리드타임을 유지하기 위해서는 진행중 업무개수를 적정수준으로 유지해야 한다. 진행중 업무개수는 상품개발팀의 과거데이터를 참조하여 결정한다. 진행중인 업무개수는 개발유형에 따라 적정비율의 유지할 수 있다. 업무 유형으로서는 신규기능, 오류 및 성능향상, 기능개선, 영업지원등으로 구분할 수 있다. 업무 중요도 관점에서는 긴급요청, 고정일정, 표준, 기타로 구분할 수 있다. 유형별 진행중 업무의 비율은 상품개발조직의 특성에 따라 달라진다.
진행중인 업무개수를 제한하면 백로그에 있는 대기 요구사항들은 증가할 수 있다. 우선순위가 낮은 요구사항들은 6개월이 지나도 백로그에 남아 있을 수 있는데, 백로그에 일정기간 이상 대기한 요구사항은 삭제하는 것이 좋다. 왜냐하면 다른 요구사항에 비해 지속적으로 우선순위가 낮았기 때문이다. 요구사항이 중요해지면 누군가 다시 등록할 것이다. 길어지는 백로그를 관리하는 것보다 삭제하고 다시 등록하는 것이 효율적이다. 관리에 집착하는 조직은 장기 대기중인 요구사항을 삭제하지 못하는데 이는 집에서 쓰지 않는 짐을 버리지 못해 집안이 어지러워 지는 것과 같다. 요구사항을 삭제하는 기준 개월수는 해당 조직의 요구사항 변동성에 반비례한다. 즉, 요구사항의 변동성이 높다면 3개월 기준으로 백로그를 정리하는 것이 좋다.
- 업무진행 현황을 시각화한다.
칸반보드는 칸반시스템의 대표적인 특징이며 칸반보드 적용을 칸반시스템 적용으로 착각하는 경우도 많다. 칸반보드의 형식은 조직이나 상품개발팀의 상황에 따라 결정한다. 칸반보드는 화이트보드 또는 툴을 활용하여 수행중인 작업을 구분하면 전체 작업현황을 직관적으로 쉽게 파악할 수 있는 장점이 있다. 칸반보드에 부착하는 것은 신호카드(Signal card)라고 하는데 하나의 신호카드는 하나의 상품요구사항(사용자 스토리)을 의미한다. 신호카드의 상태는 진행단계별로 구분하기도 하지만 업무의 중요도에 따라 구분하기도 한다. 업무의 중요도에 따라 신호카드의 색깔을 달리하는 것이 바람직하다.
칸반보드 예<칸반>(2014)에서는 업무중요도에 따른 관리방안을 다음과 같이 설명한다.
• ‘긴급요청 항목’의 진행중 업무제한은 1이고 담당자는 긴급요청을 즉시 당겨야 한다. 긴급요청을 처리하기 위해 미리 수용량을 남겨두지 않는다.
• ‘고정출시일 항목’은 출시할 수 있는 시점이 가까울때까지 대기에 머문다. 고정출시일 항목은 표준항목보다 먼저 당긴다. 고정 출시일 항목은 진행 중 업무제한을 지켜야 한다. 고정출시일 항목이 급해지면 긴급요청으로 바꾼다.
• ‘표준항목’은 선입선출 방식을 사용한다. 공수나 처리시간 결정을 위한 추정을 수행하지 않는다.
• ‘기타항목’은 위의 세가지 항목을 선택할 수 없을때 당겨올 수 있다. 기타 항목은 긴급요청을 처리하는 동안 잠시 중단한다. 무형 클래스 항목에는 서비스 수준 합의가 필요 없을 수 있다.
업무중요도를 활용하면 계획수립도 단순해진다. 업무 중요도는 개발 우선순위를 결정하며, 상품개발팀에서 당김방식으로 개발할때 위험도 작아진다. 업무중요도의 유형은 조직원들이 쉽게 암기 할 수 있는 3~5개가 적합하다.
- 개별업무의 계획준수보다 평균 리드타임을 중요시한다.
상품 출시후 운영 및 개선단계에서는 일회성의 계획보다 안정적 개발속도가 중요하다. 비슷한 규모의 업무를 합의한 리드타임 이내에 릴리즈 할 가능성이 일정수준(예:80%) 이상이라면 고객이나 상품관리자도 계획과 조정을 위해 시간을 낭비할 필요가 없다. <칸반>(2014)에서는 칸반의 간편한 계획수립을 다음과 같이 설명한다.
매주 월요일 아침 우선순위 결정을 위한 회의를 효율적으로 진행하기 위해 목요일아니 금요일에 대기열에 빈칸이 몇 개 생길지 예상해보고 그 수를 알려주는 메일을 보낸다. 추정, 비즈니스 계획준비, 백로그로 부터 후보를 선정하는 활동모두 우선순위 처리 비용이다. 이 비용은 낮게 유지하는 것이 바람직하다.
칸반 시스템에서는 ‘공정 준수율’이나 ‘공정 진척률’보다 ‘평균 리드타임’과 ‘리드타임 준수율’을 중요시하며, 상품개발팀과 이해관계자와 합의한 서비스수준 합의(SLA Service Level Agreement)를 기준으로 성과를 평가하는 것이 바람직하다. 칸반방식은 고객 또는 이해관계자와 신뢰를 기반으로 장기적인 관계를 맺는 개념이다. 따라서 칸반방식을 적용하기 위해서는 고객 또는 이해관계자에게 적정수준의 품질을 갖춘 적정량의 결과물을 지속적으로 제공받을 수 있다는 믿음을 제공해야 한다. 또한 진행중 업무개수 제한은 고객 또는 이해관계자와 함께 결정해야 한다. 고객의 신뢰가 없으면 상품개발팀이 당기는 것이 아니라 고객이 미는 방식으로 바뀔 것이다.
- 당김(pull)방식으로 개발할 상품 요구사항을 결정한다.
당김(pull)과 미는(push)방식의 개발결정은 큰 차이가 있다. 당김방식은 상품개발팀의 처리속도에 맞게 업무를 수용하고, 미는방식은 상품개발팀의 처리속도를 고려하지 않고 업무를 밀어넣는다. 당김방식 적용은 진행중 업무수행 개수를 제한하는 전제조건이다. 당김방식에서는 하나의 상품 요구사항을 완료한 후 다른 상품 요구사항을 추가한다.
- 변동을 최소화한다.
안정적인 리드타임을 유지하기 위해서는 변동을 최소화해야 한다. 다양한 상품개발 요구사항을 한 가지 유형으로 관리하면 일정과 공수의 변동성이 커진다. 따라서 요구사항 유형을 몇 가지로 구분하여 유형별로 평균과 분산을 예측하고 관리하면 전체 요구사항 개발 리드타임의 예측가능성도 높아진다. 상품개발 요구사항 유형이 내부변동 요인이라면 모호한 요구사항, 불규칙한 흐름, 시장변동, 직원이직 등은 외부 변동요인이다. 외부변동은 상품개발팀이 통제 할 수는 없지만 외부변동이 높아지면 업무의 예측가능성은 잦아진다.
지금까지 설명한 칸반시스템의 일정관리 특징을 요약하면 아래 그림과 같다.
https://brunch.co.kr/@kbhpmp/160
