스토리 포인트가 무엇인지 가장 잘 설명하는 것은 무엇입니까?

우리는 애자일 개발에 Story Points를 사용하기 시작했지만 설명하기가 어려우며 그에 대한 명확한 대답을 찾을 수 없습니다. 내가 할 수있는 최선의 방법은 다른 사이트 (예 : http://blog.mountaingoatsoftware.com/tag/story-points )를 가리키고 그들이 무엇인지에 대한 모호한 일반화를 제공하는 것입니다. 다른 사람들이 사용하는 데 도움이되는 몇 가지 사용 예를 통해 좋은 설명을 찾고 있습니다. 스토리 포인트를 설명하는 데 유용한 자료가 있습니까?

이것은 초보자로서 도움이 될 수 있습니다 : Mike Cohn on story points . 그러나이 사람은 훨씬 더 : 민첩한 개발 팀 : 마이크 콘과 범위와 규모

소프트웨어 추정 지표에 대한 Mike의 솔루션은 간단하고 효과적입니다. 생물학적 사실 :

• 인간의 뇌는 시간을 정확하게 추정 할 수 없습니다. 특히 몇 시간 이상인 경우.
• 이는 소프트웨어 개발자의 불확실성, 경영진의 심리적 압력 (추정 할 때 커밋 ...) 및 팀의 기술 차이로 크게 증폭됩니다.
• 그러나 우리는 물건을 비교하는 데 능숙합니다. 우리는 매우 정확합니다.

아이디어는 하나의 참조 사용자 스토리를 취한 다음 임의의 수의 (스토리) 포인트 를 제공하면 다른 스토리는 해당 참조와 관련된 포인트를 얻습니다.

참조 스토리가 100 포인트이고 다른 스토리가 3 배 더 크면 300 포인트가됩니다.

스토리 포인트를 계획 시간으로 변환하려면 속도 를 알아야합니다 .

정확한 속도를 얻으려면 반복을 거의하지 않고 주어진 시간 내에 팀이 완료 한 점수를 계산해야합니다.

작동합니다 .

나는 303 @Pierre 모든 동의 : 위 말했다 : (떨어져 100 참조 점에서).

내가 추가하고 싶은 유일한 것은 (강조) 우리는 업무를 잘 평가하지 못한다는 것입니다. 대략 같은 크기 인 한 다른 작업과 관련된 작업을 추정 할 수 있습니다. 작업 간의 차이가 클수록 더 나빠집니다.

따라서 100의 시작점을 사용하는 것에 동의하지 않습니다.

다음 작업을 참조 작업의 42 %로 추정하는 것은 아닙니다. 그것은 작업의 절반을 작업의 두 배로 두 배로하는 것입니다.

우리 팀은 Planing Poker를 사용합니다 . 여기에는 2 스토리 포인트의 참조 작업이 있습니다. 그런 다음 피보나치 시리즈를 사용하여 작업을 추정합니다. 1,2,3,5,8,13,21, Huge ,? 참조 작업과 관련하여 (피보나치가 아니라 다른 팀이 2의 힘을 사용하는 것을 보았습니다. 1,2,4,8,16,32, Huge ,?) 나는 다른 팀이 (small (1), medium ( 2), large (3), XLarge (4)는 속도를 계산할 때 여전히 작동했습니다.).

요점은 작업의 크기가 참조 작업에 비해 증가함에 따라 비용을 정확하게 예측할 수 없게된다는 것입니다. 따라서 노력할 필요가 없습니다. 이것은 추정 트레일 끝에서 더 큰 기울기로 반영됩니다.

따라서 참조 작업이 2SP라면 그런 다음 작업의 크기가 비슷하므로 1/2/3/5로 추정하는 것이 상대적으로 쉽습니다. 참조 작업 (5SP)의 3 배를 초과하면 추정이 더 어려워집니다 (8 / 9 / 10SP는 문제가됩니다) 5SP보다 크고 13SP보다 작 으면 8SP가 계산에 맞습니다.

SP 값이 13 / 21 / Huge 인 경우 스프린트 백 로그에 비해 너무 큽니다. 이것은 실제로 작업 할 준비가되지 않은 것들에 대한 추정치입니다 (따라서 작은 작업으로 나뉘 지 않았습니다 (필요할 때까지 나누지 마십시오)). 그러나 이들은 제품 백 로그의 작업 크기에 대한 추정치를 제공합니다 (향후 계획이 가능함). 작업 할 시점에 도달 할 때까지 스프린트 백 로그를위한 작은 작업으로 분류하고 개별적으로 다시 추정 할 수있는 충분한 지식이 있어야합니다 (참고 : 부품은 원본과 동일).

• 거대하다고 추정하는 것은 더 작은 작업으로 세분화해야합니다.
• 로 추정되는 것은 무엇입니까? 즉, 추정하기에는 정의가 충분하지 않음을 의미합니다.
  구체적으로 작업을 정의하고 작업을 정의하려면
  (예 : 문서 또는 프레젠테이션 작성) 작업을 추가해야합니다 .

스토리 포인트는 작업이 얼마나 어려운지에 대한 상대적인 측정입니다. 인간이 실제로 정확한 측정보다 상대적 추정에서 더 우수하기 때문입니다.

스토리 포인트를 사용하는 방법은 프로젝트에서 두 가지 작업을 수행하여 두 가지 스토리 포인트 값을 지정하는 것입니다. 그런 다음이 두 스토리 포인트 근사값을 추정의 기초로 사용하여 다른 작업을 추정합니다. 즉 작업 C는 작업 A보다 훨씬 어렵지 않지만 작업 B보다 훨씬 쉽습니다. 따라서 작업 A보다 약 2 스토리 포인트 더 많은 작업입니다.

지금까지 가지고있는 모든 요구 사항을 추정 한 후 스프린트에서 수행 할 수있는 수를 추정합니다. 다음 몇 번의 스프린트 동안, 당신은 당신이 완료 한 수를 추정합니다. 요구 사항의 스토리 포인트는 요구 사항이 충족 된 경우에만 완료된 것으로 계산됩니다. Scrum에는 "80 % 완료"가 없습니다. 인간이 실제로 완전성을 추정하는 데 좋지 않기 때문입니다. 몇 번의 스프린트 후 스프린트 당 몇 개의 스토리 포인트를 사용할 수 있는지 생각해야합니다.

당신은 어떻게 추정합니까? 계획 포커 를 사용 하여 개발자가 기본 요구 사항과 비교하여 요구 사항이 얼마나 많은 작업을 수행한다고 생각하는지 결정할 수 있습니다 .

나는 또한 Agile Samurai를 읽는 것이 좋습니다 . 내 의견으로는 이러한 및 기타 민첩한 개념을 설명하는 것이 좋습니다.

스토리 포인트에 대한 더 많은 링크가 있습니다.

다른 링크가 있습니다.

그들은 시간 낭비입니다.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

이 의견은 이제 트렌치에서 스크럼과 XP 를 작성한 사람 과 회사 이름 ( Crisp )을 전 세계의 많은 팀이 사용하는 계획 포커 카드의 많은 데크에서 찾을 수 있다는 사실에 흥미가 있습니다.

OP의 마지막 문장 : "스토리 포인트를 설명하는 데 유용한 자료가 있습니까?" 예,이 책은 좋은 자료입니다. 생각할 거리.

내가 생각해 낼 수있는 가장 쉬운 설명은 실체적이고 구체적인 예를 제공 할 수있는 물체를 사용하는 것입니다.

이동 주택을 가져 가십시오. 모바일 홈 비즈니스에 종사하는 경우 단일 와이드를 구축하는 데 일반적으로 5가 필요합니다 (포인트, 개구리, 위젯 ... 측정 형식은 임의 임). , 개구리, 위젯).

이 시점에서 프로그래머의 사고 방식은 간소화 된 접근 방식에 대해 이야기 할 것입니다. 인프라에서 가장 많은 시간을 소비하고 다른 유사한 예제로 인해 두 배가 걸리지 않습니다. 불가피합니다. 시간을 정확하게 예측할 수 없으므로 (포인트, 개구리, 위젯) 추정하면 (포인트, 개구리, 위젯) 추정치가된다는 사실을 이해하십시오.

무언가를 구축하는 데 시간이 얼마나 걸리는지 알기 위해 시간이 지남에 따라 트렌드를 활용할 것입니다. 따라서 시간이 지남에 따라 추정치가 점점 더 정확 해집니다.

팀이 준비되면 포커 계획을 잊지 마십시오 .

다른 사람들이 언급했듯이 스토리 포인트는 사용자 스토리의 복잡성을 상대적으로 측정 한 것입니다. 스토리 포인트의 진정한 이점은

1. 포인트는 구현을 담당하는 부서 (개인 또는 팀)에 의해 측정됩니다.
2. 일정한 기간 (속도) 내에서 동일한 단위로 몇 개의 집계 포인트가 완료되는지에 대한 메트릭이 유지됩니다.

스토리 포인트와 추적 속도에서 몇 번의 측정을 반복 한 후에는 주어진 타임 블록 (스크럼을 사용하는 경우 반복 또는 스프린트) 내에 몇 개의 스토리 포인트가 들어갈 수 있는지 정확하게 예측할 수 있습니다. 이 기술을 그룹에 적용하고 다른 팀에 대해 이러한 메트릭을 사용하려고하면 제대로 작동하지 않습니다. 즉, 팀 a가 2 주 스프린트에서 120 스토리 포인트를 완성 할 수 있다면 팀 b가 동일한 결과를 기대하는 것은 비현실적입니다.

다른 사람이 언급했듯이 포커 계획은이 방법을 사용할 때 도움이 될 것입니다.이 방법은 더 세분화해야하는 스토리를 식별하는 데 도움이됩니다 (투표간에 불일치가 있으면 요구 사항이 불확실 함을 의미 함).