91.프로젝트 진척률 관리방안
성공적인 소프트웨어 신상품 개발가이드
진척률은 프로젝트 상황을 가장 간결하게 대표하는 숫자이지만 현장에서 진척률에 대한 신뢰도는 그리 높지 않다. 상품개발팀에서 멀리 있는 사람일수록 프로젝트 상세 내용을 파악하기 힘들기 때문에 프로젝트 진척률에 대한 정보 의존도가 높다. 이번 섹션에서는 프로젝트 진척을 파악하는 두 가지의 대표지표인 ‘공정진척률’과 ‘공정준수율’에 대한 기본개념, 진척률 활용시 유의할 사항, 애자일 방법론에서 프로젝트 진척을 관리하는 기법인 번다운 차트와 간반보드에 대해 설명한다.
1) 프로젝트 진척률을 평가하는 두 가지 지표
상품개발과 관련된 이해관계자들이 궁금해하는 진척률에는 두 가지 개념이 있다.
- 완료된 업무의 비율 : 특정시점까지 전체 업무 중 몇 퍼센트를 완료하였는가?
- 계획준수 : 특정시점까지 완료하기로 계획된 업무를 완료하였는가?
필자는 전자를 ‘공정진척률’, 후자를 ‘공정준수율’로 정의한다.
공정전척률의 측정식과 유의사항은 다음과 같다.
① 공정진척률 = 특정 시점까지 완료한 업무의 양 / 전체 업무의 양
공정진척률을 측정하기 위해서는 ‘업무의 양’을 무엇으로 측정할지 결정해야 한다. 소프트웨어 상품개발의 ‘양’을 측정하기 위해 사용 가능한 후보는 다음과 같다.
• 상품 요구사항의 수 (백로그 수)
• 상품 요구사항의 규모 (예:스토리 점수)
• 작업의 수 (작업: 상품요구사항 구현을 위한 활동)
• 작업의 기간
• 작업의 원가(또는 공수)
• 작업에 부여한 주관적 가중치
애자일 용어를 사용하면 공정 진척률은 ‘백로그 진척률’ 또는 ‘스토리 점수 진척률’이 된다.
상품 요구사항의 규모를 업무의 양으로 측정하는 것이 바람직하지만 초기 분석/설계 단계에서는 상품 요구사항을 개발하지 않기에 인력을 투입하지만 진척률이 나오지 않는 단점이 있다. 따라서 아래 그림과 같이 두 가지를 혼합하여 적용하는 것도 고려할 수 있다. 예를 들어 분석단계에서는 작업규모를 기준으로 진척률을 평가하고, 요구사항을 개발하는 단계에서는 구현된 요구사항의 크기에 따라 진척률을 평가하는 방식이다.
진척률 측정은 객관적인 정답은 없기에 조직 내에서 약속한 기준에 따라 측정하면 된다. 정확하고 정밀한 측정을 위해 많은 시간을 소비하는 것은 프로젝트 관리에 별로 도움이 되지 않는다. 정밀한 저울로 몸무게를 잰다고 다이어트에 큰 도움이 되지 않는 것과 같은 이치이다. 진척률 측정공식이 어느 정도 합리적이라면 진척관리의 목적에 위배되지 않는다. 공정 진척률은 0퍼센트에서 시작하여 100퍼센트가 되면 프로젝트가 종료되는 지표로 업무수행에 따라 상식적인 수준에서 진척률이 증가하면 충분하다. 예를 들어 상품 요구사항의 절반을 개발했으면 40% ~ 60% 의 진척률이면 큰 문제가 없다. 측정기준이 객관적이고 데이터 취합이 용이한 기준을 사용하면 된다. 가장 간편한 방법은 요구사항 또는 작업의 개수를 기준으로 평가하는 것이지만, 업무의 난이도나 규모를 고려하지 않기에 요구사항은 스토리 점수로 업무의 양을 평가하고 작업은 계획MM로 업무의 양을 평가하는 것이 바람직하다.
공정진척률은 프로젝트 계획 대비 성과를 판단할 수 있는 지표가 아니다. 프로젝트의 계획 대비 진척성과를 파악하기 위해서는 공정준수율을 측정해야 한다.
② 공정준수율 = 특정시점까지의 실적진척률 / 특정시점까지의 계획진척률
공정준수율이 100퍼센트 이하면 계획대비 지연된 작업이 있다는 것을 의미한다. 공정준수율을 해석할 때 유의할 사항은 다음과 같다.
- 프로젝트 초반의 공정준수율과 프로젝트의 후반의 공정준수율은 해석을 달리 해야 한다
프로젝트 초반에는 계획진척률이 작기 때문에 약간의 지연도 공정준수율에 크게 영향을 미치며 프로젝트 후반부에는 이와 반대이다. 대형 프로젝트에서 프로젝트 후반부의 공정준수율이 99퍼센트인데도 실제로는 심각한 상황인 경우가 많다.
- 공정준수율외 지연일을 보조지표로 같이 활용해야 한다
A 프로젝트의 공정준수율이 95퍼센트이고 B 프로젝트의 공정준수율이 98퍼센트라고 했을 때 항상 B 프로젝트의 진척이 A 프로젝트보다는 좋다고 볼 수 없다. 정확한 평가를 위해서는 어떤 업무가 어느 정도 지연중인지를 파악해야 한다. 더 중요하고 어렵지만 작은 업무가 지연되는 경우, 표면상의 공정준수율은 좋아 보이지만 실제 일정에 미치는 영향은 더 클 수 있다. 공정준수율의 단점을 보완하는 지표로 마일스톤 지연일을 활용할 수 있다.
- 공정준수율은 과다평가 되기 쉽다
공정준수율이 실제 상황보다 좋게 평가되기 쉬운 이유는 첫째, 많은 프로젝트의 공정준수율이 95퍼센트 이상이기 때문에, 이는 100점 만점에 가깝다는 느낌을 주기 쉽다. 둘째, 각 작업의 완료 시 품질을 확인하지 않으면 공정준수율에 거품이 끼기 쉽다.
- 계획일을 변경하면 공정준수율이 좋게 보일 수 있다
지연되는 작업의 계획일을 변경하면 지연작업이 정상적인 작업이 된다. 따라서 프로젝트 일정의 베이스라인 관리를 철저하게 하지 않으면 공정준수율이 왜곡될 수 있다.
- 업무가 추가되면 공정진척률이 낮아질 수 있다
업무가 추가되면 ‘전체 업무의 양’이 증가하고 지표식의 분모가 커지기 때문에 공정진척률은 낮아진다. 업무가 추가될 때 지난 주 대비 공정진척률이 낮아져 프로젝트 관리자는 곤혹스러운 상황에 직면하는데 이것을 반영하지 않으면 팀원들은 공정진척에 반영되지 않는 유령 업무를 수행하게 된다.
2) 프로젝트 진척률을 관리할 때 유의할 사항
- 프로젝트 진척률은 프로젝트 현황 이해를 위한 참조자료로 활용한다.
프로젝트 진척률은 프로젝트 현황에 대한 참고 또는 보조지표로 활용해야 한다. 프로젝트의 정확한 진행상황은 지연되는 업무의 내용, 완료된 업무의 품질, 상품개발 팀원의 팀워크와 사기 등을 종합적으로 평가해야 한다. 공짜 점심은 없다. 공정진척률 하나만으로 프로젝트의 진척상황을 파악하려는 욕심을 버려야 한다. 공정진척률이나 공정준수율은 잘 관리하면 유용한 지표임에는 분명하지만 프로젝트 진척상황을 이해하는 참고지표로 국한해야 한다.
- 공정진척률 90%이상이 되면 정체현상이 발생한다.
그림 *은 공정진척률의 신뢰도와 관련된 문제를 명확하게 보여주고 있다. 90퍼센트까지는 아주 진도가 잘 나가다가 기울기가 낮아지기 시작하여 98퍼센트에서는 진척률의 기울기가 (-)가 되기도 한다. 남은 2%의 진척을 올리기 위해서는 전체 공수의 20%를 투입해야 할 수도 있기에 ‘끝나지 않는 95% 신드롬’(Never ending 95% 신드롬)이라는 말도 있다. 물론 이것은 일부 이슈 프로젝트의 과장된 이야기이지만 프로젝트 공정진척률이 부정확하다고 믿는 경영층이나 프로젝트 관리자가 많다.공정진척률이 90%를 넘어서면 프로젝트 완료를 위한 실행항목을 상세하게 정의하고 관리하는 것이 훨씬 효과적이다
- 진척률을 측정하고 관리하는 것 보다 진척률을 좋게 만드는 방법에 집중한다.
많은 프로젝트가 주간회의 때 공정현황을 숫자로 보고한다. 그러나 공정현황을 숫자로 보고하지 않는다고 해서 상품 관리자 또는 경영층이 상품개발의 진행 상태를 모른다는 것을 의미하지는 않는다. 다이어트를 하기 위해 주기적으로 몸무게를 측정하는 것은 필요하지만 몸무게 측정을 자주한다고 다이어트가 잘 되는 것은 아니다. 중요한 것은 다이어트를 하기 위한 식단조절과 운동이다. 프로젝트의 중요한 상황을 꿰고 있는 상품관리자와 프로젝트 관리자는 숫자에 집착하지 않는다. 숫자만 보는 사람들은 숫자를 좋게 만들라는 지시 말고는 할 수 없다.
숫자에는 과거와 현재의 숫자와 미래의 숫자가 있다. 과거와 현재의 숫자는 과거활동의 결과다. 과거 추이에 집착하여 책임소재를 따지거나 질책의 용도로 숫자를 활용해서는 안 된다. 중요한 것은 미래의 숫자다. 미래의 숫자를 좋게 하기 위해 지금 할 수 있는 일이 무엇인가에 집중해야 한다.
- 개별 작업의 완료기준을 명확하게 한다
업무를 관리하기 위해서는 작업의 완료기준에 대한 공통된 이해가 필요하다. 서버와 데이터 연계가 필요한 클라이언트 프로그램은 관련된 서버 프로그램도 완료되고 단위 테스트로 수행해야 한다. 그러나 클라이언트 개발자 입장에서는 본인이 할 수 있는 일은 다 했기에 완료로 볼 수도 있다.
진척이 좋은 것을 나쁘다고 인식하는 오류와 진척이 나쁜 것을 좋다고 인식하는 오류 중 프로젝트 관리자가 피해야 할 오류는 무엇일까? 당연히 후자의 오류일 것이다. 따라서 프로젝트 관리자는 작업완료에 대해 보수적인 기준을 적용하는 것이 바람직하며 위의 경우 서버 프로그램과 데이터 연계 단위테스트까지 완료했을 때 클라이언트 프로그램 완료로 인식하는 것이 바람직하다. 개발자에게 할당된 프로그램 중심으로 완료를 평가하는 것 보다 고객이나 상품요구사항 관점에서 완료기준을 정의하는 것이 바람직하다.
3) 번다운 차트와 번업차트
번다운 차트를 설명하기 위해 간단한 프로젝트 사례를 만들었다. 프로젝트는 3개의 스프린트를 수행하며 각 스프린트는 매일 한 개씩 완료할 10개의 사용자 스토리로 구성된다고 가정하자. 각 스프린트의 10개 사용자 스토리의 스토리점수의 합계는 40점으로 동일하다. 프로젝트(릴리즈) 전체의 스토리 점수는 120점이다. 계산의 편의상 휴일을 고려하지 않았기 때문에 스프린트 계획 완료일은 1월 10일, 1월20일, 1월30일이다. 표 *에 의하면 스프린트 #`1과 #2의 계획대비 실적은 다음과 같다.
- 스프린트 #1 : 1월10일까지 <10개 사용자 스토리, 40 스토리 점수> 완료예정, 1월 10일까지 <8개 사용자 스토리, 24 스토리 점수> 완료
- 스프린트 #2(누계) : 1월20일까지 <20개 사용자 스토리, 80스토리 점수> 완료예정, 1월20일까지 <16개 사용자 스토리, 53 스토리 점수> 완료
번다운 차트는 기간별로 남은 작업(remaining work)의 양을 보여준다. 번다운 차트는 프로젝트(또는 릴리즈) 수준에서 작성할 수 도 있고, 스프린트 차원에서 작성할 수도 있다. 프로젝트 수준의 번다운 차트의 X축은 스프린트가 되고, 스프린트 수준의 번다운 차트의 X축은 일자가 된다.
번다운 차트를 보면 특정 시점기준으로 완료된 작업의 양, 남은 작업의 양, 팀의 속도(기울기가 가파를수록 속도가 높다), 예상되는 출시일자를 파악할 수 있다
프로젝트 수준의 번다운 차트와 스프린트 수준의 #1의 번다운 차트는 아래 그림과 같다.
프로젝트 번다운 차트
스프린트 번다운 차트번업(burnup) 차트는 번다운 차트의 반대로 기간별로 종료된 작업 (completed work)의 양을 누계로 보여준다. 번업차트의 예는 아래 그림과 같다.
참고로 앞의 예에서 사용자 스토리 개수 및 스토리 점수를 활용하여 1/28 기준의 진척율을 계산하면 다음과 같다.
4) 간반보드
앞서 설명한 번다운 차트 혹은 번업 차트는 범위가 정해진 프로젝트 업무의 진척관리에 적합하다. 상품 출시 이후 유지보수 및 운영모드로 전환하면 프로젝트 범위관리의 의미가 약해진다. 왜냐하면 출시된 상품에 대한 개선 또는 결함수정은 수시로 발생하기 때문에 범위관리의 실효성이 없고 주어진 자원으로 개발 우선순위를 잘 결정하면 된다. 보통 결함은 우선 조치하고 나머진 접수된 순서대로 진행하되, 전략고객의 요구사항을 먼저 수행하는 것이 일반적이다. 간반보드는 ‘미착수(To do)’, ‘진행중(In Progress)’, ’완료(Completed)’로 작업 상태를 구분하는 것이 일반적이다. 화이트보드 또는 툴을 활용하여 수행할 작업을 세 가지의 상태로 구분하면 전체 작업현황을 직관적으로 쉽게 파악할 수 있는 장점이 있다.
https://brunch.co.kr/@kbhpmp/160
