사용자 스토리를 추정 할 때 사람이 아닌 스토리 포인트를 사용하는 이유는 무엇입니까?

민첩한 방법론 (예 : SCRUM)에서 사용자 스토리에 필요한 복잡성 / 노력은 스토리 포인트로 측정됩니다. 스토리 포인트는 팀이 반복에서 취할 수있는 사용자 스토리 수를 계산하는 데 사용됩니다.

추정 된 요일과 같은 구체적인 측정을 사용할 수있는 추상적 개념 (스토리 포인트)을 도입하면 어떤 이점이 있습니까? 또한 추정 된 요일을 사용하여 속도, 반복 적용 범위 등을 계산할 수 있습니다.

반대로 스토리 포인트는 사용하기 어렵고 (개념은 추상적이기 때문에) 이해 관계자에게 설명하기도 어렵습니다. 어떤 이점이 있습니까?

가장 큰 장점 중 하나는 사람과 개발자가 실제로 시간을 추정하는 데 상당히 나쁘다는 것입니다. 개발의 본질도 생각해보십시오. 처음부터 끝까지의 선형적인 진행은 아닙니다. "10 분 안에 코드의 90 %를 작성한 다음 17 시간 동안 디버깅을 중단합니다." 클럭 타이밍 의미로는 추정하기가 매우 어렵습니다.

그러나 추상화를 사용하면 실제 시간을 몇 시간 또는 며칠 안에 집중하지 않고 다른 작업에 비해 작업의 상대적 비용과 복잡성을 설명하는 데 중점을 둡니다. 인간 / 개발자가 더 좋습니다. 그런 다음,이 포인트 추정치와 실제 진행 상황으로 허밍하면 시간을보다 경험적으로 볼 수 있습니다.

점 추정치에서는 발생하지 않는 시간 추정치에서 발생하는 관찰자 효과도 있다고 생각합니다. 예를 들어, 예측을 샌드백하고 "일정표를 앞당기"는 방법은 포인트 기반 시스템에서 간접적으로 음소거 될 수있는 인센티브입니다.

피보나치 수 (또는 이와 유사한 것)를 사용하는 경우 스토리를 추정 할 때 옵션 수를 제한합니다. 나는 1, 2, 3, 5, 8, 13의 낮은 숫자만을 사용하는 그룹과 함께 일했습니다. 우리는 5의 참조 스토리를 가졌습니다.이를 통해 Planning Poker를 수행하면서 스토리의 복잡성에 대해 쉽게 결정을 내릴 수있었습니다. . 다른 부작용은 13 등급으로 평가 된 모든 정보가 충분하지 않아서 더 세분화해야한다는 것입니다. 우리가 원시 시간을 사용한다면 그렇게 쉽고 간단했을 것입니다.

제품 소유자는 이해 관계자의 언어를 말하며 필요에 따라 스토리 포인트와 인력 (또는 다른 단위)간에 번역 할 수 있어야합니다. PO로서의 시간 동안, 나는 1 스토리 포인트 = 4 시간이라는 하드 데이터를 가지고 있었지만 분명히 모든 팀은 다릅니다.

편집하다:

1 포인트 = 4 시간이라는 지식을 통해 이론적으로 Planning Poker 데크를 4, 8, 12, 20, 32 및 52로 변경할 수 있습니다. 그러나 이러한 수치는 다루기가 더 어려워집니다. 예를 들어 "하루 미만", "1 주일 이상"등의 값으로 정신적으로 값을 추상화 할 수 있다고 생각합니다. 그렇게하려는 경우 추상 단위를 고수 할 수도 있습니다. 적은 이야기 포인트.

추정자가 모두 추정값을 조정하지 않아도 시간이 지남에 따라 추정값이 향상되도록 할 수 있습니다.

추정에 관여하는 모든 사람들이 "OK .. 2 사람의 날처럼 보인다"고 생각하지만 마지막 스프린트는 모든 것을 과소 평가 했으므로 실제로 2.5 사람의 날이거나 3 일까? "5 이야기 포인트!"

그런 다음 이전 스프린트에서 실제로 측정 된 성과를 기반으로 스프린트에서 팀이 달성 할 수있는 스토리 포인트 수에 대한 추정값을 조정합니다. "우리는 이전에 스프린트 당 90-110 스토리 포인트를 수행했습니다!"

이것 뒤에있는 이론은 개발자들이 절대치 를 추정하는 것보다 다른 개발 작업의 상대적 복잡성을 추정하는 것이 더 낫다는 것 입니다. 특히 여러 사람이 그들 중 한 사람이 수행 할 수있는 작업을 추정하는 경우 (모든 사람이 다른 사람과 동일한 속도로 작동하는 것은 아님).

냉소적 대안 : 개발자들이 시간 추정치에 결코 도달하지 않는다고 말했습니다. 예상보다 오래 걸리면 끝났습니다. 그러나 예상 보다 시간 이 덜 걸리면 개발자는 금박을 입히거나 금판을 느리게하거나 느리게 할당하고 편한 임무를 부여받은 후 쉽게 처리 할 수 ​​있습니다. 실제 시간 단위를 추정값에서 벗어나면 이러한 경향이 억제 될 수 있습니다. 냉소적 인 대안을 끝내십시오.

요일이나 요일은 구체적입니다. 따라서 작업이 5 시간으로 추정되고 6 시간이 걸리면 이제 늦은 작업입니다.

이야기가 3 점이고 6 시간이 걸리고 6 시간이 걸리고 늦지 않았으며 단지 6 시간이 걸렸습니다. 속도 측정은 스프린트에서 수행되는 포인트의 수에 영향을 미치며 그 수치는 구체적이지 않기 때문에 변동될 수 있습니다. 또한 각 작업을 측정하는 것이 아니라 모든 작업의 ​​총계를 측정합니다. 각 작업에 시간이 있으면 각 작업을 측정하려는 유혹이 있습니다. 그렇게되면, 시간 내에 마무리를한다면 스프린트에 도움이되지 않으며, 주어진 시간이 지남에 따라 마무리하면 결과가 나타납니다.

그것은 관점에서 사고로의 전환이 될 수 있습니다. 노력 수준에 대한 아이디어를 얻기 위해 민첩한 중고 티셔츠 크기를 소개하기도 전에 한 곳에서 근무했습니다. 포인트는 그 확장 일뿐입니다.

그것은 논란이나 주장에 대한 임의의 할당이 없다고 말하는 것이 아닙니다. 우리는 거의 항상 가장 적은 수의 투표를 한 팀원을 보유하고 있으며, 과제가 1이라고 생각할 때 불평하고 포인트 인플레이션으로 고통 받고있는 것이 3이라고 생각합니다.

추상화는 일종의 요점입니다. '매일'을 측정 값으로 사용하면 다음과 같은 여러 가지 위험이 있습니다.

1. 팀이 사용할 기술에 익숙하지 않으면 작업 시간이 얼마나 걸리는지 실시간으로 예측하기가 어려울 수 있습니다. 예를 들어 "작업 A는 작업 B보다 두 배나 오래 걸릴 것입니다."
2. 다른 사람들은 다른 속도로 일합니다! '일수'를 사용하는 경우 작업이 한 개발자에서 다른 개발자로 전달 될 때 예상 시간을 거의 변경해야합니다. 어쨌든 누가 '맨 데이'를 구성 하는가?

요일을 추정하려면 간단한 계산입니다.

user points in story / average user points per developer per day = estimated man days

이미 언급했듯이 스토리 포인트는 상대적으로 복잡한 측정 기준입니다. 추정을 위해 2 시리즈 (1,2,4,8,16 ...) 또는 피보나치 스케일 (1,2,3,5,8,13,20 ...)의 거듭 제곱을 사용할 수 있습니다. 배우자로서 다음과 같은 말을하는 데 능숙합니다.

기능 A는 기능 B의 거의 두 배입니다.

그러나이 기능을 구현하는 데 '얼마나 오래 걸립니까'라고 말하기는 정말 어렵습니다. 속도에 따라 균형을 잡습니다. 따라서 무언가가 5로 추정되었지만 13으로 밝혀지면 속도가 느릴수록 반복 속도가 정상화됩니다 (또는 다시 추정 할 수 있음).

또 다른 대안이 있습니다. '이상적인 날'(일부 날과 비슷하지만 그게 무슨 뜻인지 잘 모르겠습니다)을 선호하는 팀이 몇 군데 있습니다. 이상적인 날은 다음과 같이 해석됩니다.

그것이 사무실에 와서 필요한 휴식을 취한 후에 내가하는 모든 일이라면 방해를받지 않으며, '이야기 구현'에 필요한 모든 것을 가질 것입니다.

민첩한 전도자 중 한 명인 마이크 콘 (Mike Cohn)은 이야기 포인트와 이상적인 날을 다음과 같이 비교합니다.

스토리 포인트

• 기능 간 행동을 유도하는 데 도움이됩니다. 즉, 팀은 UI에서 DB에 이르기까지 모든 구현 복잡성에 대한 스토리를 추정합니다.
• SP 견적은 쇠퇴하지 않습니다. 지금부터 5 개월 이야기는 5 포인트가 될 것 같지만 특정 프로그래머의 습득 된 개발 기술 / 속도에 따라 이상적인 일일 견적이 변경 될 수 있습니다.
• SP는 크기의 순수한 척도입니다. 즉, 크기와 복잡성 만 반영합니다. 기간. 지속 시간 등이 없습니다. 그것은 속도의 일입니다. 그러나 이상적인 날에는 그렇지 않습니다. 실제로 이상적인 날에는 달력 일과 혼동하는 경향이 있습니다. SP가 현실과 비교하려는 유혹과 싸울 때 추상적을 유지하십시오. 크기의 측정치입니다. 말도 안돼.
• 일반적으로 이상적인 날보다 빠릅니다. 처음 몇 이야기에는 까다로울 수 있지만 일단 중단되면 더 빠릅니다.
• 다른 개발자는 이야기를 완성하기위한 이상적인 하루 추정치를 다르게 가질 수 있습니다. 나는 3에서 똑같이 할 수 있고 5에서 할 수 있습니다. SP는 전반적으로 다소 균일합니다. 말을하기 위해 경기장을 평평하게합니다.

이상적인 날

• 팀 외부에서 설명하기 쉬움; 명백한 이유로 :)
• 위에서 언급 한대로 처음에 더 쉽게 추정 할 수 있습니다. 그러나 일단 SP를 중단하면 자연스럽게 제공됩니다.

이제 어느 쪽을 선택할 것인지는 팀에게 달려 있습니다. 그러나 대부분의 답변과 개인적인 경험으로 이야기 포인트를 선호합니다. 이상적인 날에는 실제로 SP에 비해 많은 이점이 없습니다 (Mike Cohn은 다른 많은 민첩한 전도자와 함께 SP를지지합니다).

스토리 포인트는 또한 시간이 지남에 따라 팀의 성능 향상을 측정하는 데 도움이됩니다. 또한 성능이 향상됨에 따라 모든 것을 다시 추정 할 필요는 없습니다.

man days를 사용하는이 예제를 보자.

팀은 근무일과 다른 작업을 추정합니다. 잠시 동안 작동하지만 얼마 후 팀이 원래 생각했던 것보다 많은 작업으로 더 빨리 완료되었음을 알 수 있습니다. 따라서 팀 은 작업을 재 추정 합니다. 그것은 잠시 동안 작동하고 얼마 후에 다시 똑같은 것을 보게됩니다 : 팀은 많은 작업으로 다시 빠르게 완료됩니다. 그래서 당신은 다시 추정 하고,이 이야기는 계속 반복되고 또 다시 반복됩니다.

왜? 팀 의 성과 가 향상 되었기 때문입니다. 그러나 당신은 그것에 대해 모른다.

스토리 포인트와 동일한 예 :

팀 은 사용자 스토리 의 크기 를 추정합니다 . 스프린트 후 팀은 스프린트 당 약 60 스토리 포인트를 수행 할 수 있습니다. 나중에 팀이 60 개가 넘는 스토리 포인트를 달성했음을 알 수 있습니다. 팀은 계속 그렇게하고 다음 스프린트를 위해 더 많은 사용자 스토리를 끌어와 전달합니다.

왜? 성능 이 향상 되었기 때문입니다. 그리고 당신은 그것을 측정 할 수 있습니다. 또한 팀의 성과가 높아진 후에 모든 것을 재 추정 할 필요는 없습니다.

첫째, 사람들은 절대 추정치보다 상대적 추정치가 더 좋습니다. 바빌로니아 사람들은 별의 상대적 밝기를 매핑하고 평가하는 것이 좋은 예입니다. 그들은 절대 수치를 올바르게 얻지 못했지만 매우 유사한 강도에서도 대부분 순서가 나타났습니다.

두 번째 장점은이 연습을 수행하는 주된 이유는 대화를 유도하는 것입니다. 정확한 요일에 대화를 시작하면 대화가 빨리 탈선 될 수 있습니다.

나폴레옹이 말했듯이, 계획은 가치가 없으며 계획은 매우 중요합니다.

셋째, 프로젝트 관리자는 모든 추정치를 편집 할 필요는 없습니다. 단지 추정치가 예를 들어 130 %의 요인으로 인해 소멸되었다는 것입니다.

스토리 포인트는 문제의 복잡성을 반영하므로 추정이 얼마나 정확한지에 대한 자신감 (또는 위험)을 반영합니다.

스토리 포인트가 높은 스토리는 구체적이지 않은 사용자 스토리와 관련하여 많은 일이 진행되고 있음을 알려줍니다.

아이디어는 다양한 스토리 포인트의 균형이 좋은지 확인하는 것입니다. 높은 스토리 포인트가있는 스토리가 포함 된 반복 계획이 표시되면 반복이 예상대로 실행되고 반복을 위해 다른 스토리를 보거나 스토리를 분해해야한다는 확신이 거의 없습니다.

관리자 나 제품 소유자와 통신 할 때 스토리 포인트가 높으면 특정 기능을 사용할 수있는 시점이 매우 흐릿하다는 것을 의미합니다. 이에 대한 해결책 중 하나는 스토리를 세분화하는 것이며 제품 소유자에게 진행 상황을 반복적으로 보여줄 수 있도록 낮은 스토리 포인트와 높은 스토리 포인트를 함께 사용할 수 있기를 바랍니다.

일수 는 무언가를하는 데 걸리는 시간을 추정합니다. 추정하는 항목이 매우 정확하고 측정 가능할 때 가장 잘 사용됩니다. 잘 알려진 구체적이고 반복 가능한 작업은 사람의 날에 추정 할 수 있습니다.

예를 들어, 영업 사원이 하루에 20 건의 고객 통화를 할 수있는 경우 평균적으로 각 통화에 걸리는 시간을 계산할 수 있으며 그로부터 1000 회 전화를하는 데 소요되는 일수를 추정 할 수 있습니다.

이 예에서, 모든 통화가 사실상 동일한 것으로 가정 될 수 있기 때문에 통화의 중간 길이에 관한 통계적 용어로 구체적으로 생각할 수있다.

스토리 포인트 는 반복에서 수행 할 수있는 스토리 조합을 결정합니다. 이기종 목표를 퍼지 경계와 결합하고 고정 된 시간 프레임에서 수행 할 수있는 수를 측정하는 데 사용됩니다. 그들은 작업 덩어리 를 서로 비교할 수 있도록 서로 비교하여 작업 덩어리의 복잡성을 추정합니다 .

예를 들어, 팀은 반복 1에서 총 23 포인트, 반복 2에서 20 개에서 8 층으로 5 개의 스토리를 개발했습니다. 이로부터 반복 2에서 팀은 총 20 포인트 정도의 몇 가지 스토리를 수행 할 것으로 추정 할 수 있습니다. 반복적으로 3.

우리는 한 점의 크기를 결정할 필요가 없으며, 특히 같은 크기의 각 스토리를 개발하는 데 같은 시간이 걸릴 것이라는 가정은 없습니다! 우리는 합계와 반복 당 포인트에 대해서만 작업합니다. 반복이 얼마나 긴지는 언급하지 않았습니다.

길거리에서 인간에게 걸어 가서 "T-rex는 얼마나 큰가?"라고 물으면 비록 대다수의 인간이 T-rex가 무엇인지, 그것이 얼마나 큰지 알지만, 실제로는 아무도 알지 못합니다. 기준에 대한 상대적인 규모가 없기 때문입니다.

그것은 당신이 예측으로 알아 내려고하는인지 적 행동이며, " 나는 그것을 얻었습니다! .. 나는 정확한 예측의 비밀을 가지고 있습니다! "뱀 오일을 대중에게 전달합니다. 당신이 실제로 예측할 때, 당신은 실제로 " 나는 그것을 완료하기 위해 x 일 / 시간 / 포인트를 허용 할 것입니다 "라고 말하고 있습니다 -그것은 그 사건이 수행 될 "타임 박스"를 만드는 의미에서 "입니다.

나를 위해, 당신은 " * 우리는 스프린트 당 3 주가 있고 엄지 손가락을 빨고 ... 나는 우리가 쏴야 할 그림 을 말하고 기뻐하는 팀이 아닌 한 하루가 끝날 때 포인트가 경계를 이동하고 있습니다. 이 사이클에서 30 점을 완수하십시오! 나와 함께있는 사람! * "그리고 예측 모델링에 들어가는 깊이 – 괜찮습니다! .. 실제로 당신은 임의의 예산을 설정하고 있습니다. 당신은 또한 회고 적으로 "거룩한 쓰레기, 우리는 스프린트, 꽤 멋진 33pts를했다"라는 느낌으로 완성 된 작품을보고 있습니다. " 우리는 아직 15pt를 달성 했습니까?"라고 외치면서 속도를 사용하여 예산 부담에 대비할 수있는 중간 스프린트를 결정할 수 있습니다."그러나 여기서 위험은 이제 속도를 사용하여 용량이 아닌 생산성을 측정하는 것입니다. 이는 내가 이해 한 것으로부터 반응 형 릴리스 관리 (스토리 포인트)를 유발하는 것입니다 ..

포인트 시스템은 합의 된 "스프린트 사이클"부터 데일리 스탠드 업에 이르기까지 지속 시간 + 복잡성 = " 최대 시간 이 오래 걸림 그 작업 "선천적 인 직감 느낌 팀 코드 레드 순간?

인간의 두뇌는 장기 / 단기 리콜과 혼합 된 많은 작업 메모리를 포함하기 때문에 예측할 수 없으므로, 초보 수학 학생에게 종이가 아닌 머리에 분수를 표시하도록 요구하는 것과 같습니다. 상대 시간에 예측을 지속적으로 검증합니다 (예 : 지질학자는 입방 미터가 땅에서 파고 나서 "완료"될 때까지 예측 모델링을 중단하지 않습니다).

예측하지 않으면 포인트 시스템이 작동한다고 말하고 싶습니다 . 하위 청크 알고리즘을 기반으로하는 작업에 동의하지만 가능한 한 예측에 가장 근접한 접근 방식입니다. 실제로 릴리스 관리자는 테마에 맞는 "백 로그"대기열에서 자연스럽게 끊어 질 수 있습니다 (즉, Silverlight에서 제품 관리자는 백 로그를 완료하고 초기에 설정 한 테마를 구성 할 때까지 기다릴 것입니다. 엔지니어링 팀이 무엇을하고 있는지 정확히 알지 못했을뿐입니다. 우리는 기본 개요 만 가지고 있습니다.

속도 + 시간에 의존하는 스프린트 사이클 내에서 속도 예상을 잠그기 시작하면 "게임에 의존합니다"를 플레이하고 있기 때문에 이번에는 최악의 상황 만 다시 예측을 다시 예측할 수 있습니다. 또한 팀 성장 / 커리어 성장의 잠재력을 죽이고 있습니다.

포인트 대 시간에 대해 지불하는 세금은 실무 기술 개발 / 멘토링 또는 개발자 행동을 추적하기 위해 대체 측정 공식을 찾아야하는 포인트입니다.

기술 / 노력을 전하기위한 이상적인 사람으로 "중앙 개발자"를 계속 살펴보아야 할 때, 해당 직원을 가진 다른 개발자를 기준으로 팀 내에서 지속적인 성장에 어떻게 공평한 지 결정할 수 있습니다. 또한 "빠른"개발자들이 대부분의 물을 가지고 있지만 지루하거나 더 심해지면서 더 긴 시간을 일하고 경쟁 마감일 등으로 인해 인식 / 보상을받지 못하는 상황을 강조합니다. 스탠드 업은 실제로 이것을 발굴하지 않습니다. "사람이 어려움을 겪고있다, 도움을 준다"에서 말한 것처럼 팀 내에서 악취를 감지하기 위해

다음은 또한 "스 캐리 오버"스토리, 스프린트 사이클에 청크되지 않은 다음 스프린트 사이클로 넘어가는 스토리를 제공합니다. 그러면 시간을 고려할 때 쉽게 효과를 만들 수 있지만 상대 시간을 고려하는 순간은 다시 "시간 기반 예측 / 추정"으로 되돌아 가고 다시 포인트 시스템은 물을 진흙탕.

당신이 포인트를 가면 당신은 시간을 완전히 무시하고 당신이 아이디어 / 방법론을 게임하고 있음을 느끼는 순간을 완전히 의미합니다.

전도자로 세계를 여행하는 데, "나는 팀의 많은 그들이 애자일 예측 코드를 금 것을 소중히 무엇에 손을 맹세했다 ...하지만 난 항상 내 혀를 클릭, 미소 멀리 생각에 걸어 네 ... 당신은 거의했지만, 우리가 '시간'이라고 부르는 그 여주인 ... 그녀는 단지 잔인합니다 ... "

Mike Cohn의 책 "Agile Estimating and Planning"은 "이상적인 날"또는 스토리 포인트를 사용하여 추정 할 때의 장단점을 설명하므로 질문에 대한 빠른 답변은 스토리 포인트로 추정 할 필요가 없다는 것입니다. 이상적인 날에 추정하는 것이 더 자연스러운 경우 바로 진행하십시오.

Story Point 방법은 Man-day 방법에 비해 두 가지 중요한 장점이 있다고 생각합니다. 첫째, SP에서 추정하기가 더 쉽습니다. SP는 상대적이며 인간과 마찬가지로 인간은 인간 방법과 같은 절대 추정보다 낫습니다.

둘째, SP에서 추정하면 "개인 Manday"가 아닌 "Team SP"가됩니다. "이 작업이 얼마나 오래 걸립니까?"라고 물으면 선임 개발자는 주니어에게 1 일 5 일을 줄 수 있습니다. 맨 데이는 누가 그 일을 수행 할 것인지에 달려 있습니다. 소유자가 강제로 변경되면 모든 일정을 다시 예약해야합니다. SP를 사용하면 여전히 작업을 수행하는 사람이 동일합니다.

아직 파킨슨의 법칙 을 언급 한 사람이 아무도 없습니다 .

작업 완료 시간을 채우기 위해 작업이 확장됩니다.

기본적으로 대규모 작업에 대해 어떤 종류의 시간 단위로도 추정하는 경우 개발자는 완료 또는 완료하는 데 예상되는 시간이 걸리는 경향이 있습니다. 스토리 포인트 또는 셔츠 크기와 같은 끔찍한 시간을 예상 할 때이 함정을 피하십시오.

스토리 포인트 추정은 피보나치 시리즈 1,2,3,5,8,13,21을 따릅니다 ...

인간의 뇌는 크기에 따라 쉽게 물건을 매핑 할 수 있습니다. 예를 들어 : 포스트잇 카드가 있고 스토리 포인트 2를 할당하고 3 개의 포스트잇 카드 크기는 2 * 3 = 6 스토리 포인트를 의미합니다.

스토리 포인트 6은 피보나치 시리즈 번호 5와 8 사이에 있으며 5가 가장 가까운 숫자이므로 스토리 포인트는 5가됩니다.