Оценка времени для пользовательской истории

Question

Как вы оцениваете время, необходимое для реализации пользовательской истории?Если это что-то, что вы сделали раньше, вы знаете, сколько времени это займет.А что если для вас это совершенно новое?Сколько времени вы отводите на «сюрпризы»?

Answer 1

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

• Задача А займет 2 единицы (произвольно)
• Задача Б примерно в 2 раза сложнее задачи А (4 единицы).
• Задача С усложнилась примерно на половину (1 единица)

Мы лучше оцениваем относительную сложность, чем абсолютную.Потом вы фактически выполняете одну из задач, и прикидываете, сколько «реального времени» у вас уходит на реализацию 1 единицы — теперь вы можете просчитать все задачи.Вы продолжаете обновлять свои оценки в зависимости от вашего прогресса.

Эта техника из Гибкая оценка и планирование Майка Кона — отличная книга на эту тему.

Answer 2

В школе гибкой разработки XP они рекомендуют вам оценивать не в реальном времени, а в произвольных единицах. (Они используют & Quot; Gummy Bears & Quot; но вы можете использовать что угодно). Вы назначаете свое лучшее предположение относительно количества единиц, которые потребуются для реализации этой пользовательской истории.

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

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

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

Что касается сюрпризов, то на самом деле это не влияет на оценку пользовательских историй ... поскольку у вас нет пользовательских историй для представления сюрпризов.

Answer 3

Стив МакКоннел в & письме; Оценка программного обеспечения - демистификация черного искусства & Quot; сказал это лучше, чем я:

  

& "Посчитай, если это вообще возможно. Вычислить когда   Вы не можете & # 8217; t считать. Используйте суждение в одиночку   только в крайнем случае. "

Глава 7 - Считать, вычислять, судить (PDF).

(спасибо, что напомнили мне об этом:)

Answer 4

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

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

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