В этой статье даётся пояснение о необходимости оценки пользовательских историй. Рассмотрены различные виды оценок.
Зачем оценивать
Представим, что у нас появился новый заказчик, который хочет реализовать продукт быстро, качественно и недорого. Конечно, можно попробовать сразу оценить продукт навскидку, дать временну́ю и финансовую оценку проекта, пообещать учесть все пожелания. Однако при таком подходе велик риск, что продукт не реализуется в срок, что затраты выйдут за рамки бюджета, что функционал не будет соответствовать ожиданиям заказчика.
Чтобы избежать промаха, следует прежде всего убедиться, что вы и заказчик говорите об одних и тех же вещах. Для этого формируется устав проекта, включающий в себя общее видение функционала у всех участников. В рамках устава выполняется декомпозиция функционала проекта на более мелкие части. На этом этапе команда и заказчик вместе рассматривают все детали и договариваются о содержании проекта.
Следующий шаг – создание пользовательских историй, из которых будет составлен бэклог продукта.
Разработчики, являясь конечными исполнителями, могут оценить каждую историю в отдельности. Сумма оценок покажет примерный срок реализации проекта. Подобный подход является более точным, поскольку он включает в себя детализацию и показывает, что следует исключить из функционала с целью уложиться в срок и бюджет.
От точности оценки пользовательских историй будет зависеть дальнейшая судьба проекта.
Как оценивать пользовательские истории
Традиционная абсолютная временна́я оценка
В данном случае предпочитают использовать идеальные дни, идеальные часы или просто человеко-дни или человеко-часы.
Плюсы такой оценки:
- Простая и понятная оценка по времени, которую легко воспринять заказчику: эту фичу сделаем за 3 дня, эту за 14 дней и т.д.
- Её легко конвертировать в деньги: 1 час труда разработчика стоит $200. Фича на 3 часа стоит $600.
- Velocity. Если в команде 6 штатных разработчиков, работающих 5 дней в неделю, по 8 часов в день, тогда мы знаем, что их velocity на двухнедельный спринт составит 6*5*8*2=480 часов. Если мы оценили все истории продукта в 5500 часов, тогда логично сразу предположить, что проект будет готов через 6 месяцев.
Минусы такой оценки:
- Начальные пользовательские истории могут быть неверно оценены. К примеру, первая история оценена в 20 часов, а фактически на неё потрачено 40 часов. Если команда давала оценку остальным историям относительно этой, тогда собьются все оценки. В проекте, где для визуализации используются диаграммы Ганта, менеджеру придётся перекалькулировать всё сначала.
- Люди не умеют давать точные абсолютные оценки. На этот счёт есть множество популярных исследований.
Относительная оценка в стори поинтах
В качестве хороших примеров сюда можно отнести размеры маек (XS, S, M, L, XL), попугаев и т.п.
Плюсы оценки в стори поинтах:
- Стори поинты относительны и тем смягчают последствия неверной оценки. Предположим, что изначально бэклог был оценен в 5500 стори поинтов. При реализации одной из первых историй, оценённой в 8 стори поинтов, потребовалось не 8 часов, а 12. И что, теперь разработчикам придётся заново переоценить всё? Нет, ничего страшного не случилось. Да, velocity команды окажется ниже, бэклог следующего спринта будет сформирован с меньшим количеством стори поинтов, но сложность этой истории относительно других останется примерно той же.
- Например, история оценена в 2 стори поинта. Опытный разработчик сделает её за 2 часа, а начинающий – за 4. При этом новая оцениваемая история будет, с точки зрения обоих разработчиков, в одинаковое количество раз сложнее самой простой истории, оценённой в 1 стори поинт. В данном случае – в 2 раза. То есть оба разработчика согласятся, что это 2 стори поинта.
Минусы оценки в cтори поинтах:
- Стори поинты покажутся заказчику непонятными. При упоминании, что фича стоит 8 стори поинтов, велик риск остаться непонятым. В ответ можно услышать, что заплатят за неё 8 «попугаев».
- Достоверное соотношение между стори поинтами и временем их выполнения, включая значение velocity в cтори поинтах, установится только на 3-й или 4-й спринт.
- Стоимость cтори поинта варьируется от команды к команде. Поэтому вполне вероятна ситуация, когда команда с velocity 20 cтори поинтов за спринт выполняет объём работ, равный 40 cтори поинтам у другой команды.
Что выбрать для моего проекта?
- При выполнении краткосрочных проектов удобнее всего использовать традиционную временнýю оценку. Она понятна заказчику и легко конвертируется в деньги.
- При рассмотрении долгосрочных проектов лучше использовать стори поинты. На старте проекта проще сопоставить во сколько раз выбранные истории сложнее самой простой истории, чем пытаться оценить все истории в часах.
- На начальном этапе стори поинты тоже можно попробовать конвертировать в деньги. Сначала оцениваем самую простую историю в cтори поинтах, далее оцениваем её же по времени выполнения. Переводим оценку в деньги. Однако учтите, что точная стоимость одного cтори поинта сформируется только к концу 3-го или 4-го спринта.
В следующей статье мы расскажем о том, как и зачем оценивать подзадачи пользовательских историй.
