일단 우리 S/W팀에서는 엑셀을 칸반 보드로 사용한다. 그리고 매일 자신이 가지고 있는 이슈에 대해서 상태를 업데이트했다. 따라서 칸반 보드의 정보를 취합하면 각 이슈의 개발 시작 날짜, 개발이 끝난 날짜를 알 수 있으므로 해당 이슈의 development cycle time을 알 수 가 있다. cycle time은 lead time과는 다른 개념으로 그림으로 설명하면 하기와 같다.
보통 칸반을 수행하면 해당 결과물들은 하기와 같은 cumulative flow diagram으로 표현을 한다.
cycle time에 대한 히스토그램도 하기와 같이 그리기도 한다.
일단 위의 그림처럼 프로젝트 기간동안에 처리된 모든 이슈들에 대해서 cycle time 히스토그램을 그려봤다. (하기는 프로젝트의 실제 데이타가 아님, 분석 과정을 보여주기 위한 dummy 데이타임, 실제 데이타는 회사의 자산이므로 올릴 수 없음)
1) 평균 cycle time 6일 : 평균적으로 하나의 이슈를 처리하는데 6일 걸림
2) 중간값 cycle time 6일 : 전체 이슈 중 50%가 6일안에 처리됨
3) cyctime 10일에서 누적 % 값은 95.12% : 전체 이슈중 95.12%가 10일 안에 처리됨
4) cycle time 모드 값 (최빈수) 4,5일 : 전체 이슈중 4,5 일에 처리된 이슈가 가장 많음
그리고 상기의 히스토그램이 보여주는 특징은 하기와 같다.
1) 가장 cycle time이 긴 이슈는 30일
2) 중간에 cycle time이 15일인 이슈도 하나 있음
3) 히스토그램은 multi modal 히스토그램임, 빈도수를 보면 몇개의 peak가 있음 (cycle time 4,5,9 일)
히스토그램을 그려보면 어떤 이슈를 먼저 분석할지가 보인다. 상기의 3가지 특징에 해당하는 이슈들을 먼저 보면 된다. 그래서 상기 3가지 특징에 해당하는 이슈들을 열어서 자세히 본 결과는 하기와 같다.
1) cycle time 30일인 이슈는 feature request (새로운 기능 구현)
2) cycle time 15일인 이슈는 software platform 관련된 이슈임
3) cycle time 9일인 이슈들은 대부분 문서 작업, 테스트 케이스 생성, 유닛 테스트 작성 이슈임
특징들을 분석해보면 이슈들의 타입이나 일의 성격에 따라서 cycle time이 달라진다는 것을 알 수 있다. 따라서 이 이슈들을 서로 분리하여 히스토그램을 다시 그려보면 각 이슈의 타입에 따른 cycle time에 대한 정보들을 더 세밀하게 추출해 낼 수 있을 것이다. 따라서 하기와 같이 일의 성격에 따라서 이슈들을 나누기로 했다.
히스토그램에 나타난 특징을 반영하여 일의 종류를 분류하는데 하기와 같이 크게 3가지로 나누기로했다.
1) software 측면에서 issue type
2) 칸반 service class : 칸반에서 보통 사용하는 일의 분류 기준
3) module 관련성 : S/W platform 관련 이슈인지 아닌지 구분
그리고 각각의 세부 항목들의 설명은 하기와 같다.
1) Change request : 스펙 변경으로 인한 이슈
2) Feature request : 새로운 기능 구현
3) Problem report : 기능상의 문제점을 해결한 이슈
4) intangible class: 우리가 릴리즈하는 S/W의 기능과는 무관한 작업들
5) standard class : intangible class가 아닌 나머지 모든 작업들
6) Application : 코드 변경 사항이 application인 경우
7) S/W platform : 코드 변경 사항이 S/W platform인 경우
위의 카테고리를 조합하여 이슈들을 분류하였다. 크게는 하기와 같이 나왔다.
1) Change request & standard class & application
2) Change request & standard class & S/W platform
3) Feature request & standard class & application
4) Feature request & standard class & S/W platform
5) Problem report & standard class & application
6) Problem report & standard class & S/W platform
7) Intangible class
상기와 같이 총 7개의 카테고리로 이슈들을 분류하여 각각의 히스토그램을 뽑아보았다. 그리고 해당 히스토그램들을 각각 다시 분석하여 보았다 (평균, 중간값, 누적 %, 특이사항).
히스토그램을 통해서 여러가지 정보들을 추출할 수 있다. 그렇다면 이런 정보들을 어디에 사용할 수 있을까? 이 정보들은 하기에 쓰일 수 있다.
1) cycle time이 긴 이슈들의 목록을 쉽게 파악할 수 있으며, 해당 이슈의 분석을 통한 개선 활동을 할 수 있다.
2) 이슈들의 development cycle time을 통해 우리 SW팀의 performance를 알 수 있으며, 이를 가지고 프로젝트 estimation (프로젝트를 완료할 때까지 얼마의 시간이 필요한지 예측하는 활동)이 가능하다.
다음번 포스트는 상기 2가지 사항을 중심으로 작성할 것이다.
0 개의 댓글:
댓글 쓰기