Почему мы используем Story Points?

Ответ простой. Посмотрим на альтернативы.

А альтернатива - это идеальные часы, дни или что-то другое со вренем.

Кстати, проясню, идеальный день равен 6 идеальным часам. Сами ведь понимаете, что нужно и по нужде сбегать, и с коллегами поговорить, и звонки могут быть, да и просто мой блог почитать и на курс ко мне сходить :)

Story Points - это трудоёмкость оцениваемая командой во время планирования. Это не время, очень большая ошибка перейти на оценку в идеальных часах. Почему?

Расказываю.

Вариант 1. Идеальные дни.
Напомню, функциональные требования (User Stories) оцениваются в идеальных днях. А задачи, на которые разбиваются требования в идеальных часах.

Итак у нас команда из 5 разработчиков. Итерация 2 недели. Сколько мы наберём работы? Посчитаем - 5 разработчиков x 2 недели x 5 дней x 6 идеальных часа в день = 300 часов. Ну мы собственно и набираем задач. В конце итерации выясняется, что мы сделали работы на 200 часов.

Стоит вопрос - нужно переоценить требования? или укоротить идеальный час? или набирать теперь часов не 300, а на 200 в следующий раз? А что делать с новыми задачами? Их сразу домножать на коэфициент? или ввести термин "идеальная итерация" состоящая из 200 часов. Куча вопросов и у меня нет на них ответа. Потому что это не Agile ;) А заниматься классическими расчётами, как учат нас книги по менеджменту и придумывать теории производительности - крайне неэффективно.

Поэтому рассмотрим вариант 2.

Вариант 2 (по Agile). Меряем User Stories (функциональные требования) с помощью Story Points.

Во время обучения меня срашивают, что такое Story Points? А я отвечаю
1) это сипульки
2) прошу понаблюдать за игрой слов - User Stories -> Story Points
3) мера трудоёмкости
4) мера не времени, а бизнес-значимости, так как бесполезные вещи для бизнес не оцениваются в Story Points. график убывания (burndown) показывает как значимые вещи реализуются в коде.

А теперь вернёмся к нашей команде в 5 человек. После планирования они поняли, что трудоёмкость итерации 150 Story Points. Итерация. Результат - 100 сделали.
А теперь магия корректировки скорости.
фокус фактор = сделанные Story Points / ресурс в идеальных часах = 100 / 300 = 33%

Что значит 33%? Это соотношение стори-поинтов к идеальному времени. В следующий итерации один разработчик ушёл в отпуск. Как вы посчитаете сколько вы за итерацию осилите? берём идеальные часы (ресурс) - 240 часов и множим на 33% - получаем нужно набрать требований на 80 Story Points.

Причем заметьте:
1) нам не нужно адаптировать свои оценки сложности
2) мы не задумываемся о своей неверной оценке одного требования, как впрочем и целого набора
3) 1 проработанный час не всегда равен 1 выработанной Story Point. Банально много много времени бесполезно сидеть, а бизнес-выхлопа никакого. Если ежедневно считать, сколько осталось Story Points сделать до конца итерации. То можно заметить - время течёт, а бизнес стоит. Сразу можно оперативно реагировать.
4) если каждую итерацию мерить свою скорость в story point можете увидеть очень интересную картинку. особенно меня радует, когда команда занимается рефакторингом, тогда просест графика в ноль гарантирован :) хуже, когда график проседает в итерации, где добавляются полезные фичи.

А дальше обширное поле игры с фокус-фактором. Хотим время на стабилизацию - делаем цифирку поменьше. Хотим поработать по выходным - побольше :)

Продолжение: http://denismiller.blogspot.com/2009/02/story-points.html