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

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

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

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

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

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

  1. Команда заинтересованных сотрудников;

  2. Итеративный процесс разработки по любому из фреймфорков (SAFe, Scrum, каскадная модель и т.п.);

  3. Некий принятый командой метод оценки (в нашем случае, Story Points);

  4. Договорённости о правилах закрытия и переноса задач из спринта в спринт;

  5. Графики отпусков/совмещений;

  6. Статистика выполненных задач в прошлых итерациях (скорость команды).

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

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

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

Теория
Теория

Теория

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

Термин

Описание

Цель использования

Уменьшает влияние

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, так и по приведенному FTE'.

Что интересно, поскольку FF – интегральный показатель, он меняется с течением времени. Он зависит от множества факторов, которые учитываются в SP и FTE, как во внутреннем пространстве команды, так и во внешнем.

При этом алгоритм вычисления FF не изменяется – автоматически учитывается (за счёт историчных данных) и смена состава, и изменение направления решаемых задач, и частичная занятость в проекте. То есть все те форс-мажоры, что случаются с командой в домене Complex Enterprise разработки.

Метод

Процесс определения Capacity и FTE визуально можно представить в виде 2х последовательностей действий:

Определение Capacity
Определение Capacity
Определение FTE
Определение FTE
Практика
Практика

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

А у нас не SP!

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

Тезисно

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

    • Берем среднее значение SP прошедших трёх инкрементов за 1-4 спринты - AvgSP;

    • Берем среднее значение FTE' прошедших трёх инкрементов за 1-4 спринты - AvgFTE';

    • Получаем отношение FFprev = AvgSP/AvgFTE'.

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

    • Берём производственный календарь;

    • Учитываем график отпусков сотрудников;

    • Применяем коэффициенты совмещения и командных активностей.

  3. Вычисляем Capacity на новый инкремент:

    • Вычисляем по каждому спринту SPsprint = FFprev * FTE'new.

Детально

Бывают ситуации, когда сразу посчитать FF прошлых инкрементов не получается в виду отсутствия информации о FTE. Поэтому приходится расчет FTE повторять 2 раза: на 0 и 2 шаге.

Если у вас с данными все хорошо и FTE' прошлых инкрементов имеется, можно сразу приступать к Шагу 1.

А если только начинаете использовать метод, то вполне достаточно ограничиться статистическими данными последнего инкремента.

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

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

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

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

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

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

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

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

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

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

Рассчитываем capacity на инкремент (2.5 месяца) с 21.11.2022 по 29.01.2023.
Рассчитываем 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

Отпуска
Отпуска
График отпусков в виде Диаграммы Ганта
График отпусков в виде Диаграммы Ганта

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

Team/Days

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5 (dev)

Sprint 5 (planning)

[dev] 1

5

9

9

5

5

5

[dev] 2

10

0

5

5

5

5

[dev] 3

10

10

9

5

5

5

[analyst] 1

10

10

9

5

0

0

[q/a] 1

10

10

0

5

5

5

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

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' по участнику команды можно представить в виде формулы:

FTE' = (1-k)*(n-m)*(1-l)
Описание коэффициентов

Коэффициент

Описание

n

Количество рабочих дней спринта

m

Количество рабочих дней отсутствия участника команды

k

Процент совмещения

l

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

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


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

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

Для расчёта необходимо взять статистику выполненных командой задач. При этом важно, чтобы размерность используемых данных совпадала с размерностью прогнозируемой ёмкости. Ещё в расчёт стоит брать только продуктовые спринты. В случае 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

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

Sprint 1.*

Sprint 2.*

Sprint 3.*

Sprint 4.*

Avg SPsprint

16

13.25

15.75

18.75

AvgSP

15.94

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

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

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

Берем значение из примера: AvgSP = 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

AvgFTE'

44.625

Берем значение из примера: AvgFTE' = 44.625

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

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

FFprev = AVGsp/AVGfte' = 15.94/44.625 = 35.72 %

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

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

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

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

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

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/Days

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5 (dev)

Sprint 5 (planning)

[dev] 1

10

8

9

10

0

5

[dev] 2

10

8

9

10

5

5

[dev] 3

10

4

7

10

5

5

[analyst] 1

10

8

9

10

5

5

[q/a] 1

10

8

9

10

5

5

Dev 2 обладает экспертными знаниями и 20% времени тратит на внекомандные активности.
Dev 2 обладает экспертными знаниями и 20% времени тратит на внекомандные активности
Итоговый FTE'
Итоговый FTE'

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

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

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

SPsprint = FFprev * FTE'new

FFprev = 35.72%

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

FTE'new

38

26

31

38

15

SPsprint

14

9

11

14

5

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


Побочка

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

  1. Возможность проверки сходимости оценок – можно сравнить плановые и фактические часы работы над задачей;

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

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

Побочка
Побочка

Итог

Как видим, определение 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. :)

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

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

Комментарии (0)