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

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

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

В этой главе мы рассмотрим два способа, которые подходят для быстрой оценки сущностей размером в квартал, то есть тех, которые требуют от трех до шести месяцев для реализации. Эти способы называются оценкой по «ведрам» (bucket system estimation) и оценкой по сходству (affinity estimation).

4.3.5.1. Ретроспективная оценка трудозатрат

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

Для наглядности можно построить таблицу, где:

➠ Эпик – это название эпика, который был выполнен командой.

➠ Сторипоинты – это сумма всех сторипоинтов, затраченных на эпик с момента старта команды.

➠ Юзерстори – это сумма всех юзерстори, выполненных по эпику с момента старта команды.

➠ Дни команды – это оценка трудозатрат в днях команды на эпик, рассчитанная по формуле:

Табл. 4.8. Пример таблицы с расчетом количества затраченных дней

В табл. 4.8 предполагается, что команда выполнила 200 сторипоинтов за 40 рабочих дней. Тогда, например, для эпика «Внедрение дизайн-системы» оценка трудозатрат в днях команды будет равна:

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

В свое время я делал оценку трудозатрат на эпики для бэклога, которому было несколько лет. Интересно, что, если сравнить расчет трудозатрат через долю в стори пойнтах с расчетом через долю количества юзерстори, то разница оказывается менее 10 % (один день из двух недель спринта), поэтому я решил использовать среднее арифметическое из оценок этих двух методов.

4.3.5.2. Оценка по «ведрам»

Далее можно прибегнуть к оценке по «ведрам». Это метод, при котором сущности распределяются по группам («ведрам») в зависимости от их сложности или затрат времени. Каждое «ведро» имеет свое значение, которое может быть выражено в сторипоинтах, часах, днях или других единицах измерения. Значения «ведер» обычно выбираются так, чтобы они отражали нелинейный рост сложности сущностей. Например, «ведра» могут иметь значения 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 и т. д. Для примера, приведенного выше, можно присвоить значения в юзерстори или в сторипоинтах с шагом 0, 10, 20 и т. д.

Для проведения оценки по «ведрам» необходимо собрать команду, которая будет участвовать в оценке, и подготовить материалы, такие как карточки с описанием сущностей, карточки со значениями «ведер», стикеры, маркеры и т. д. Также можно использовать онлайн инструменты, такие как Miro или Figjam.

1. Разместить карточки со значениями «ведер» на столе или на стене в порядке возрастания.

2. Расположить карточки с уже оцененными эпиками из табл. 4.7, сформованные ранее, по «ведрам» в соответствии с размером.

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

4. Посмотреть на распределение сущностей по «ведрам» и обсудить с командой, есть ли какие-то несоответствия, противоречия или сомнения. Перемещать сущности между «ведрами», пока не будет достигнуто согласие по всем сущностям.

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

4.3.5.3. Оценка по сходству

Другой способ быстрой оценки сущностей размером 1–3 мес. (эпик) – это оценка по сходству. Этот метод подходит для команд, которые только начали работать и не имеют ретроспективных данных о трудозатратах на предыдущие сущности. Оценка по сходству заключается в том, что эпики сортируются по порядку от самой простой до самой сложной, а затем оцениваются по сравнению с крайними эпиками.

1. Сначала участники индивидуально сортируют карточки-эпики от самых простых до самых сложных.

2. Затем на основе индивидуальных рейтингов формируется групповой рейтинг (сумма рейтингов участников для каждого эпика).

3. Карточки с эпиками выстраиваются в ряд в соответствии групповым рейтингом и команде предлагается обсудить получившийся порядок и при необходимости совершить перестановку.

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

5. Трудозатраты для промежуточных карточек оцениваются путем линейной интерполяции оценок крайних эпиков.

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