Agile Note 여섯 번째
[불확실성에 대한 추적. 01]
# 규모추정
SW개발에서 그 규모와 개발기간을 추정하는 것은 좀 극단적으로 표현하면 장님 코끼리 만지기와 유사한 상황으로 이해할 수도 있을 것 같습니다. 특히 수주를 통한 주문형 SW를 개발하는 경우에는 더욱 어려운 작업입니다. 고객의 입맛에 따라 요구사항은 언제든 변할 개연성이 높고, 국내처럼 갑과 을의 불공평한 계약관계로 엮일 때는 불확실성의 정도가 심해지겠지요.
국내 SW산업은 현재 기능점수(Function Point)에 기반하여 비용과 Man/Month를 산정하는 형태가 가장 일반화되어 있습니다. 기능점수는 단순히 개발대상 비즈니스의 기능을 분류하고 난이도를 추정하여 점수를 주고, 이에 기반하여 투입공수를 추정한다는 방정식은 아닐 것입니다. 실제 기능점수가 제 역할을 발휘하기위해선 SW 개발에 영향을 미치는 많은 변수들에 대한 데이터가 축적되고 반영되어야 그 정확도가 향상될 것입니다.
애자일은 SW개발에 대한 불확실성을 전제로 합니다. 거친 표현으로 ‘We Know Nothing’ 라는 정신으로 개발을 준비하고, 그 맥락에서 SW 규모와 시간에 대한 추정범위를 좁혀 나가기 시작합니다. 애자일에서의 개발규모와 기간을 파악하는 방식을 처음 마주할 때는 ‘과연 이게 가능할까?’라는 의문이 앞서기 마련입니다.
애자일은 일의 규모에 대한 추정을 기간에 대한 추정과 분리하여 생각합니다. 예를 들어보겠습니다. 저는 얼마전에 살던 곳에서 이사를 하여 새로운 동네로 옮겼습니다. 이사할 때 이삿짐 센터에서 일하시는 분이 와서 우리집에 있는 이삿짐의 규모를 미리 파악하고 갔습니다. (4톤 트럭 1대와 2,5톤 트럭 1대 정도의 분량이라고 얘기하더군요) 오랜 경험을 통해서 10분 정도 관찰한 뒤에 필요한 이삿짐의 트럭 톤수(규모)를 유추했던 것 같습니다. 당연히 규모의 짐작만으로는 이사가 얼마나 걸릴지 알 수 없겠지요.
이삿짐 센터에서는 이삿짐을 들어내서 트럭에 옮기는데 걸리는 시간과 내려서 새집으로 옮기는데 소요되는 시간과 인력의 수를 경험치로 제시하였고, 실제 걸린 시간도 다른 환경변수가 없었기에 제시했던 시간과 비교적 큰 차이없이 끝냈던 것 같습니다.
결국 일의 규모(이삿짐을 수용할 트럭의 톤수)와 이삿짐을 옮기는데 걸리는 속도를 알면 이사가 언제쯤 끝나게 될지 추정(예상시간)하게 됩니다. 그 예상시간은 ‘이삿짐 옮기기’라는 비교적 단순한 작업이기에 그 동안의 경험에서 축적된 추정은 거의 정확할 것입니다.
다시 주제를 애자일로 돌려서 일의 규모(개발규모) 측정은 어떻게 하는지 살펴보겠습니다. 애자일에서 일의 규모 측정은 스토리점수라는 기법을 주로 활용합니다.
# 스토리점수 기반의 개발규모 측정
인간은 태생적으로 절대수치를 식별하는 것보다 상대적인 값을 비교하는데 능합니다. 예를 들면 ‘A의 키가 B의 키보다 크다’ 라고 말하는 것은 쉽지만 ‘A의 키와 B의 키는 각각 몇 센티미터다.’ 라고 말하는 것은 휠씬 정확도가 떨어지는 일이겠지요.
애자일에서 말하는 스토리점수는 상대적인 비교입니다. 스토리점수는 어떤 작업(SW의 특정기능에 대한 개발 등)의 전체규모를 표현하기 위한 단위입니다. 스토리점수가 상대적이라는 의미는 3점을 받은 스토리는 2점을 받은 스토리보다 작업규모가 크고 5점을 받은 스토리보다는 작업규모가 작습니다. 상대적인 값의 할당을 통한 규모측정 방식입니다.
스토리 하나에 할당된 점수는 단순히 그 스토리의 상대적인 규모/크기를 나타냅니다. 스토리점수를 표현하기 위한 별도의 공식이 존재하지도 않습니다. 바꾸어 말하면 특정 스토리를 기능으로 개발하는데 필요한 노력의 양, 개발 복잡도, 기타 위험성을 고려하여 직관적으로 표현하는 값입니다. (Mike Cohn. Agile Estimating and Planning 2006)
앞서 언급했듯이 애자일은 불확실성을 전제로 합니다. 개발을 시작할 즈음에 개발팀에 주어진 정보는 한정적이고 불확실한 정보가 많다고 가정합니다. (물론 이전에 유사한 SW나 기능레벨에서 비슷한 류를 개발한 경험치 등 개발업에 종사하면서 익힌 Know-how 기반의 경험치를 통해서 최대한의 추정을 할 것이라는 가정도 함께 하게 될 것입니다.)
프로젝트의 시작 무렵에 파악된 요구사항과 제약조건을 기반으로 전체 소프트웨어 개발을 사용자 스토리(User Story)라는 이름으로 묘사하게 됩니다. 사용자 스토리는 만들려고 하는 SW가 이런 저런 기능들을 하면서 작동해야 함을 기술하는 것이겠지요. 이런 사용자 스토리에 대하여 각각의 스토리점수를 부여하게 됩니다. 부여하는 원칙은 앞서 설명한 상대적인 크기의 비교에 따른 것입니다.
# 속도(Velocity)
상대적인 규모를 나타내는 스토리점수가 실제 의미를 가지고 활용될 수 있으려면 ‘속도’라는 개념이 필요합니다. 애자일에 정의된 속도는 개발팀의 진도를 평가하는 방법이자 수단입니다. 속도의 정의는 ‘개발팀이 스프린트 동안 완료한(구현을 끝낸) 스토리점수들의 합산’ 이라고 합니다.
예를 들어 특정 스프린트 기간(2주)동안 각 3점, 5점, 5점, 7점으로 추정된 스토리 4개를 완료했다면 속도는 20입니다. 스토리점수와 속도와 합쳐지면 어떤 결과를 보여줄까요?
다시 예를 들어보겠습니다. 프로젝트에서 구현해야 할 모든 기능(초기에는 명확하지는 않겠지요)들에 대해 스토리점수를 부여하고, 이 점수들의 총합은 프로젝트의 전체규모가 됩니다. 여기에 프로젝트팀의 속도를 알고 있으면(앞의 예시에서는 20), 프로젝트를 완료하기 위한 스프린트의 횟수를 식별할 수 있고 개발을 위해 소요되는 기간(Duration)도 파악이 됩니다.
너무 단순화해서 표현했지만 불확실성의 추정이 시간이 지나면서 어떻게 구체화되어가는지에 대한 감은 조금씩 잡히리라 생각됩니다. 스프린트의 횟수가 거듭될수록 개발팀의 속도가 명확해지고 개발기간이나 인력투입규모에 대한 정확도도 높아질 것입니다.
애자일은 근본적으로 Time & Material 기반의 계약으로 진행할 때 적합합니다. 앞서 언급한 추정과 계획들은 모두 불확실성을 전제로 일의 규모나 기간이 변화할 가능성이 있음을 가정하니까요. 국내의 고정형 계약방식에서 애자일을 활용하는 방식은 별도의 주제로 이야기해보겠습니다.
다음 노트에서 계속해서 추정의 기술, 스프린트 일정계획 등 불확실성의 추적에 대한 나머지 주제들에 관해 알아보겠습니다.
#애자일 #스크럼 #스토리점수 #Agile #Scrum #Agile_Estimation #User_Story #Story_Points #Velocity #Agile_Velocity #Sprint #Iteration
