[Agile] 스토리 포인트로 견적내는 현실적인 방법

※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용이 있으면 지적해주시면 감사하겠습니다.

 

 

스토리 포인트란?

---

 스토리 포인트는 과제의 크기를 표시하는 수치이다. 이용할 수 있는 수치로는 1, 2, 3, 5, 8, 13, 21, 40이 있다. 이것은 시간을 표시하는 것이 아닌 단순히 과제의 크기라는 것을 주의하자.

 

 

시간 견적이 아닌 이유

---

  방금 작성했듯 스토리 포인트는 시간이 아니다. 그 이유는 다음과 같다.

 

시간 견적은 사람에 따라 큰 차이가 있다.

 예를 들어 다음과 같은 과제가 있다고 상정하자.

## Done의 정의(완료 요건)
- Google계정을 이용하여 등록, 로그인할 수 있도록 하는 것

## 이용 기술
- Ruby on Rails

 어떤 개발자 A는 이 기능을 8시간에 구현 가능할 것이라고 견적을 냈다. A는 Ruby나 Ruby on Rails로 개발한 경험이 풍부하며 더욱이 Google 계정을 이용한 로그인 기능을 구현한 경험이 있다.

 같은 팀에 B이라는 기술자가 있다. B는 PHP로 개발한 경험은 있지만 Ruby는 처음이다. 당연 Ruby on Rails도 만져본 적이 없다. 이 기능 구현을 기술자 B로 한다면, B는 8시간만에 구현할 수 있을 것인가?

 A가 담당이라면 개발 경험도 풍부하므로 8시간이라는 견적은 정답이지만, 더욱이 이 정답이 유효한 사람은 A뿐이다. 

 

시간 견적은 속인화하게 되는 원인이 된다.

 맨 처음의 예에서 알게 된 사람이 많을 것이라고 생각되는데, 시간 견적을 정확히하기 위해 아래의 조건 둘 중의 하나를 만족해야한다.

1. 반드시 견적을 낸 사람이 과제를 담당한다.

2. 팀 전원의 스킬 레벨 차가 거의 없는 팀이어야한다.

 2는 거의 불가능하다고 봐야한다. 엔지니어의 레벨은 개개인의 편차가 있는 것이 당연하며, 동일한 정도의 스킬 멤버만으로 구성된 팀을 장기간 유지하는 것은 불가능하다.

 그러나 1의 방법을 하면, 기본적으로 견적한 사람이 그 과제의 담당자로 고정되므로 과제의 속인화를 유래한다.

 

기본적으로 정확한 시간 견적은 불가능하다.

 완전히 동일한 기술을 사용한 시스템 요건도 완전히 동일하다. 이러한 상황을 몇 번이고 반복하면 정확한 시간 견적이 될지도 모른다. 

 그러나 현실적으로 이러한 것은 불가능하다. 동일한 Ralis라도 버전에 따라 미묘하게 사용 방법이 다르고 예를 들어 상급자라고 한다고 해도 "학습 비용이 0"인 프로젝트는 존재하지 않는다고 생각하며, 시스템의 요건은 만드는 서비스에 따라 커다랗게 변화한다.

 "정확한 시간 견적이 가능하다"라는 생각은 현실적이지 않다.

 

 

스토리 포인트를 이용한 상대적인 견적을 사용하는 이유

---

 방금 봤던 시간 견적의 예는 "절대 견적"이라고 불리는 방법이다. 그에 반해 스토리 포인트를 사용한 견적은 "상대 견적"이라고 불린다.

 이 방법은 기본이 되는 과제에 포인트를 붙여, 그 과제 대비 지금의 과제는 몇 포인트인지를 도출해내는 방법이다. 아래의 예로 설명하도록 하겠다.

현재 위치는 도쿄역이다.
여기에서 이케부쿠로역까지 이동한다. 거리는 약 10km이다.。

여기에 걸리는 시간을 견적해보라.

※ 참고자료로는 야마노테선의 노선도를 살펴 볼 수 있다.
※ 구글 검색하면 바로 알 수 있다는 태글은 받지 않는다.

 시간을 사용한 "절대 견적"으로는 다음과 같은 결과가 된다.

• A는 25분으로 견적을 냈다.
• B는 16분으로 견적을 냈다.

 꽤 차이가 났다. 원인은 A는 야마노테션을 이용하는 것을 상정했지만 B는 마루노우치선을 사용하는 것을 상정했기 때문이다. A와 B이외에도 다른 개발자가 있다고 한다면 전철이 아닌 택시나 버스를 이용하겠다고 말하는 사람도 생길지도 모른다. 이렇게 각자의 견적이 다 다를 수 있다는 것은 예상할 수 있다.

 이러한 시간 견적은 가지고 있는 지식(이 경우는 도쿄의 교통 상황)이나 어떤 수단을 이용하는가(이 경우는 교통수단)에 따라 커다랗게 차이가 난다.

 그러면 스토리 포인트를 사용한 "상대 견적"으로 방금 봤던 예제를 견적내보자. 설명문은 다음과 같다.

현재 위치는 도쿄역이다.
여기에서 이케부쿠로역까지 이동한다. 여기에서 부터 걸리는 공정수를 스토리 포인트로 견적내보자.

참고로 도쿄역에서 시나가와역까지의 거리를 스토리 포인트는 2라고 가정한다.

※ 참고자료로는 야마노테선의 노선도를 살펴 볼 수 있다.

 이용할 수 있는 수치는 ZenHub에서 사용할 수 있는 1, 2, 3, 5, 8, 13, 21, 40이다. 

 이 경우는 많은 사람이 도쿄 > 시나가와간의 거리를 2라고 한다면 이 두 배 정도로 떨어져 있는 도쿄 > 이케부쿠로 사이의 거리를 5라고 견적할 수 있을 것이다.

 그러나 "어떤 교통 수간을 사용할것인가"나 "도쿄의 어떤 선로를 사용할지"와 같은 지식 필요없이 견적을 낼 수 있다. 이와 같이 스토리 포인트를 사용한 "상대 견적" 은 사람의 지식이나 능력에 의존하지 않고 견적이 낼 수 있게 된다.

 

 

스토리 포인트를 이용한 "상대 견적"의 구체적인 방법

---

 여기서 부터는 구체적인 예를 활용하여 설명하도록 하겠다.

 

스토리 포인트2의 기준이 되는 과제

유저의 이름을 획득하는 기능.

# Done의 정의
- 유저ID에서 이름을 획득하여 화면에 표시한다.

# 보충
- DB의 테이블 구성은 확정되어 있다.
- 유저ID는 Cookie에서 획득 가능하다.
- 대상 유저의 이름이 등록되어 있지 않은 등의 예외 패턴에 관해서는 여기서 고려하지 않아도 된다.
- 화면 디자인에 대해서도 여기서 고려하지 않아도 좋으며, 어떤 화면에서든 괜찮으니 일단 유저의 이름이 표시되면 된다.

 

스토리 포인트5의 기준이 되는 과제

유저의 패스워드를 리셋하여 새로운 패스워드로 변경하는 기능

# Done의 정의
- 유저의 패스워트가 변경되어 있는 것
- 새로운 패스워드 설정시에 메일로 인증을 할 것
- 패스워드는 8문자 이상, 2문자이하의 대문자 소문자 알파벳과 1에서 9의 숫자를 허가할 것

# 보충
- DB의 테이블 구성은 확정되어 있다.
- 메일 송신용 함수는 기존에 존재한다.
- 메일 주소에 메일 도착하지 않은 경우 등 예외 사항은 고려하지 않아도 된다.
- 화면의 디자인에 관해서는 여기서 고려하지 않아도된다.

 

스토리 포인트13의 기준이 되는 과제

유저가 신용카드를 이용해서 상품을 구입하는 기능

# Done의 정의
- 임의의 상품을 신용카드로 구매할 수 있는 것
- 구입한 상품의 정보는 My페이지에서 볼 수 있는 것
- 관리사이트쪽에서도 유저 구입 상품을 볼 수 있는 것

# 보충
- My페이지나 신용 카드의 등록 기능은 기존에 존재하고 있다.
- 「유저가 구입한 상품」을 나타내는 DB테이블이 존재하지 않으므로 설계할 필요가 있다.
- 관리 사이트에는「유저 정보를 볼 수 있는 기능」이 존재하지 않으므로 만들 필요가 있다.
- 신용카드관련한 에러 패턴등은 고려하지 않아도 좋다.

 

이처럼 여러 가지 사례가 있다면 견적을 낼 때 망설이지 않을 수 있다.

 그 중에서도 팀의 누구도 해 본적이 없는 미지의 기술을 조사할 필요가 존재한다. 그 때는 스파이크(기술적 검증)이라고 말하는데, 그러한 과제는 견적내기 매우 곤란하다.

 이러한 경우는 다음과 같은 방법으로 견적을 낼 수 있다.

• [방법1] 팀의 개발 속도 (1 스프린트당 생산량)에서 산출한다.
  • 팀의 개발 속도 평군이 100이라고 상정한다.
  • 팀의 멤버 수가 5명이라고 상정한다.
  • 2주간의 스프린트에서 스파이크에는 스프린트의 반을 쓰는 것을 상정한다.
  • 100의 반은 50으로 이것을 개발자의 수로 나누면 10이 된다. 이용할 수 있는 포인트로 가장 가까운 것은 8이므로 8을 채용한다.
• [방법2] 일방적으로 포인트를 정의한다.
  • 미지의 기술을 사용한 과제는 일괄 13으로 하는 등

 

 

플래닝 포커

---

 포인트로 견적을 낼 때 이용되는 방법이다. 상세한 것은 다른 블로그 글을 참고하는 것이 좋을 것 같은데, 여기서 가볍게 설명하자면 모두가 한 곳에 모여서 포인트가 적혀 있는 카드를 일제히 제시하는 방법이다.

 포인트가 크게 차이가 나는 경우는 제일 큰 수를 낸 사람과 제일 작은 수를 낸 사람의 의견을 각각 들어보고, 의식을 맞춘 후에 다시 견적을 낸다.

 과제 하나 하나에 그렇게 시간을 쓰면 안된다. 그리고 자택 근무하는 멤버가 있는 경우는 플래닝 포커를 할 수 있는 여러 웹 사이트를 이용하면 된다. 

 

 

Done의 정의를 명확하게 해 둔다.

---

 이것은 꽤 중요하다. 플래닝 포커를 한다고 해도, 차이가 있는 경우가 있는데, 이 원인은 Done의 정의가 매우 애매하기 때문에 일어난다. 어떤 조건을 만족하면 이 과제가 완료가 되는 것인가를 제대로 기록해두자. 

 모든 과제가 만족해야할 조건으로 "보편적인 Done의 정의"를 해두는 것을 추천하다. 예를 들면 다음과 같은 것이다.

• 테스트 코드가 작성되어 있고, 테스트를 패스한 경우
• 2명 이상의 리뷰어의 승인을 받은 경우

 원칙적으로 Done의 정의를 만족하면 이 이상의 것은 할 필요가 없다. 예를 들어 과제를 하다가 다른 개선점을 찾았다고 하더라고 그것은 다른 과제로 제기하고 더 이상 하지 않도록 하는 것이 중요하다.

 그렇지 않으면 사람마다 견적과 작업량의 균형이 달라지므로 이 점은 철저히 하는 것이 좋다.

 

 

주의점

---

 스토리 포인트 견적을 채용할 때에는 주의점이 있다. 개발자도 그렇지만 매니저 수준이 되는 사람들도 이 점을 충분히 이해해둘 필요가 있다.

 

스토리 포인트를 과도하게 믿지 않는다.

「Velocity tracking」나「Release report」를 이용하면 어느 정도 릴리즈날을 어느정도 예상할 수 있다. 그러나 "반드시 이 날 릴리즈해야한다"라고 생각하는 것은 틀리다.

 스토리 포인트는 시간 견적보다도 차이가 발생하기는 어렵지만 명확한 수치는 아니다. 그리고 과제는 개발 기간중에 점점 늘어나는 경향이 있으므로, Release report의 수치는 상태에 따라 변화한다.

 또한 Velocity tracking에 관해서도 개발자가 병결이나 퇴직등으로 팀의 변화가 생길 수 있으므로 어디까지나 참고 정보의 하나로써 이용하자.

 시스템 개발에 있어서 "정확한 견적"은 원래 무리라고 개인적으로 생각한다. 이러한 것을 이해하지 못하는 관리자가 스크럼 팀을 지배하고 있으면 스크럼이 붕괴될 가능성이 커진다.

 

개발 속도를 팀의 평가에 이용한다.

 개발 속도를 올리는 것을 일반적으로 좋은 것이지만, 이것을 바탕으로 평가를 낮추는 등은 하지 않도록 하자. 개발 속도가 저하되면 "게으름 피운다"라는 등으로 질책하는 것은 팀의 심리적 안정성을 저해하므로 주의하자.

 개발 속도를 올리는 방법으로는 간단히 개발자와 회의하여 매 스프린트마다 조금씩 넉넉하게 견적을 내면 된다. 하지만 그런 일을 개발자가 하기 시작하면 "스토리 포인트"에 대한 신뢰성이 단숨에 없어지므로 어느정도 주의할 필요가 있다.

---

참고자료

https://qiita.com/keitakn/items/c30b7071ebfbf4b1b3e0