User-stroy, Estimable in the INVEST

 

Estimable – 추정 가능하다

출처 : xp123.com/articles/estimable-stories-in-the-invest-model/

 

좋은 스토리는 추정할 수 있다. 정확한 추정은 필요하지 않지만 고객이 스토리 구현의 순위를 매기고 일정을 잡는 데 도움이 될 만큼 충분하다. 우리가 이해하지 못하는 스토리는 추정하기가 어렵기 때문에 추정 가능하다는 것은 부분적으로 협상의 기능이다. 또한 크기의 함수이기도 합니다. 더 큰 스토리는 추정하기가 더 어렵습니다. 마지막으로 이는 팀의 기능입니다. 예측하기 쉬운 것은 팀의 경험에 따라 다릅니다.
때때로 팀은 적절한 추정을 내기 위해 충분한 정보를 제공하는 "SPIKE" 와 원하는 기능을 실제로 구현할 나머지 스토리로 나누어야 할 수 있습니다.

 

개발자들은 각 스토리의 크기 혹은 작업 소요 시간을 추정할 수 있어야 한다.

- 추정은 Agile 시리즈 책 1권 분량의 어렵고 고통스러운 작업이다.

- 간단하게 아래 방법으로 추정해 볼 수 있다.

- counting stories : 작성된 스토리 수로 추정한다. (이전 평균(샘플) 값 필요)

- historical estimates : 기존 작업 이력을 기반으로 추정한다. (칸반 WIP)

- rough order of magnitude estimates : 대략적인 크기를 산정하여 추정한다.

 

 

추정이 쉽지 않은 경우 및 해결책

 

– 해당 분야(도메인)의 지식이 부족 

=> 고객 인터뷰를 통해 해결책을 모색한다.

 

–기술적인 지식이 부족 (짧은 Spike를 통해 극복)

=> 정보수집을 위한 민첩한 스파이크

=> 실제 작업을 수행하는 스토리

* Spike : 개발이나 설계전 프로토타입 형태로 간단하게 구현 또는 시뮬레이션하는 방법

 

– 스토리가 너무 크다.

=> 스토리를 작은 스토리로 나눈다.

=> Epic 으로 구분하여 향후 스토리로 세분화한다.

 

 

추정 관련하여 언급하기

Why Is It Hard to Estimate? : 추정이 어려운 이유가 무엇인가?

소프트웨어 개발에는 알려지지 않은 사항이 너무 많다. (so many unknowns) 아래 항목들은 하루 또는 일주일 동안 계획하고 회의에 참석하고 헌신적으로 시작한다고해서 어려움을 극복 할 수는 없다. - The Domain => 도메인을 모르는 경우 고객과 오해를하기가 더 쉽고 더 나은 솔루션에 대한 깊은 통찰력을 갖기가 더 어려울 수 있다. - Level of Innovation => 이전에 한 번도 해본 적이 없는 일을 해야하는 분야(domain)에서 운영(operating)해야 한다.  - The Details of a Story => 우리는 종종 완전히 이해되기 전에 이야기를 추정하고 싶어한다. => 아직 명확하지 않거나 예상하지 못한 복잡한 비즈니스 규칙과 제약의 영향을 예측해야 할 수 있어야 한다. - The Relationship to Other Stories => 일부 스토리는 구현 될 다른 스토리에 따라 더 쉬울 수도 있고 어려울 수도 있다. - The Team => 같은 프로젝트, 팀 사람이도 시간이 지남에 따라 변한다. => 새로운 팀에서는 더 어렵다. - Technology => 대규모 프로젝트에서 사용할 기술 중 일부를 알고 있을 수 있지만 모든 것을 미리 알수 없다. => 따라서 추정치는 학습 시간을 고려해야한다. - The Approach to the Solution => 우리는 문제를 어떻게 해결할 것인지 아직 알지 못할 수 있다. - The Relationship to Existing Code  => 기존 솔루션의 섹션("habitable section")에서 작업 할 것인지 여부를 알 수 없습니다. - The Rate of Change  => 우리는 단지 "스토리가 무엇인가?" 를 추정해야되며 또한, "마지막으로 무엇이 될까?" 까지 추정해야 할 수도 있다. - Dysfunctional Games => 일부 환경에서 추정은 정치적 권력을 위한 도구로 평가된다. (힘, 권력에 따라 결정) => 예상 대 약정, 일정 관리 및 기타 많은 악용 등 - Overhead => 외부 요인이 추정에 영향을 준다. => 멀티 태스킹을하거나 사이드 프로젝트를 맡게되면 일이 더 오래 걸린다.

Simple Estimates: Count the Stories

Don Wells 는 매우 간단한 접근 방식을 제안했다. "그냥 이야기를 세어보세요." thought experiment 1. 스토리의 실제 크기를 나타내는 숫자를 가져옴. 2. 무작위 샘플 채취함. 3. 샘플의 평균을 스토리 크기로 설정. 4. 총계에 대한 추정치는 스토리 수에 샘플 평균을 곱한 값. 주의. - 시간이 지남에 따라 능력치나 적응력이 향상된다. (회고를 통해 간격을 좁혀야 함.) - 실제 크기를 가지지 않는 스토리는 무시함 (의존도가 높은 경우)

Historical Estimates (ala Kanban)

work-in-progress (WIP) is the challenge 칸반의 WIP 개념에 대해 먼저 이해를 해야 한다. 개발 기록을 추적하면서 시간을 측정하고 패턴을 찾아낼 수 있어야 한다. - 평균 스토리 전달에 10일 - 스토리 95% 전달하는데 22일 이하 소요 => 다음 스토리 전달에 걸리는 시간을 추정할 수 있다. 이것은 "얼마나 큰가?" 에서 추정 질문을 "얼마나 빨리받을 수 있나요?" 로 바꿀 수 있다. WIP 가 높으면 개발팀의 퍼포먼스가 높은 것이며 WIP 가 낮아지면 개발항목의 중요도가 높은 것이다.

Rough Order of Magnitude

대략적인 추정치는 시간 단위(시간, 일, 주, 월, 년)를 추정한다. - 리스크, 가치 및 옵션을 탐색("Explore")한다. - 대략적인 규모를 추정한다. - 가장 중요한 스토리의 유용한 버전을 작게 만드는 것에 먼저 집중한다. - 해당 버전에서 이해 관계의 균형을 맞추기 위해 협상한다. (어떻게 그리고 얼마나 진행할지 결정) - 이 과정에서 배워나가야 한다.

 

---

 

• INVEST in User-Story
• (I)ndependent - 독립적이다
• (N)egotiable – 협상 가능하다
• (V)aluable – 사용자 및 고객에게 가치가 있다
• (E)stimable – 추정 가능하다
• (S)mall - 작다
• (T)estable – 테스트 가능하다

참고 사이트

INVEST in Good Stories, and SMART Tasks - XP123

 

---