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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не значит, что здесь нет противоречий или какого-то произвольного назначения точек. У нас есть члены нашей команды, которые почти всегда голосуют за наименьшее число, и жалуются, когда считают, что задача - это 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, более медленная скорость нормализовала бы это для итерации (или вы могли бы переоценить).

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

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

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

Очки истории

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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