Оценка времени для пользовательской истории - PullRequest
6 голосов
/ 05 декабря 2008

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

Ответы [ 4 ]

6 голосов
/ 05 декабря 2008

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

  • Задача A займет 2 единицы (произвольно)
  • Задача B примерно в 2 раза сложнее, чем Задача A (4 единицы)
  • Задание C примерно наполовину сложное (1 единица)

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

Эта техника взята из Agile Estimating and Planning Майка Кона, замечательной книги по этому вопросу.

2 голосов
/ 05 декабря 2008

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

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

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

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

2 голосов
/ 05 декабря 2008

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

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

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

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

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

0 голосов
/ 05 декабря 2008

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

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

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

...