Agile 프로젝트 퀵가이드(5) : Starting편-일감크기 추정

Updated:


크기 추정이란?

일감(=제품 백로그)의 크기는 해당 일감을 완료하기 위해 필요한 노력의 양인데, 1MM, 1MD와 같은 절대적인 개념이 아닌 상대적인 크기입니다. 프로그램 난이도를 상/중/하로 분류하여 생산성을 구하는 것과 비슷하되, 스크럼에서는 상/중/하 개념이 아닌 포인트 개념으로 상대적인 크기를 추정하게 됩니다.

추정 시점

스크럼 프레임워크에서는 스프린트 계획 회의에서 스프린트 백로그의 크기를 추정하는 것으로 소개합니다. 스프린트 계획에서 선정된 제품 백로그를 구현하기 위한 작업들이 구체화되고 난 뒤 해당되는 작업의 양 크기를 추정할 수 있기 때문이죠.

이에 반하여, 당사의 방법론에서는 스프린트 제로 단계에서 전체 일감에 대한 크기를 추정하도록 하고 있습니다. 스프린트 제로 단계에서는 제품 백로그 목록만 도출이 되고 아직 구체적인 내용이 파악이 된 상황이 아니기 때문에 일감 추정이 어려울 수 있지만, 이 단계에서의 일감 양을 추정함으로써 전반적인 제품 백로그 항목을 살펴봄으로써 스크림팀 모두가 함께 전체 일감 양에 대한 공감대를 형성하기 위해서입니다.

이를 통해 프로젝트의 제품 기능을 완료하기 위해 필요한 팀 속도를 계획하고, 릴리즈 및 스프린트 일정 계획을 수립할 수 있습니다.

스프린트 제로 단계에서 추정한 일감의 크기는 스프린트를 진행하면서 다시 업데이트합니다. 제품 백로그가 새로 더해지거나 변경될 경우 또는 시작 초반에는 감지되지 않았던 세부사항이 밝혀지면서 크기가 달라질 수 있으며, 스프린트 계획 미팅 때마다 스프린트 백로그 선정과 함께 백로그 크기는 재추정을 하는 것이 바람직합니다.

SI 프로젝트의 일감 추정

SI 프로젝트에서는 백로그를 선정한 다음 이 백로그의 크기를 추정한다는 것이 좀 난해할 수 있습니다. SI 프로젝트는 시작 전에 전체 물량과 개발 공수가 결정이 되어 있는 상태에서 출발을 하기 때문이지요. 이는 개발팀 속도와 일의 양 또한 이미 결정되어 있음을 의미합니다.

현실적으로 애자일/스크럼을 적용하기 어려운 부분이 바로 여기에 있습니다. 프로젝트가 착수되고 나서 투입된 구성원들로 이루어진 스크럼팀의 역량과 속도를 감안하지 않고, 시작도 하기 전에 주어진 목표에 맞게 일을 해치워야 하는 상황인 셈입니다.

그러나, 계약에 의해 정하여진 범위의 S/W를 개발하는 SI프로젝트일지라도 애자일 방법론을 적용하기로 결정된 이상, 고정된 프로젝트 기간 내에 고정된 일감을 무조건 완수해야 하는 경우는 아닐 것이라고 봅니다.

어느 정도의 변동성을 감안하고 애자일 방법론을 통해 매 스프린트마다 PO의 의견을 반영하여 보다 가치가 높은 기능을 개발하고자 하는 목표가 합의되어 있다면, 새로 추가되거나 변경되는 요구사항의 크기가 스크럼팀에 얼마의 영향을 줄 지 가늠하기 위해 일감 크기 추정을 실시할 필요가 있습니다. 이를 통해 고객에 의해 무리한 요구사항이 발생되지 않도록 협상할 근거를 마련할 수 있습니다.

일감 추정 방법

일감 추정 방법에는 Planning poker 기법, 유사 추정, 전문가 추정 등의 방법이 있습니다. 중요한 것은 팀원 모두가 공감할 수 있는 방법으로 크기를 추정해야 합니다. 기존처럼 PM 또는 PL 혼자서 일감의 크기를 결정하지 않아야겠지요.

아래 내용은 Planning Poker를 이용한 스토리 포인트 산정 방법입니다.
기존에 Delphi 기법과 유사한데, 전문가일자라도 제3자가 아니라 프로젝트 수행 당사자인 개발팀이 모여서 본인의 역량을 감안하여 직접 스토리 포인트를 산정한다는 점이 핵심입니다.

  1. 적당한 사용자 스토리를 선택하여 해당 스토리 크기를 3 포인트로 기준을 정의한다.
    해당 업무에 대해 설명을 하여 참여자 모두가 이해하고, 크기에 대해서도 공감대를 이룬다.
  2. 해당 스토리를 기준으로, 다른 스토리들에 대한 상대적인 크기를 정의된다.
    (3보다 두 배 정도 큰 일이면 5, 절반 정도의 일이라면 1 or 2로 기준 정의 )
  3. 추정 하고자 하는 스토리가 적힌 스토리 카드를 고른 후, 제품 책임자가 해당 업무에 대해 설명하며, 팀원들은 질문/토론을 통해 업무를 대해 충분히 이해 한다.
  4. 설명이 끝나고, 모든 참여자가 동시에 각자 생각하는 숫자가 적혀있는 카드가 위로 향하도록 내민다.
  5. 만장 일치가 아닐 경우, 의견 조정을 위한 토론을 진행하고, 이를 바탕으로 다시 게임을 반복한다.
    (만장일치가 될 때 까지)
  6. 만약 3회가 되도록 만장 일치가 나오지 않는다면, 중간 포인트를 선택하고 다음 게임으로 넘어간다.
  7. 40 이상으로 예측된 사용자 스토리가 있다면, 너무 커서 분할해야 하는 것은 아닌지 다시 한번 확인한다.
  8. 나눌 필요가 있다고 판단되는 일에 대해서는 세분화된 할 일을 인덱스 카드에 적고 이에 대해 게임을 한 뒤, 이전의 카드를 폐기한다.


  • 스토리 포인트 산정시 주의사항
    • 스토리 포인트로 표현된 추정치는 그 기능을 개발하는데 드는 노력의 양과 개발복잡도 그리고 그 안에 내재된 위험성 등을 한데 모아 표현하는 값으로 산정(Calculation)이 아닌 추정(Estimation)을 통해 도출된다.
    • 추정의 경우 아무리 많은 시간을 들이더라도 직접 작업을 하기 이전에는 100% 정확해지지 않는다. 추정은 추정일 뿐이다. 완벽한 추정은 애초에 불가능하다는 것을 인정하고 포인트 추정에 너무 많은 시간을 들이지 않도록 한다.
    • 추정치는 팀에 속한 한 개인이 만들어 내기 보다는 여러 명이 참여하여 의견을 모으고, 서로 간의 이견을 조정하는 것이 중요하다.

일감의 범위와 전체 양을 대략 파악했으니 이제 전체 기능에 대한 개발 일정을 수립해야겠지요 ?

다음 릴리즈 계획 편으로 넘어가 주세요.




Related Posts :
QuickGuide 04 > 제품 백로그 도출
QuickGuide 06 > 릴리즈 계획 수립


< EOF >