Почему при оценке пользовательских историй мы используем баллы за историю вместо человеческих дней?

132

В гибких методологиях (например, SCRUM) сложность / усилия, необходимые для пользовательских историй, измеряются в точках истории. Очки истории используются для расчета количества пользовательских историй, которые команда может взять за итерацию.

В чем преимущество введения абстрактной концепции (сюжетных точек), где мы можем просто использовать конкретное измерение, например, оценочные человеко-дни? Мы также можем рассчитать скорость, оценить охват итерации и т. Д. С использованием оценочных человеко-дней.

Напротив, сюжетные моменты сложнее использовать (потому что концепция абстрактна), а также сложнее объяснить заинтересованным сторонам. Какое преимущество это предлагает?

Луис Рис
источник
16
почему вы полагаете, что человек-день более конкретен, чем сюжет, не так.
Ryathal
4
Легче ли объяснить, что ваша оценка в 5 человеко-дней означает, что для ее завершения потребуется 1 месяц, поскольку ваша скорость составляет 0,25 человеко-дня / календарный день?
Патрик
3
@Izkata, это верно только в том случае, если ваша скорость всегда равна 1
Патрик
4
@Patrick При использовании человеко-дней (см. Человеко-часы в Википедии) понятие скорости отсутствует. Это проворная вещь.
Изката
3
Интересно то, что как только скорость стабилизируется, сюжетные точки имеют тенденцию отождествляться с определенным количеством часов или дней. Например, 1 очко истории = 1 день. Если я думаю, что это займет 2 дня, я буду оценивать 2 балла.
Джорджио

Ответы:

126

Я думаю, что одним из главных преимуществ является то, что люди и разработчики, в частности, довольно плохо оценивают время. Подумайте и о природе развития - это не линейная прогрессия от начала до конца. Часто «пишут 90% кода за 10 минут, а потом отрывают волосы в течение 17 часов». Это довольно сложно оценить в смысле часов.

Но использование абстракции снимает фокус с фактического времени в часах или днях и вместо этого делает акцент на описании относительных затрат и сложности задачи по сравнению с другими задачами. Люди / разработчики лучше в этом. И затем, как только вы начнете гудеть от этих точечных оценок и некоторого фактического прогресса, вы можете начать смотреть на время более эмпирически.

Я подозреваю, что есть также эффект наблюдателя, который случается с оценками времени, которые не происходят с точечными оценками. Например, стимул для оценки мешков с песком и доставки «с опережением графика» будет приглушен косвенным воздействием в системе, основанной на точках.

Эрик Дитрих
источник
28
+1 за акцент на сложности , а не на времени. Перевести на сырые часы будет легко, когда у вас будет достаточно спринтов под поясом. Я обнаружил, что различия между историями со временем стираются.
Кристо
14
В действительности, точки сложности могут быть более понятными, чем сюжетные точки, и любая задача, имеющая слишком много точек сложности, является слишком сложной и, вероятно, включает слишком много рисков и неизвестных факторов, чтобы иметь дело со всеми сразу. Сложность имеет экспоненциальную стоимость, и бедняга, который застрял с этой задачей, собирается вырыть яму настолько глубоко, что его больше не увидят в течение нескольких недель или месяцев. Лучше сделать более простую задачу: сначала понять сложную задачу и разделить ее на более мелкие задачи с менее рискованной и более понятной сложностью.
Супр
4
Время и стоимость - это следствие, сложность - причина, и вы не можете понять время, не понимая сложность.
Супр
8
Очки истории = точки сложности - 2 слога. :-D
Кристо
5
Кто-нибудь когда-нибудь считал, что сюжетные очки называются «стоимость кастинга»? => ботаник
Аарон Гибралтер
59

Если вы используете числа Фибоначчи (или что-то подобное), это ограничивает количество вариантов при оценке истории. Я работал с группой, в которой использовались только младшие цифры: 1, 2, 3, 5, 8 и 13. У нас был справочный материал, который был 5. Это позволило нам легко принимать быстрые решения по сложности истории при планировании покера. , Другим побочным эффектом было то, что что-либо с рейтингом 13, вероятно, было недостаточно информации и нуждалось в дальнейшем разборе. Я серьезно сомневаюсь, что было бы так легко и просто, если бы мы использовали сырые часы.

Владелец вашего продукта говорит на языке ваших заинтересованных сторон и должен иметь возможность переводить между историческими моментами и человеко-часами (или другими единицами) по мере необходимости. За время работы в ПО у меня были точные данные, что 1 очко истории = 4 человеко-часа, но, очевидно, каждая команда отличается.

Редактировать:

Зная, что 1 очко = 4 часа, вы можете теоретически изменить колоду Planning Poker на 4, 8, 12, 20, 32 и 52. Но с этими цифрами сложнее иметь дело. Я думаю, что мысленно абстрагирую значения обратно до чего-то простого, например, «меньше, чем за день», «больше, чем за неделю» и т. Д. И если я собираюсь это сделать, я мог бы также придерживаться абстрактной единицы без истории

Kristo
источник
Мы используем тот же метод, и наша колода планирования имеет более высокие числа, но мы определили 20 как значение, которое нужно разбить или определить лучше. Для нас 13 - наша самая большая задача, и обычно это задачи, которые заканчиваются целыми неделями.
Билл Липер
«Другим побочным эффектом было то, что что-либо с рейтингом 13, вероятно, было недостаточно информации и нуждалось в дальнейшем разборе». И я предполагаю, что если он будет разбит дальше, он будет разбит на эквивалентные части Фибоначчи?
Джо З.
@JoeZeng, да, они часто становятся 8 + 5 или 5 + 5 + 3. Это абстрактное измерение, поэтому, если новые истории достаточно близки, то я не слишком беспокоюсь. Команда обычно могла принять 13, ставшие две 8 или три 5, но три 8 означали, что мне нужно было провести разъясняющую беседу с заинтересованными сторонами. В идеале, мы оценили достаточно заранее, чтобы это не повлияло на текущий спринт.
Кристо
1
Не обязательно. У нас были предположения о том, что истории составляют 5 баллов, а более подробная разбитая сумма находится в диапазоне 15 баллов. Такое случается.
ashes999
24

Это позволяет оценке улучшаться с течением времени, и все оценщики не должны корректировать свои оценки.

Вместо того, чтобы всем, кто участвовал в оценке, приходилось думать: «Хорошо ... похоже, что это 2 человека в день ... но в прошлом спринте мы все недооценили, так что, может быть, это действительно 2,5 человека в день. "5 баллов!"

Затем вы корректируете свою оценку количества баллов, которые команда может набрать в спринте, исходя из фактического измеренного достижения в предыдущих спринтах. «Ранее мы делали 90-110 баллов за спринт!»

Я бы сказал, что теория, лежащая в основе этого, заключается в том, что разработчики лучше оценивают относительную сложность различных задач разработчиков, чем они оценивают абсолюты . Особенно, если несколько человек оценивают задачу, которую может выполнить любой из них (и не все работают с той же скоростью, что и все остальные).

Циничная альтернатива: я видел, как сказано, что разработчики никогда не приходят по смете времени. Если что-то занимает больше времени, чем предполагалось, вы прошли. Но если что-то занимает меньше времени, чем предполагалось, разработчики могут поиграть с этим, получить золотую табличку, или просто замедлиться и успокоиться, так как им дали удобное задание. Извлечение реальных оценок времени из оценки может обуздать эти тенденции. Конец циничной альтернативы.

Carson63000
источник
13
Это даже не так цинично. Это принцип «быстро или дешево или хорошо». Я могу дать вам в основном стабильную, в основном рабочую версию FizzBuzz, которая даст вам то, что вы обычно хотите в течение нескольких минут, но если вы хотите взаимодействия с пользователем, это займет больше времени, а если вы хотите регрессионное тестирование, это займет дольше, и если вы хотите, чтобы он не потерпел неудачу при нажатии MAX_INT, это займет больше времени. Скажите мне расставить приоритеты по скорости, и я начну сбрасывать требования. Скажи мне, чтобы расставить приоритеты во всем остальном, и я буду использовать все время, которое мне дают.
deworde
17

Человеческие дни или человеческие часы, как вы говорите, конкретные. Таким образом, когда задача оценивается в 5 часов и занимает 6, это теперь запоздалая задача.

Когда у вас есть история, которая составляет 3 очка, и это занимает 6 часов, это заняло 6 часов, это не поздно, это просто заняло шесть часов. Измерение скорости больше, чем фактор того, сколько из этих точек вы сделали в спринте, и это число может колебаться, потому что оно не является конкретным. Вы также измеряете не каждое задание, а общее количество всех заданий. Когда у вас есть часы на каждую задачу, возникает соблазн измерить каждую задачу. Когда это происходит, вы не получаете никакой выгоды от спринта за то, что он финишировал вовремя, и это является следствием того, что он финишировал за какое-то задание.

Это может быть переход к мышлению с точки зрения точек. В одном месте, где я работал, еще до того, как мы представили Agile, использовали размеры футболок, просто чтобы понять уровень усилий. Очки являются лишь продолжением этого.

Это не значит, что здесь нет противоречий или какого-то произвольного назначения точек. У нас есть члены нашей команды, которые почти всегда голосуют за наименьшее число, и жалуются, когда считают, что задача - это 1, а мы думаем, что это - 3, что мы страдаем от точечной инфляции.

Билл Липер
источник
13

Абстракция является своего рода точкой. Использование «человеческого дня» в качестве измерения имеет ряд подводных камней, в том числе:

  1. Если команда не знакома с технологией, которую они собираются использовать, то может быть очень сложно дать оценку в реальном времени того, сколько времени может занять задание. Они с большей вероятностью смогут дать хорошие относительные оценки - например, «задача A, вероятно, займет вдвое больше времени, чем задача B».
  2. Разные люди работают с разной скоростью! Если вы используете «человеко-дни», вам в значительной степени приходится менять оценку времени, когда задача передается от одного разработчика другому. Кто определяет, сколько работы составляет «человеческий день»?

Если вы хотите оценить человеко-дни, это простой расчет:

user points in story / average user points per developer per day = estimated man days
vaughandroid
источник
Что касается пункта 2: как сюжетный пункт решает это? Вы оцениваете историю как 4 балла. Вы отдаете его более быстрому программисту, и это занимает 4 дня. Вы даете это медленному программисту, и это занимает 8 дней. Мне кажется, что проблема не решена, а просто перемещена.
Джорджио
Относительно пункта 1. Идея состоит в том, что если команда ознакомится с технологиями, необходимыми для проекта, их скорость возрастет, и относительный размер историй, измеренных в историях, останется прежним. Но что, если две пользовательские истории требуют разных знаний? Например, у вас есть история пользователя для внешнего интерфейса в Javascript / HTML и история для пользователя в Java. По мере того, как команда узнает больше о Javascript, HTML и Java, они обнаруживают, что передняя часть намного проще, чем внутренняя часть, и относительные оценки историй снова неверны.
Джорджио
@ Джорджио Ре. пункт 2: у вашего более быстрого программиста скорость работы составляет 1 балл / день, а у более медленного программиста скорость работы составляет 0,5 балла / день. Если вы делаете это за несколько часов, либо ваш более быстрый программист собирается работать сам до смерти, либо ваш более медленный программист должен уволить. Ответ Билла Липера очень хорошо подтверждает это.
vaughandroid
1
Число рейнольдса Пункт 1: За мои деньги, если вы говорите о двух разных наборах технологий и двух разных областях продукта, у вас есть две команды.
vaughandroid
Дальше пункт 2: Пользовательские истории разрабатываются командой , а не отдельными разработчиками. Это рабочая скорость команды, которая является важной частью. Имейте в виду, что при реализации пользовательских историй вы должны сначала разбить их на задачи. Дай быстрее разработчику больше задач!
vaughandroid
6

Как уже упоминалось, сюжетные точки являются относительной мерой сложности. Для оценки можно использовать степень 2 серии (1,2,4,8,16 ...) или шкалу Фибоначчи (1,2,3,5,8,13,20 ...). Как утверждают разработчики, они вполне способны сказать что-то вроде этого:

Функция A почти в два раза сложнее, чем функция B

Но действительно трудно сказать, «сколько времени» эта функция займет для реализации. Вы позволяете этому быть сбалансированным по скорости. Таким образом, если что-то было оценено как 5, но оказалось 13, более медленная скорость нормализовала бы это для итерации (или вы могли бы переоценить).

Теперь есть другая альтернатива, она называется «идеальные дни» (некоторые из них похожи на человеко-дни, но я не уверена, что вы это имели в виду), и я знаю довольно много команд, которые предпочитают это. Идеальные дни следует интерпретировать как:

Если это все, что я делаю после прихода в офис и делаю только необходимые перерывы, не имею перерывов и буду иметь все, что мне нужно для «реализации истории», то есть никаких второстепенных действий, таких как встречи, ответы на письма и т. Д.,

Майк Кон, один из многих хорошо известных проворных евангелистов, дает следующее сравнение между историческими моментами и идеальными днями

Очки истории

  • Помогает управлять межфункциональным поведением, т. Е. Команды оценивают истории по всей сложности реализации от UI до DB и обратно.
  • Оценки SP не ослабевают, то есть через несколько месяцев 5-балльная история, вероятно, будет 5 баллами, но идеальная дневная оценка может измениться в зависимости от приобретенных навыков / скорости разработки данного конкретного программиста.
  • SP являются чистой мерой размера, т.е. они только и отражают только размер по сложности. Период. Нет продолжительности и т. Д., Бросил его. Это работа скорости. Но не так с идеальными днями. На самом деле в идеальных днях есть тенденция путать его с календарными днями. Сохранение его абстрактным, поскольку ИП борются с искушением сравнивать с реальностью. Просто мера размера. Никакой ерунды.
  • Обычно быстрее, чем идеальные дни. Это может быть сложно для первых двух историй, но как только вы освоитесь, это будет быстрее.
  • Разные разработчики могут по-разному оценивать свой идеальный день для завершения истории. Я мог бы сделать то же самое в 3, а вы могли бы в 5. SP более или менее единообразны по всем направлениям. Они выравнивают игровое поле, так сказать.

Идеальные дни

  • Легче объяснить вне команды; по понятным причинам :)
  • Сначала проще оценить, как указано выше. Но как только вы овладеете SP, это естественно

Теперь, какой из них выбрать, зависит от команды. Однако, поскольку большинство ответов здесь и мой личный опыт, я предпочитаю сюжетные моменты. Идеальные дни на самом деле не имеют такой большой пользы по сравнению с СП (и Майк Кон также защищает СП вместе со многими другими проворными евангелистами).

кандидат наук
источник
Следующее число Фибоначчи - 21, а не 20.
Джо З.
4
21 или 20 не имеет значения при оценке. SP округляют следующее число Фибоначчи, чтобы устранить чувство ложной точности. Следующее число в последовательности - не 34, а 40 (двойное число из 20), а затем 100. Числа представляют «неопределенность» в сложности, а не в точности. Это только приближение.
PhD
1
Это правда, я просто выбирал гниды (и шучу).
Джо З.
1
@PhD: «Оценки SP не ослабевают, т.е. через несколько месяцев история из 5 пунктов все еще может составлять 5 баллов, но идеальная оценка дня может измениться в зависимости от приобретенного навыка / скорости разработки данного конкретного программиста»: неявно предполагает, что команда будет улучшать свои навыки равномерно во всех областях проекта. Я не понимаю, почему это всегда должно быть так: некоторые части проекта (и технологии, необходимые для них) могут оказаться сложнее, чем другие, что делает первоначальную оценку относительных сложностей в сюжетных пунктах недействительной.
Джорджио
3

Очерки также помогут вам измерить улучшение производительности команды с течением времени. Кроме того, вам не нужно переоценивать все, поскольку производительность улучшается.

Возьмите этот пример, который использует человеко-дней:

Команда оценивает разные задачи в человеко-днях. Это работает некоторое время, но через некоторое время вы видите, что команда справляется со многими задачами быстрее, чем первоначально предполагалось. Таким образом, команда переоценивает задачи. Это работает некоторое время, и через некоторое время вы снова видите то же самое: команда снова справляется со многими задачами. Таким образом, вы переоцениваете снова, и эта история повторяется снова и снова и снова ...

Почему? Потому что производительность вашей команды увеличилась. Но вы не знаете об этом.

Тот же пример с историями:

Команда оценивает размер пользовательских историй. После нескольких спринтов вы видите, что команда может набрать около 60 баллов за спринт. Позже вы видите, что команда набрала более 60 сюжетных очков, может быть, 70. И команда продолжает в том же духе, набирает больше пользовательских историй для следующих спринтов и доставляет их.

Почему? Потому что производительность увеличилась. И вы можете измерить это. И вам не нужно переоценивать все после того, как производительность вашей команды повысилась.

UOOO
источник
3
«Почему? Потому что производительность вашей команды увеличилась.»: Альтернативное объяснение состоит в том, что через некоторое время команда начинает давать более точные / реалистичные оценки времени (так как они опоздали с некоторыми задачами в предыдущих спринтах, они начинают выделять больше времени, когда оценка историй для последующих спринтов).
Джорджио
2

Во-первых, люди лучше относительные оценки, чем абсолютные оценки. Вавилонский картографирование и оценка относительной яркости звезд является отличным примером. Они не поняли абсолютные цифры правильно, но порядок был в основном точен даже для очень похожих интенсивностей.

Второе преимущество заключается в том, что основной причиной выполнения этого упражнения является ведение разговора. Если вы начнете обсуждать в точные дни, разговор может быстро сорваться.

Как сказал Наполеон: план бесполезен, планирование бесценно.

В-третьих, руководителю проекта не нужно редактировать все оценки только потому, что оказывается, что оценки были отклонены, например, на 130%.

Tormod
источник
0

Очки истории отражают сложность проблемы и, следовательно, отражают уверенность (или риск) в том, насколько точна оценка.

История с высокой историей говорит мне, что с пользовательской историей многое происходит не конкретно.

Идея состоит в том, чтобы увидеть, каков хороший баланс различных сюжетных моментов. Если мне показывают план итерации с историями со всеми важными историями, это дает мне небольшую уверенность в том, что итерация будет выполнена, как ожидается, и что нам нужно посмотреть другие истории для итерации или начать разбивать истории на части.

При общении с менеджером или владельцем продукта высокие исторические моменты означают, что будет крайне туманно, когда они получат определенную функцию. Одно из решений этой проблемы состоит в том, чтобы разбить историю, и, надеюсь, у вас будет комбинация низких и высоких точек рассказа, чтобы вы могли многократно демонстрировать прогресс Владельцу продукта.

grumpasaurus
источник
0

Человеческие дни оценивают время, необходимое для того, чтобы что-то сделать. Их лучше всего использовать, когда оцениваемые вами элементы очень точны и измеримы. Конкретные, хорошо известные, повторяемые задачи оцениваются в человеко-днях.

Например, если продавец может в среднем совершать 20 звонков клиентов в день, мы можем рассчитать, сколько времени занимает каждый звонок, и исходя из этого, мы можем оценить, сколько человеко-дней потребуется, чтобы сделать 1000 звонков.

В этом примере можно конкретно представить в статистических терминах среднюю длину вызова, поскольку можно предположить, что все вызовы фактически являются одним и тем же.

Очки истории определяют, какую комбинацию историй можно сделать в итерации. Они используются для объединения разнородных целей с нечеткими границами и для измерения того, сколько можно сделать за фиксированный период времени. Они оценивают сложность кусков работы по сравнению друг с другом, чтобы иметь возможность сложить их вместе.

Например, ваша команда разработала 5 историй на общую сумму 23 балла в итерации 1 и 8 историй на 20 баллов в итерации 2. Исходя из этого, вы можете оценить, что во второй итерации ваша команда сделает несколько историй, общее количество которых составляет около 20 баллов. в итерации 3.

Обратите внимание, что нам не нужно определять размер одной точки, и, в частности, нет никаких предположений о том, что для разработки каждой истории одинакового размера потребуется одно и то же время! Мы работаем только с суммами и баллами за итерацию. Я даже не упомянул, как долго длится итерация.

Sklivvz
источник
0

Если вы подойдете к человеку на улице и спросите: «Насколько большим был T-rex?» ответы будут колебаться, даже если большинство людей знают, что такое T-rex, насколько он велик, но никто не знает наверняка - потому что у нас НЕТ относительного масштаба относительно исходного уровня.

Это когнитивное поведение, которое вы пытаетесь выяснить с помощью прогнозирования, и во многих методологиях крутятся циклы: « У меня есть! .. У меня есть секрет точного прогнозирования! » - змеиное масло в массы. Когда вы на самом деле делаете прогноз, вы на самом деле говорите вслух « Я ПОЗВОЛЮ x дней / часов / баллов для того, чтобы это завершилось » - это в некотором смысле создает «временной интервал» для того события, которое должно быть выполнено внутри.

Для меня Очки - это просто смещение границ, в конце дня, если вы не в команде, которая с радостью скажет " * Ну, у нас есть 3 недели на спринт, и большой палец сосет ... я думаю, что мы должны стрелять для 30 баллов для завершения в этом цикле! Кто со мной! * " .. поскольку реально вы просто устанавливаете арбитражный бюджет и все. Затем вы ретроспективно смотрите на работу, выполненную с чувством «святого дерьма, мы сделали 33 спринта, это было круто», и с этим ничего не поделаешь. Вы можете использовать скорость, чтобы определить, в середине спринта вы получаете удар по бюджету, спросив вслух: « Мы уже набрали 15 очков?«но опасность здесь в том, что вы сейчас используете Velocity для измерения производительности, а не емкости, что, как я понимаю, выбивает Reactive Release Management (исторические моменты) в голову».

Система баллов почти слишком умна, чтобы не замечать, что вы все еще относите относительное время к уравнению, все от ваших согласованных «циклов спринта» до ваших ежедневных переходов в режим ожидания, в которых вы вводите какое-то скрытое правило в отношении продолжительности + сложности = « Макс переводится в длительное время». с этой задачей "врожденное чувство кишки команды кода красный момент?

Человеческий мозг не может прогнозировать, потому что он включает в себя много рабочей памяти, смешанной с долгосрочным / краткосрочным отзывом, так что это все равно, что просить начинающего студента-математика делать дроби в голове, а не на бумаге. постоянно проверять прогнозы в относительном времени (например, геолог никогда не прекращает моделирование прогноза до тех пор, пока этот кубический метр не будет выкопан из земли, а затем его «выполнено»).

Я бы сказал, что система очков работает, если вы не прогнозируете . Вы соглашаетесь на кусок работы, основанный на алгоритме подколов, но это действительно ваш самый близкий подход к прогнозированию. Фактически, ваше управление выпусками будет искать естественные разрывы в очереди «невыполненных работ», которые соответствуют темам (т. Е. В Silverlight мы, менеджеры по продуктам, будем ждать до тех пор, пока они не завершат свое отставание и не соберут вместе темы, которые мы первоначально установили. мы никогда не знали, что конкретно делали инженерные команды, у нас была базовая схема. Затем мы взяли бы эту работу и построили вокруг нее наше маркетинговое мероприятие (Microsoft Mix).

Когда вы начинаете фиксировать ожидания скорости в спринтерских циклах, которые зависят от скорости + времени, вы снова возвращаетесь к прогнозированию оценок, только в этот раз вам хуже, потому что вы играете в игру «все зависит» ... Более важно, что вы также убивает потенциал для роста команды / карьерного роста.

Налог, который вы платите за Очки против Времени, - это баллы, которые вам нужно искать, чтобы найти альтернативные формулы измерения для отслеживания развития навыков / наставничества или поведения разработчика.

Поскольку вам все еще нужно будет рассматривать «медианного разработчика» как своего идеального человека, с которым нужно приложить умение / усилие, вы можете затем связать других разработчиков с этим человеком, чтобы определить, как они справляются со своим постоянным ростом в вашей команде. В нем также освещаются ситуации, когда «быстрые» разработчики несут большую часть воды, но им становится скучно или хуже, они работают дольше, и не получают признания / вознаграждения из-за конкурирующих сроков и т. Д. Состояния не обнаруживают этого в реальности, они действительно там, чтобы обнаружить плохие запахи в команде, скажем, как в «этот человек борется, давайте поможем»

Далее также идут истории «переноса», истории, которые не попадают в этот цикл спринта, а затем перетекают в следующий цикл спринта. Который затем может легко создать эффект «зацепки», если вы учитываете время, но в тот момент, когда вы учитываете относительное время ... снова, вы просто вернулись к «прогнозированию / оценке на основе времени», и снова система баллов просто мутит воду.

Если вы набираете очки, вы полностью игнорируете время, и я имею в виду полностью как момент, когда вы позволяете времени ползти, вы играете идею / методологию.

Путешествуя по миру как евангелист, я видел, как многие команды ругаются на то, что им дорого, что они взломали код Agile Forecast ... но я всегда щелкал языком, улыбался и уходил с мыслью: « Да ... ты почти сделал, но та хозяйка, которую мы называем "время" ... она просто жестока ... "

Скотт Барнс
источник
-1

В книге Майка Кона «Проворная оценка и планирование» описаны преимущества и недостатки оценки с «идеальными днями» или историческими баллами, поэтому быстрый ответ на ваш вопрос заключается в том, что вам не нужно оценивать с помощью баллов. Если в идеальные дни оценки более естественны, продолжайте.

Дэвид М
источник
1
Это не обязательно отвечает на вопрос; вместо этого он просто дает ссылку на книгу. Вы можете усилить свой ответ, предоставив краткое изложение преимуществ и недостатков.
-1

Я думаю, что метод Story Point имеет по крайней мере два важных преимущества перед методом Man-day: во-первых, его легче оценить в SP. SP относительна, а люди, подобные нам, лучше относительны, чем абсолютные оценки, как метод человеко-дня.

Во-вторых, когда вы оцениваете в SP, вы получаете «Team SP», а не «Individual Manday». Когда вы спрашиваете: «Сколько времени займет это задание?», Старший разработчик может дать вам 1 день, но 5 дней для младшего. Это Человек-день зависит от того, кто возьмет на себя эту задачу. Если владелец вынужден изменить (и это будет!), Вы должны перепланировать все. С SP это все тот же, кто бы ни взял на себя задачу.

Амп Танават
источник
-1

Я удивлен, что никто не упомянул Закон Паркинсона .

Работа расширяется, чтобы заполнить время, доступное для ее завершения.

В основном, если вы оцениваете единицу времени для больших задач, разработчики, как правило, тратят время, которое, по их оценкам, завершают или переходят. Когда вы оцениваете в туманное время, как Очки истории или Размеры рубашки, вы избегаете этой ловушки.

Вадим
источник
1
«Когда вы оцениваете в туманное время, как Очки истории или Размеры рубашек, вы избегаете этой ловушки.»: Не совсем: если для двухнедельного спринта мне были назначены две пользовательские истории на общую сумму 10 историй, я могу взять целых две недели и установите скорость 5 баллов в неделю. Я думаю, что повышение производительности больше связано с мотивацией команды и условиями труда, чем с устройством, используемым для измерения сложности задач.
Джорджио
Я имел в виду не повышение производительности, а скорее тот факт, что если оценка для истории выходит за 3 дня. Разработчик, скорее всего, займет 3 или более дней, чтобы закончить его, чем прийти по смете.
Вадим
Есть ли веские доказательства закона Паркинсона? Страница Википедии, кажется, не упоминает ничего.
BDSL
-2

Оценка сюжета следует за сериями Фибоначчи 1,2,3,5,8,13,21 ...

Человеческий мозг может легко отображать вещи в зависимости от размеров. Например: у нас есть открытка, и мы присваиваем ей 2 балла истории, а три поста размером карты будут означать 2 * 3 = 6 баллов.

Точка сюжета 6 находится между сериями Фибоначчи 5 и 8, где 5 - это более близкое число, и поэтому сюжетная точка будет 5.

Ecogreen
источник
1
Мы не отображаем вещи в зависимости от размера, мы фактически используем рабочую память, чтобы рассматривать их как «схемы» для работы. Вроде как наш мозг обладает небольшим объемом ОЗУ, и когда мы подаем небольшие различимые узоры в (Фибоначчи, A000079, размеры футболок и т. Д.), Они могут обратиться к нашим внутренним когнитивным силам, чтобы затем помочь проецировать в этом случае - ответ. Это действительно модель «относительного прогноза».
Скотт Барнс