Scrum - Story Point

스토리 포인트(SP)라는 녀석은 기존의 공수 산정을 할 때 들어난 단점들을 좀 커버해보자 하는 개념에서 출발했습니다.

 

기존의 산정 방법 중, 규모(소프트웨어 규모) 측정 단위는 LOC(Line of Code), FP(Function Point), 웹페이지 등이 있습니다.  기존 규모를 측정하는 것, 즉 이미 개발된 규모를 측정할 때 효과적입니다만 (사실 했던거 다시 하는 것은 쉽습니다) 그러나 요구사항의 불확실성이 높은 초기 단계에서 적용하면 정확도가 떨어지는 문제가 발생할 수 있고, 규모를 산정하는 사람의 기술적 역량과 실제 작업을 하는 사람의 기술적 역량이 다른 것도 정확한 산정에 문제가 됩니다. (초급, 중급, 고급, 특급 등 역량에 따라 작업 기간이 달라집니다.) 

 

기존 산정 방법 단점 - 요약

1. 요구사항의 불확실성이 높은 프로젝트에서는 산정의 정확도가 떨어집니다.

2. 산정 인력과 실제 개발 인력의 기술적 역량이나 배경이 다르기 때문에 산정의 정확도가 떨어집니다.

3. 투입 개발 인력의 역량에 따라 작업 기간이 다르기 때문에 재산정 시 불필요하게 낭비되는 시간이 발생합니다. 

 

그래서 나온 방법이 모수산정도 좀 가져다 쓰고, 치환기법과  비교 추정(상대 추정)도 가져다 잘 버무려서 Story Point 라는 것을 하나 만들었습니다. 왠만한 자료들에서 보면, Stroy Point는 리스크와 복잡성을 고려하고 작업량을 고려하고 블라블라 하는데요. 뭐 저도 일단은 그렇게 이야기를 합니다. ^^::

 

 

그런데 본질은, 정성적 평가죠. 각자의 영역에서 자신의 직, 간접적 경험과 정보를 바탕으로 산정을 합니다. 개발자는 개발 영역에서 정성적 산정을 하고, 저 같은 경우는 프로젝트 관리 영역에서 산정을 합니다. 실제 예로, 520억 프로젝트인데 기간을 13개월을 줍니다. 예전 경험에, 다른 조직의 450억 프로젝트가 명확한 프로젝트 관리이론 기반이 아닌 상태에서 4년이 소요된 것을 옆에서 구경했고, 이 450억짜리 프로젝트는 관리 이론과 방법론을 적용해도 2~3년이 소요되는 규모(사이즈)인데, 520억짜리 프로젝트를 1년 1개월에 완료하겠다 라고하면 저는 100% 못한다라고 말합니다. 그리고 그 프로젝트는 당연히 지연되었고, 언제 완료될지 추정도 못하는 상황이죠. 예측 기반의 완료 추정일이 아닌 그냥 윗 사람이 이 때까지는 할께요 라는 상황입니다. 
(실제로, 이 520억짜리 프로젝트는 계획 일정보다 1개월 지연, 범위는 실질적으로 계획에 반도 못하고 오픈했죠)

이렇게 프로젝트 관리 영역에서는 프로젝트 예산을 가지고 정확하지 않지만 기간이나 규모(사이즈)를 추정할 수 있습니다.  전에 경험과 이번 프로젝트를 자기 전문 영역에서 비교해서 추정을 하게 됩니다. 

 

(모수산정은 다 알고 계실테니 논외로 하고,) 조금 더  비교 추정(상대 추정과 혼재해서 사용합니다)부터 말씀 드리면, 

 

상대 추정(비교 추정)은 우리가 밥 먹듯이 해왔던 기법입니다. 대표적으로 남방(옷)을 살 때 L 사이즈, M 사이즈 또는 XL 사이즈 등 본인에게 맞는 옷을 사실겁니다. 만약 내가 맞는 사이즈가 L 이라면 M 이나 S 사이즈는 정확한 수치로 얼마나 작은지는 몰라도 일단 M 은 작고 S 는 더 작다라는 것을 알고 있습니다. 이게 상대 추정, 비교 추정입니다. 

그리고 상, 중, 하 또는 대, 중, 소 이런것들도 다 상대, 비교 추정할 때 사용하는 단위입니다.

 

그럼, 자동차와 트럭, 덤프 트럭이 함께 서 있을 때, 무게가 가벼운 순서를 숫자 치환해서 표시해 보시면 어떨까요?

 

누구나 다,  승용차 < 트럭 < 덤프 순서로, 1, 2, 3, 또는 1, 3, 5로 표시할 수 있습니다. 우리는 각각의 차량이 정확히 몇 톤인지 몰라도 일단은 상대 추정(비교 추정)을 해서 무게 순으로 나열을 할 수 있습니다.

 

다시 Story Point로 돌아가면, 일단 이 녀석 이름이 왜 Stroy Point가 되었냐면, 요구사항(Product Backlog를 구성하는 User Story)에 포인트(숫자)를 부여하는 것입니다. User Story에 포인트를 부여하다 보니 Story Point라고 이름이 붙은 겁니다.

 

요구사항인 User Story를 쭉 나열해 놓고, Working Group 팀 전체가 가장 규모가 (차로 치면 무게가 가장 낮은) 작은 User Story를 찾아서(팀이 협의 & 합의한 결과) 가장 낮은 포인트(일반적으로 1 을 부여함)를 부여합니다. ( 편의상 가장 낮은 포인트를 부여한 User Story를 A 라고 합니다) 그리고 이 A User Story를 기준으로 잡습니다. ( 내 몸에 맞는 남방 사이즈가 L 일 때 L 이 기준이 되듯이 ) 

 

이제 A User Story를 기준으로 상대 추정을 해서 나머지 User Story에 포인트를 부여합니다. 그런데 포인트에도 기준이 있습니다. 선형 스케일이라고 해서 1, 2, 3, 4, 5, 6, 7, ... 이렇게 부여할 수도 있고 옷 사이즈로 부여할 수도 있습니다. 

가장 많이 사용하는 포인트 기준은 피보나치 수열을 사용합니다. 0, 0.5(1/2), 1, 2, 3, 5, 8, 13, 21, ...

 

대부분의 경우 스토리 포인트는 크기 조정을 위해 다음 스케일 중 하나를 사용합니다.

• 선형 스케일 : 1, 2, 3, 4, 5, 6, 7, ...
• X-Small, Small, Medium, Large, Extra-Large (T- 셔츠 크기)
• 피보나치 수열 : 0.5, 1, 2, 3, 5, 8, 13, 21

중요한 것은, 이렇게 부여하는 포인트는 작업 기간이나 공수가 아니라는 것입니다. 기간을 산정하는게 아니고 말 그대로 User Story의 규모를 산정하는 것입니다. 얼마나 걸릴지라는 관점은 처음부터 고려하시면 안됩니다. 

 

 

위 이미지의 기어는 크기가 다르며 소프트웨어 개발 프로젝트의 기능과 마찬가지로 고유 한 속성을 갖습니다. 원의 크기를 측정 할 방법이 없다고 상상해보십시오. 각 기어의 정확한 크기를 어떻게 결정할 수 있습니까? 그러나 규모로 본다면 Story Point를 사용할 수 있습니다. ( 위 이미지에서는 가장 작은 User Story로 3SP를 부여했습니다. )

 

SP(Story Point)가 기간이 아니라는 부분을 계속 강조하고 있는데요. 팀 협의 없이 전통적인 산정 책임자가 3SP를 3day로 할 수 있다고 해버리면, 실제 작업자의 역량에 따라 3day가 안될 수도, 넘을 수도( 보통은 일정 지연이 되는 경우가 많습니다) 있습니다. 아직은 기간을 산정하는 시기가 아닙니다.  

 

User Story Card

 

참고로 User Story에 Story Point를 부여할 때는 다음의 각 요소를 고려해야합니다.

1. 해야 할 일의 양
2. 작업의 복잡성
3. 작업 수행시 발생하는 모든 리스크 또는 불확실성

 

다음은 Working Group의 팀원들이 User Story에 Story Point를 부여하는  Planning Poker 기법에  대한 내용입니다. 

(작성중)