앞에서 기능점수를 활용하여 프로젝트의 추정을 하는 기법을 배웠다. 이를 기초로 기능점수를 프로젝트의 계획과 그 관리에도 활용할 수 있다.
?
프로젝트 추정에서의 질문과 마찬가지로, 구현단계에서의 일정계획을 어떻게 수립하는가? 에 대한 질문에 어떻게 대답하겠는가?
대다수의 개발팀은 개발일정계획을 그리 세밀하게 수립하지 못하며, 그 진척관리 또한 명확하게 관리하지 못한다. 또한 대부분의 프로젝트는 WBS라는 Work 기반의 일정계획을 수립하고 있으며, 프로젝트에서 가장 많은 기간을 차지하는 구현단계는 WBS 상에서 몇줄의 일정으로 표현될 뿐이다.
?
또한 진척도의 보고시 진척도를 산출하는 기준 또한 매우 모호하게 표현된다. 대부분의 프로젝트관리자는 WBS상의 활동이 수행되었는가를 보고 진척도를 산출한다. 하지만, 실제 개발 과정에서 “어떤 활동을 수행했는가”는 실제 “구현이 얼마나 진행되었는가”에 대한 답을 주지는 못한다.
구현에서의 가치는 활동의 수행이 아니라 실제 기능의 완료에 있기 때문이다. 활동의 결과는 “고객의 가치(기능)”가 얼마나 실현되었는지를 전혀 측정할 수 없으며, 이는 개발프로세스에서 관리할 필요가 없음을 의미한다.
(무슨 활동을 얼마나 했는가는 실제 프로젝트를 얼마나 수행하였는지에 대한 척도가 될 수 없다. 또한 활동을 얼마나 했는지는 측정할 수도 없다.)
?
이전의 WBS방식의 진척도 산출은 활동의 수를 정하고 활동을 완료한 개수로 진척도를 정하는 방식이었다. 사실 이 방식은? “개발의 진척”의 의미로 사용하기에는 무리가 있다. 활동의 완료라는 것은 실제 개발의 진척도와는 무관하기 때문이다.
(WBS에 의한 진척을 보고받아본적이 있는가? 프로젝트가 시작되기도 전에 수립된 WBS 계획과 프로젝트 진행시의 진척은 거의 일치한다. 이 것은 둘중 하나다. 계획수립을 한 사람이 “예언자”이던지, 계획에 결과를 의도적으로 일치시켰던지)
?
현대적인 개발분야의 전반적인 패러다임은 “기능” 중심으로 전환되고 있다. 지금 설명하고 있는 기능점수와 관련된 일련의 교육자료 또한 이 “기능”중심의 개발사상을 그 기반으로 하고 있다.
?
즉, 진척도는 고객이 요구한 기능이 얼마나 완료되었는가에 의하여 산출되어야 하며, 이는 업무의 수행여부와는 별개이다. 따라서 구현단계에서의 진척은 반드시 “기능의 구현완료”로 측정되어야 하며, 이는 기능점수를 기준으로 측정할 수 있다.
?
|
참고 |
|
파킨슨 법칙 : 일의 양은 주어진 시간에 따라 늘어난다. 활동단위의 업무지시는 활동 자체를 줄이거나, 활동을 의도적으로 늘리는 결과를 가져온다. 즉, 실제 업무의 완료여부와 관계없이, 활동에 주어진 일정이 되면 끝나버린다. 거꾸로, 실제 업무가 완료되었더라도, 일정이 끝나지 않은 경우, 해당 업무는 완료계획일까지 지속된다. |
?
최근 들어 소프트웨어의 대가기준은 이전의 인건비방식(활동을 한 사람에 대한 대가)에서 기능점수방식(소프트웨어의 기능의 규모)로 변경되었다. 이는 “가치”의 기준이, 더 이상 의미 없는 활동을 기준으로 하는 것이 아니라 실제 “실현한 가치”를 중심으로 이동하였음을 의미하는 것으로 소프트웨어 분야의 특성을 반영하고자 하는 노력의 결과이다.
?
즉, 이것은 소프트웨어 회사의 대가에만 국한된 것이 아니라, 모든 가치 기준을 “기능?가치”를 기준으로 관리하여야 함을 의미한다.
(소프트웨어 개발이 활동 및 활동에 투입된 자원의 양으로 결정되지 않음은 모두가 공감한다.)
?
소프트웨어 기업은 기능에 의하여 대가를 지불 받고 소프트웨어의 개발과정은 기능에 의하여 그 계획이 수립되어야 한다. 그래야만이 실제 대가에 대한 “실현결과”를 측정할 수 있다. 기존의 WBS는 소위 “머리수”에 의한 대가기준을 사용하던 시절에 적합하다.
?
이 개념은 그 소프트웨어 개발과정에 참가한 개발자의 성과 측정에도 그대로 적용된다.
이전의 활동에 대한 대가 ? 활동에 의한 계획 방식을 사용했을 경우, 그 성과는 “활동의 양”이 되어야 한다. (공수라고 불리우는) 즉, 기업의 이윤이 활동에 의하여 분해되고 그 분해된 활동에 투입된 성과(시간)에 의하여 분배되는 것이다.
?
하지만 기능에 의하여 대가가 산정되고, 기능에 의하여 계획이 수립된 경우, 그 성과는 개발자가 개발한 “기능의 수”가 된다.
위에서 설명한 바와 같이, 일정계획의 수립과 수립된 계획에 의한 진척도 측정에 기능점수를 활용할 수 있다. 기능점수는 이미 고객의 요구사항이 “단위기능”으로 분해되어 있으며, 각각의 기능의 “규모”또한 점수로 표현되어 있다. 즉, 기능점수는 개발의 양으로 볼 수 있으므로 이 양을 각 개발일정단위에 분배하고, 실제 개발된 양을 측정하여 객관적인 진척도를 수치로 표현가능하다.
?
|
기능점수를 일정에 분배하고, 완료된 기능점수를 측정하여 진척을 관리한다. |
?
즉, 프로젝트 추정에 의하여 산출된 일정과 투입자원을 기능점수에 의하여 각 개발주기에 분배한다. 개발주기는 개발일정에 따라 적절히 분할하여 수립하고, 각 개발인력의 개발속도를 고려하여 주당 개발 기능점수를 판단하여 배분한다.
?
[개발주기계획]
|
개발주기 |
시작일 |
종료일 |
|
1주기 |
2012-08-27 |
2012-08-31 |
|
2주기 |
2012-09-03 |
2012-09-07 |
|
3주기 |
2012-09-10 |
2012-09-14 |
?
[자원계획]
|
개발자 |
개발속도 |
|
개발자1 |
10.0 |
|
개발자2 |
9.5 |
?
[개발계획]
|
기능 |
기능점수 |
담당자 |
개발주기 |
기능점수합계 |
|
기능1 |
10.0 |
개발자1 |
1주기 |
34.4 |
|
기능2 |
3.9 |
개발자1 |
1주기 | |
|
기능3 |
4.9 |
개발자2 |
1주기 | |
|
기능4 |
15.6 |
개발자2 |
1주기 |
?
위와 같이 그 규모가 측정된 각 기능에 대하여 기능별로 개발담당자와 개발일정을 지정하면, 어떤 개발자에게 또는 어떤 주기에 부하가 많은가를 미리 검토할 수 있고, 검토 결과에 의하여 개발계획을 보정할 수 있다. 또한 수치에 의한 명확한 일정별 개발범위가 결정되어, 실제 구현결과를 측정함으로써 계획대비 실제 진척율을 매우 객관적으로 측정하여 산출할 수 있게 된다.
?
즉, 실제 가치 있는 기능의 완료를 기반으로 계획을 수립하고, 그 진척도를 측정할 수 있다. 또한 이 기능점수는 실제 개발원가로 바로 환산되므로, 실제 완료된 진척을 돈으로 측정할 수도 있다.
?
이러한 방식을 사용할 경우, 구현의 진척도는 “완료”만을 기준으로 삼는다. 일부완료는 고려하지 않으며 반드시 “구현완료”된 기능을 측정하는 것이 좋다. 또한 계획대비진척을 Agile에서 즐겨 쓰는 번다운 차트를 이용하여 표현하면, 시각적으로 프로젝트의 진척도와 위험도를 쉽게 확인할 수 있다.
