Блог

Зачем оценивать пользовательские истории

Сен 21, 2021

В этой статье даётся пояснение о необходимости оценки пользовательских историй. Рассмотрены различные виды оценок.

Зачем оценивать

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

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

Следующий шаг – создание пользовательских историй, из которых будет составлен бэклог продукта.

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

От точности оценки пользовательских историй будет зависеть дальнейшая судьба проекта.

Как оценивать пользовательские истории

Традиционная абсолютная временна́я оценка

В данном случае предпочитают использовать идеальные дни, идеальные часы или просто человеко-дни или человеко-часы.

Плюсы такой оценки:

  • Простая и понятная оценка по времени, которую легко воспринять заказчику: эту фичу сделаем за 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-го спринта.

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

Новое в блоге

Разработка через прототипирование

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

Современный подход к подготовке технической документации

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

Ряд тенденций, меняющих автомобильную промышленность

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