Расчёт ёмкости, или как мы гадаем на SP

Зачем всё это?

Исходные данные

Теория

Алгоритм расчёта

Побочка

Итог

Благодарности

Метод

Тезисно

Шаг 0. Расчёт FTE’ прошлого инкремента

Шаг 1. Расчет FF прошлых инкрементов

Шаг 2. Расчет FTE’ нового инкремента

Шаг 3. Расчет Capacity нового инкремента

Про то, как посчитать ёмкость задач разного уровня сложности написано немало, например эта статья. Ответу же на практический вопрос: «А сколько реально сможет взять команда?», – уделено меньше внимания. В рамках своей статьи поделюсь эмпирическим методом расчёта ёмкости на основании простых статистических данных.

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

Для работы понадобится:

Команда заинтересованных сотрудников;
Итеративный процесс разработки по любому из фреймфорков (SAFe, Scrum, каскадная модель и т.п.);
Некий принятый командой метод оценки (в нашем случае, Story Points);
Договорённости о правилах закрытия и переноса задач из спринта в спринт;
Графики отпусков/совмещений;
Статистика выполненных задач в прошлых итерациях (скорость команды).

Немного про статистику

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

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

Прежде чем приступить к расчёту, определимся с несколькими важными терминами:

Термин	Описание	Цель использования	Уменьшает влияние
Story Point (SP)	Мера относительной оценки задачи команды.	Даёт единую методику оценки, которой достаточно легко обучить большое количество сотрудников. Рассматривает эмпирические данные – фактически выполненную работу.	Позволяет уменьшить или исключить неопределенности с оценкой малоизвестных задач. Подход учитывает уровень профессиональных навыков команды, её компетенции и внутренние процессы.
Full Time Equivalent (FTE)	Мера включенности сотрудника в проект.	Показывает, сколько требуется человек для выполнения проекта или сколько сотрудников компания нанимает в течение финансового года. Держим в уме, что это 100% занятность в конкретном проекте. Для расчета FTE, общее количество отработанных часов сравнивается с количеством часов официального недельного графика полной занятости в компании (например, 40 часов в неделю). Для удобства и простоты, FTE считаем, как количество дней в спринте, которые работает участник команды.	Убирает из рассмотрения фреймворк команды. Нормирует индивидуальные графики работы членов команды – совмещения, отпуска, обучения и т.п.
Доля командных мероприятий	Мера командных временных затрат.	Показывает какую часть FTE участник команды тратит на командные активности. Включает в себя грумминги, Daily, подготовки и проведения планирований и т.п. Т.е. все то время, которое необходимо для организации и поддержания работоспособности команды.	Убирает из расчётов организационную составляющую команды. Позволяет определить чистую продуктовую ёмкость.
Focus Factor (FF)	Мера доли работы команды по отношению к рабочему времени.	Является отношением единицы выполненной командной работы (SP) к дню работы эквивалентного сотрудника (FTE). По сути, это сколько команда выполнила задач в своих оценках по отношению к одному дню работы её участника.	Убирает зависимость от единиц измерения (SP, ч/час, ч/день и т.п.) и статистические флуктуации. Дополнительно нивелирует командные особенности по оценке и организации работ.
Приведенный FTE (FTE’)	Мера включенности сотрудника в работу над бизнес-задачами.	Соответствует FTE за вычетом командных активностей. Позволяет получить чистую продуктовую ёмкость.	Исключает влияние командных активностей из процесса работы над задачей.

Немного про FF

FF напрямую зависит от размера единицы измерения и его можно считать как по FTE, так и по приведенному Complex Enterprise разработки.

Процесс определения Определение Capacity

Определение Capacity

А у нас не SP!

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

Вычисляем

А если нет статистики (новая команда или новый проект)?

Если команда новая и ещё ни разу не работала над задачей, то для первого прогноза можно взять FF = 0.75+/- 0.25. По результатам отработанного инкремента – пересчитать.

Более подробно см. Agile Estimating and Planning by Mike Cohn.

Определяем время присутствия членов команды на проекте (FTE). Для этого необходимо взять график фактических отпусков (с отгулами, переносами, больничными и т.д.) и наложить его на производственный календарь.

Полученное значение умножаем на коэффициент совмещения, так как некоторые участники команды могут присутствовать не full time. Важно понимать, что FTE, это не оценка трудоёмкости в ч/час, а присутствие в команде.

Поскольку не все 40 часов в неделю участник команды посвящает разработке, FTE необходимо скорректировать под командные активности (Daily, грумминги, ретроспективы и обучения). Это делается с помощью коэффициента доли командных мероприятий. Эмпирические наблюдения рекомендуют брать его значение в размере 20%.

Общий принцип расчёта FTE приведен на графике.

Пример расчёта

Команда состоит из 5 человек: 3 разработчика, 1 аналитик и 1 тестировщик

Рассчитываем capacity на инкремент (2.5 месяца) с 21.11.2022 по 29.01.2023.

Sprint	Date Beg	Date End	Duration
1	21.11.2022	04.12.2022	10
2	05.12.2022	18.12.2022	10
3	19.12.2022	01.01.2023	9
4	02.01.2023	15.01.2023	5
5 (dev)	16.01.2023	22.01.2023	5
5 (planning)	23.01.2023	29.01.2023	5

Присутствие в рабочие дни:

Dev 2 обладает экспертными знаниями и 20% времени тратит на внекомандные активности

Team/FTE’	% FullTime	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5
[dev] 1	100	4	7	7	4	4
[dev] 2	80	6	0	3	3	3
[dev] 3	100	8	8	7	4	4
[analyst] 1	100	8	8	7	4	0
[q/a] 1	100	8	8	0	4	4

Данные из примера:

Team/FTE’	% FullTime	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5
[dev] 1	100	4	7	7	4	4
[dev] 2	80	6	0	3	3	3
[dev] 3	100	8	8	7	4	4
[analyst] 1	100	8	8	7	4	0
[q/a] 1	100	8	8	0	4	4

В первом приближении расчёт FTE’ по участнику команды можно представить в виде формулы:

Описание коэффициентов

Коэффициент	Описание
n	Количество рабочих дней спринта
m	Количество рабочих дней отсутствия участника команды
k	Процент совмещения
l	Доля командных активностей

Для 5 спринта FTE рассчитывается только для тех недель, где нет SAFe-планирования, то есть в общем случае, для 1 недели.

Статистика выполненных командой задач в прошлых инкрементах

Для расчёта необходимо взять статистику выполненных командой задач. При этом важно, чтобы размерность используемых данных совпадала с размерностью прогнозируемой ёмкости. Ещё в расчёт стоит брать только продуктовые спринты. В случае SAFe-планирования, когда одна итерация предназначена для багфикса и подготовки к следующему инкременту (проведение планирования), этот 5 спринт в расчётах не стоит учитывать.

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

Холивар о переносе задач

Ещё одним подводным камнем статистики является процесс переноса задач из спринта в спринт. В этом случае рекомендую простое правило от Майка Кона «всё или ничего» (см. книгу Agile Estimating and Planning by Mike Cohn, глава Re-Estimating Partially Completed Stories) – если цель задачи не достигнута (не проведен показ и/или доработка не принята бизнесом), она (задача) полностью переносится в следующий спринт (с полной оценкой). Для любознательных – хорошая дискуссия на тему.

И последний нюанс: в практике возникают ситуации, когда данные по трекингу задач отличаются от реальной работы команды. Например, команда массово закрывает в системе все задачи под конец спринта/инкремента, а не в реальный момент выполнения. Либо система не фиксирует (сложно выгрузить) дату начала работы над задачей.

Пример статистики

SP	Sprint 1.1	Sprint 1.2	Sprint 1.3	Sprint 1.4	Sprint 2.1	Sprint 2.2	Sprint 2.3	Sprint 2.4	Sprint 3.1	Sprint 3.2	Sprint 3.3	Sprint 3.4	Sprint 4.1	Sprint 4.2	Sprint 4.3	Sprint 4.4
Planed	14	24	12	15	15	8	18	14	13	12	23	15	18	17	22	23
Fact	17	24	12	11	18	8	13	14	15	12	24	12	18	15	22	20

Здесь нас интересует строка Fact

Берем среднее значение по инкрементам и получаем Avg_SP:

	Sprint 1.*	Sprint 2.*	Sprint 3.*	Sprint 4.*
Avg SP_sprint	16	13.25	15.75	18.75
Avg_SP				15.94

Зачем 2 группировки?

Первое усреднение, в границах инкремента, убирает неравномерность в спринтах – когда задачи переносятся из спринта в спринт, но к концу инкремента выпускаются

Второе усреднение, в границах расчета, убирает флуктуации от разнотипных фич и сезонов отпусков.

Берем значение из примера: Avg_SP = 15.94

Статистика FTE’ в прошлых инкрементах

Пример статистики FTE’

	Sprint 1.1	Sprint 1.2	Sprint 1.3	Sprint 1.4	Sprint 2.1	Sprint 2.2	Sprint 2.3	Sprint 2.4	Sprint 3.1	Sprint 3.2	Sprint 3.3	Sprint 3.4	Sprint 4.1	Sprint 4.2	Sprint 4.3	Sprint 4.4
FTE	56	56	36	49	44	21	48	46	37	23	50	43	49	49	50	57

И среднее значение:

	Sprint 1.*	Sprint 2.*	Sprint 3.*	Sprint 4.*
Avg FTE’_sprint	49.25	39.75	38.25	51.25
Avg_FTE’				44.625

Берем значение из примера: Avg_FTE’ = 44.625

Вычисление FF прошлых инкрементов

Используем простую математическую формулу:

Алгоритм подробно описан в Шаге 0

Пример расчёта

Команда состоит из 5 человек: 3 разработчика, 1 аналитик и 1 тестировщик

Sprint	Date Beg	Date End	Duration
1	31.01.2023	12.02.2023	10
2	13.02.2023	26.02.2023	8
3	27.02.2023	12.03.2023	9
4	13.03.2023	26.03.2023	10
5 (dev)	27.03.2023	02.04.2023	5
5 (planning)	03.04.2023	09.04.2023	5

Присутствие в рабочие дни:

Team/FTE’	% FullTime	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5
[dev] 1	100	8	6	7	8	0
[dev] 2	80	6	5	5	6	3
[dev] 3	100	8	3	5	8	4
[analyst] 1	100	8	6	7	8	4
[q/a] 1	100	8	6	7	8	4

Данные из примера:

Team/FTE’	% FullTime	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5
[dev] 1	100	8	6	7	8	0
[dev] 2	80	6	5	5	6	3
[dev] 3	100	8	3	5	8	4
[analyst] 1	100	8	6	7	8	4
[q/a] 1	100	8	6	7	8	4

Вычисляем по каждому спринту применяя правило математического округления:

FF_prev = 35.72%	Sprint 1	Sprint 2	Sprint 3	Sprint 4	Sprint 5
FTE’_new	38	26	31	38	15
SP_sprint	14	9	11	14	5

В результате, на следующий инкремент у команды есть 48 SP в 1-4 спринтах и 5 SP запаса в 5 на багфикс и переехавшие задачи.

Как и любое лекарство, метод имеет свои побочные эффекты:

Возможность проверки сходимости оценок – можно сравнить плановые и фактические часы работы над задачей;
Исключение человеческого фактора координатора/тимлида в плане расчета ёмкости – после проведения обучения, любой заинтересованный может прогнозировать ёмкость следующих инкрементов. При этом понимание специфики работы команды, стека технологий и процессов требуется только при оценке задач, но не при планировании ёмкости;
Учёт внутрикомандных процессов – для подхода не важно, как задачи движутся внутри команды, какие есть договоренности и ограничения. Мы оперируем чистыми планом и фактом. Даже если в команде есть системные процессные проблемы, на возможность предсказания ёмкости они не оказывают сильного воздействия;

Как видим, определение capacity нового инкремента подлежит алгоритмизации. При желании, его можно встроить в свою трекинговую систему.

По опыту команды, с момента перехода на метод, большая часть проблем с планированием ёмкости нового инкремента ушла. За 2 года работы с использованием метода спринт закрывали не на 100% только по двум причинам: взяли сильно больше расчётной ёмкости и форс-мажоры (переприоритезация, внепланы, задачи с огромным количеством неизвестных, резкое изменение состава команды).

Последствия от применения метода на данных одной команды

До метода:

SP	Sprint 5.1	Sprint 5.2	Sprint 5.3	Sprint 5.4	Sprint 6.1	Sprint 6.2	Sprint 6.3	Sprint 6.4
Planed	45	37	41	29	34	34	27	35
Fact	30	23	15	22	26	27	22	34
%	66.67	62.16	36.59	75.86	76.47	79.41	81.48	97.14

Среднее значение выполнения задач – 72%

После 2х лет применения:

SP	Sprint 18.1	Sprint 18.2	Sprint 18.3	Sprint 18.4	Sprint 19.1	Sprint 19.2	Sprint 19.3	Sprint 19.4	Sprint 20.1	Sprint 20.2	Sprint 20.3	Sprint 20.4
Planed	13	12	23	15	18	17	22	23	19	18	16	13
Fact	15	12	24	12	18	15	22	20	22	18	25	14
	115.54	100	104.35	80	100	88.24	100	86.96	115.79	100	156.25	107.69

Среднее значение выполнения задач — 105%.

Логика и мнения коллег других направлений, подсказывает, что метод можно использовать не только в SAFe, но и в каскадных фреймворках. Буду признателен получить в комментариях примеры других практик по прогнозированию capacity. 🙂

Team/Days

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5 (dev)

Sprint 5 (planning)

[analyst] 1

Хочу выразить благодарность людям, без которых данная статья не появилась бы на свет: Денису Ветрову, привившему описываемый подход, Дарии Бутенко и Диме Тараскину, активно помогавшим в подготовке материалов для публикации и всем командам, которые на своём опыте дотачивали методику.

ссылка на оригинал статьи https://habr.com/ru/articles/731670/