[에자일]불확실성과 화해하는 프로젝트 추정과 계획

불확실한 것 투성이인 S/W 개발을 정량화 하여 언제 완료 된다고 감히 말한다는 것은 참으로 어려운 일이다.
더군다나 본인이 직접 개발을 하는 상황이 아니라 여러 팀원들과 진행하면서 "다른 사람이 이일을 얼마만에 해 낼 것이다" 라고 추정하기란 더더욱 어렵다.

프로젝트 미팅을 들어가면 항상 이런 패턴이다.

프로덕트 기획자: 우리 이러한 제품을 만들어야 하는데요. 개발실에서는 어떻게 생각하시나요.
             ( 프리젠테이션을 멋지게 보여준다.)
개발자들 : <속으로>허걱~ 완전 상상의 나래를 펼치셨네.
개발자들 끼리 의견 분분~
개발자 중 한사람: 그거 음 이렇게 하면 되지 않을까요?
                    (솰라 솰라~~ 구현에 대해서 자신이 생각하는 방향을 열씸히 예기 한다.)
다른 개발자: 음 그런데 지금 구조에서는 잘 안될것 같은데 새로 뭔가 만들거나, 지금껄 많이 엎고 작업 다시 하는 것도 생각해봐야 겠네요.

그리고 한참동안 개발자들은 나름대로의 상상속에 빠져서 자기가 생각하는 구현 방법, 문제점 등등을 즉시 예기하기 시작한다. ㅎ
이미 설계는 시작되었다~~~!!!!
이 와중 찬물을 끼언는 소리~~~~

프로젝트 리더: 그럼 언제까지 돼?
개발자들 : ...

참으로 언제까지 된다는 예기를 하기가 점점 힘들어지는 것이 개발자의 입장이다..!!!
경험이 쌓이면 쌓일 수록 쉬워야 되는 것인데도 불구하고 점점 요구되는 S/W의 스팩도 높아지고, 복잡도도 높아지고 있어서 결정하기가 점점 어려워지게 된다.

이런 업무 범위 추정과 계획은 프로젝트의 성공과 상품화 전략을 위해서 매우 중요한 부분이다.

에자일에서는 이러한 업무의 process를 나누는 단위를 "스토리","이터레이션" 이라는 이름으로 사용하고있다.

스토리는 업무의 조각에 해당하는 것이고, 이터레이션은 수행기간을 단위화 한 것이다.

프로젝트의 초기 셋업에서 가장 중요한 것은 개발 일정 산출일 것이다.
하지만 개발일정이라는 것은 각 모듈의 개발 기간과 투입 리소스를 산출해야 하는데 이를 정확히 산출해 내서 계획을 새운다는 것은 사실상 리스크를 더 갖게 만든다.
이유는 개발 기간을 산출하는 사람이 개발자라 할지라도 개발 기간중 어떻한 일이 발생할 것인 지도 모르는 상황에서 이건 언제 끝나고 이건 언제 끝난다 라고 답하는 것은 힘들기 때문이다.
또 만약 개발자가 개발해본 경험이 없는 모듈이라고 한다면 사실 개발 기간을 정리 하는 것도 무리일 수가 있다.

그럼에도 불구하고 프로젝트가 움직 이기 위해서는 개발팀은 개발기간을 산출 해야 한다.

이런 확실하지 않은 개발 기간 산출을 "추정"이라 하고 이를 얼마나 효과적으로 가능한한 현실 적으로 정리 하는 가를 "추정의 기술" 이라 하겠다.
(마치 "싸움의 기술" 같은 느낌?ㅎ )

우선 프로젝트의 기간을 추정하는 작업은
가장 먼저 프로젝트의 규모를 추정하는 작업에서 시작된다.
만약 이전에 이미 팀의 프로젝트 진행 속도를 알고 있다면, 추정하기가 편해진다.
스토리 단위로 개발을 진행 한 경험이 있다고 한다면, 팀의 속도가 더욱더 분명해진다.

이로 인해 개발전에 프로젝트 전체의 추정치가 나오게 되고, 실제 개발에 들어가게 되면, 이 추정치를 바탕으로 실제 개발 범위와의 오차를 조절해야 한다.

예를 들면 , 이러한 것이다.

자동 운전 시스템을 개발하고자 할때 Story를 다음과 같이 정했다고 하자.
운전 시스템 모듈 100점
도로 주행 모듈 150점
주행 경로 모듈 50점

이렇게 총 300점의 개발 프로젝트 라고 초기에 추정했다고 하자. 그래서 이전에 개발팀의 속도로 보아 100 점을 4회의 이터레이션에 처리했다면 약 12회의 이터레이션에 해결할 수 있는 프로젝트 라고 생각 할 것이다.(1회에 25점의 스토리를 처리했다.)

그런데 막상 개발을 시작하고 보니, 1회 이터레이션에 10점 정도의 스토리 밖에 처리가 되지 않았다 라고 한다면, 우리는 15점을 처리 못하고 남겨 놨다는 것을 알게된다. 때문에 우리 개발기간은 1.5배 길어질 것이라는 것을 예상 할 수 있다.

그렇다면 초기 추정치가 쓸모 없는 것이 되는가?
그렇지 않다! 그렇게 되도록 둬서는 안된다.
무슨 의미인가 하면 우리는 흔히 개발 spec을 산출할때 기간을 중심에 두는 경우가 많다.
이건 몇일 걸리고 이건 몇일 걸리고, 이런 식으로 말이죠.
이렇게 생각해서 스토리에 점수를 줬다고 한다면, 많은 부분이 다시 수정되어야 한다.
그러면 스토리 점수는 무엇이어야 하는가?
일의 크기로 생각해야 한다. 일의 범위는 모듈의 개수,class의 수, 코드량, 난이도, 등등을 생각해서 점수를 줬다면
전체적인 일의 크기가 정해지게 된다. 일의 크기가 얼마인가와 이를 해결하는데 얼마가 걸리는 것인지는 다르다.

일의 크기를 단위로 나누게 되면, 각 스토리 간의 난이도 비교가 된다.
즉 10의 점수를 갖는 스토리는 5의 점수를 갖는 스토리보다 배는 어렵다는 것이다.
또 10의 점수를 갖는 스토리는 20의 점수를 갖는 스토리보다 반은 쉽고 간결하다는 것이 된다.

이는 10의 점수를 갖는 스토리가 얼마가 걸리는가 하는 문제와는 별개라는 것을 다시한번 강조하고 싶다.

이전 프로젝트에서는 25의 점수가 1 이터레이션이 걸렸지만 , 이번 프로젝트에서는 10의 점수가 1이터레이션이 걸릴 수도 있다는 것이다.
(대부분 반대의 경우가 많다. 이유는 프로젝트 경험이 쌓일 수록 개발 속도는 빨라지기 때문에 지난번 프로젝트에서는 20점이 1 이터레이션이었지만 이번에는 30점을 1이터레이션 내에 끝낼 수 있을 것이다.)

또 점수를 측정함에 있어서도 개발자의 질이 향상되면 그만큼 점수도 유동적으로 변하게 된다.




추정치의 값은 이런 값을 사용해라.

1,2,3,5, 그리고 8 
1,2,4, 그리고 8  큰 단위의 작업에 대한 추정을 할때 , 이 값을 사용하게 되면 보다 큰 불확실성에 대한 대처가 쉽다.

숫자의 간격이 있게되면, 장점은 이렇하다, 3보다는 크고 4보다는 작은 약 3.5 정도 되는 것 같은 스토리의 경우에, 3이라고 작성하면 된다.
이렇게 함으로 해서 복잡해지는 스토리 점수를 막을 수 있다.
실제 우리 업무가 3이라고 작성했지만 3.5가 될 소지가 매우 크기 때문이다.

'0'이라는 값을 추정치에 포함하겠다라고 하면 어떤 일을 0으로 정할 것인지를 고민해야 한다.
(실제로 0을 포함 시키면 프로젝트 추정에 많은 도움이 될 수 있다.)

0이라는 값은, 작업은 필요하지만 매우 간단하여 프로젝트 수행에 영향을 미치지 않는 것을 의미한다.
(또는 자동으로 해결되는것 - 이런 경우는 매우 적지요)

0이라는 값을 사용함에 있어서 먼저 팀원들의 인식을 확실히 해야 한다.
0 이라고 해서 일이 없는 것이 아니기 때문에, 0점짜리 스토리를 한꺼번에( 13x0해서 한 이터레이션 안에서 ) 처리 할 수는 없다.
0은 공짜 점심처럼 한 이터레이션 안에 처리 할 수 있는 작은 업무이지만, 공짜 점심은 개수 재한이 있다는 것을 인식 시킬 필요가 있습니다.
만약 이렇게 많은 0점짜리 스토리를 한번에 처리하고 싶다면, 이들을 묶어서 1점 이상 되는 이터레이션으로 묶어야 합니다.