Планировать объем на основе данных
Емкость релиза в этой методологии оценивается через трудозатраты на аналитику, разработку и тестирование. История выпущенных релизов помогает сопоставить плановый объем работы с фактическими возможностями команды.
Цель подхода: предсказуемая поставка качественного программного обеспечения, отвечающего потребностям бизнеса и сопровождения. Методология опирается на Agile и итеративную разработку.
- Планирование и прогнозирование. Оценивать объем, сроки и ресурсы до начала работ.
- Оценка загрузки команды. Замечать перегрузку и нехватку ресурсов.
- Снижение риска сдвига контрольных точек. Раньше выявлять отклонения и обсуждать решения.
- Улучшение процесса. Корректировать планы и распределение ресурсов по результатам релизов.
- Управление ожиданиями. Делать состав релиза прозрачным для команды, релиз-менеджера и заказчика.
Где применять методологию
Частые релизы
Еженедельные или более частые выпуски, требующие координации и управления загрузкой.
Большой объем изменений
Релизы с множеством новых функций, улучшений и исправлений ошибок.
Несколько команд
Сложные системы, для которых важны межкомандная координация и общее планирование.
Критичные бизнес-системы
Изменения, влияющие на ключевые процессы организации и связанные с существенными рисками.
Производственный и релизный процессы
Производственный процесс организует выполнение работ в спринтах. Релизный процесс связывает планирование состава, его формирование, приемку и внедрение с последующей оценкой результата.
Планирование состава релиза
От вехи начала релизного цикла: оценка емкости и количества доработок по истории, выбор планового состава.
Параллельные процессы
Повторяющийся цикл спринтов
- ПланированиеПостановка задач и приоритеты
- АналитикаПроработка требований
- РазработкаРеализация задач
- Функциональное тестированиеПроверка соответствия требованиям
Формирование состава релиза
Накопление и уточнение задач, мониторинг выполнения и корректировка состава.
Контроль соответствия текущей емкости запланированным показателям на протяжении спринтов.
Приемка релиза
Проверка выполнения задач, качества и готовности к внедрению.
Организация внедрения
Подготовка, развертывание в продуктивной среде и сопровождение.
Пострелизные работы
Сравнение плана и факта, анализ отклонений и улучшение следующего планирования.
Планирование состава начинается до цикла спринтов. Во время спринтов состав уточняется параллельно работам, а не отдельным этапом после завершения всей разработки.
Типы задач, статусы и переходы описаны в WorkFlow для релизных проектов. Роли и организационные параметры процесса можно зафиксировать в релизной стратегии.
Собрать историю релизов
Используйте не менее 10 последних релизов при наличии данных. Для каждого выпущенного релиза заполните одинаковый набор показателей.
- Наименование релиза
- Версия или название выпущенного релиза.
- Формирование состава, дни
- Длительность этапа «Формирование состава релиза».
- Доработки, шт.
- Количество включенных контейнеров поставки: задач, User Story, Technical Task, ошибок. Подзадачи с видами работ не считаются дополнительными доработками.
- Аналитика, ч
- Сумма фактически списанного времени на подзадачи типа «Аналитика».
- Разработка, ч
- Сумма фактически списанного времени на подзадачи типа «Разработка».
- Тестирование, ч
- Сумма фактически списанного времени на подзадачи типа «Тестирование».
- Общие трудозатраты, ч
- Аналитика + разработка + тестирование. Не прибавляйте к этой сумме еще раз итог родительской задачи или релиза.
Часы показывают суммарные трудозатраты, дни показывают длительность этапа. Емкость в часах не является длительностью релиза; часы и дни нельзя складывать или подменять друг другом.
Показатели и формулы
Для выборки из N релизов обозначим: Dᵢ — дни формирования состава, Cᵢ — число доработок, Aᵢ, Rᵢ и Tᵢ — часы аналитики, разработки и тестирования. Общие трудозатраты Hᵢ = Aᵢ + Rᵢ + Tᵢ.
Средние показатели релиза
Среднее(X) = (X₁ + … + Xₙ) / N
Арифметическое среднее каждого столбца: длительности D, количества доработок C, аналитики A, разработки R, тестирования T и общих трудозатрат H. Среднее(H) — средняя емкость релиза в часах.
Доработки в день для одного релиза
Cᵢ / Dᵢ
Количество доработок, деленное на длительность формирования состава этого релиза. Единица измерения: шт./день.
Усредненное число доработок в день
(C₁ / D₁ + … + Cₙ / Dₙ) / N
Сначала рассчитайте отношение для каждого релиза, затем усредните отношения. Это не Среднее(C) / Среднее(D).
Усредненная емкость в день
Среднее(H) / Среднее(D)
Средняя общая трудоемкость, деленная на среднюю длительность формирования состава. Единица измерения: ч/день. Для этого показателя методология использует именно отношение средних.
Для деления длительность должна быть больше нуля. В вычислениях сохраняйте полную точность: округляйте только отображаемые результаты.
Расчет по десяти релизам
Пример иллюстрирует формулы, а не задает норматив емкости для вашей команды. Все десять исходных строк сохранены; итоги рассчитаны из них.
| Релиз | Формирование, дни | Доработки, шт. | Аналитика, ч | Разработка, ч | Тестирование, ч | Всего, ч | Доработки в день |
|---|---|---|---|---|---|---|---|
| Релиз №1 | 5 | 15 | 5 | 12 | 8 | 25 | 3 |
| Релиз №2 | 10 | 20 | 4 | 15 | 8 | 27 | 2 |
| Релиз №3 | 7 | 17 | 8 | 11 | 5 | 24 | 2,43 |
| Релиз №4 | 5 | 12 | 3 | 15 | 7 | 25 | 2,4 |
| Релиз №5 | 9 | 18 | 6 | 14 | 8 | 28 | 2 |
| Релиз №6 | 6 | 10 | 6 | 11 | 4 | 21 | 1,67 |
| Релиз №7 | 4 | 9 | 7 | 11 | 6 | 24 | 2,25 |
| Релиз №8 | 9 | 12 | 8 | 13 | 7 | 28 | 1,33 |
| Релиз №9 | 11 | 25 | 10 | 18 | 11 | 39 | 2,27 |
| Релиз №10 | 7 | 7 | 3 | 9 | 6 | 18 | 1 |
Средние по выборке
- Длительность формирования
- 7,3 дня
- Доработки за релиз
- 14,5 шт.
- Аналитика за релиз
- 6 ч
- Разработка за релиз
- 12,9 ч
- Тестирование за релиз
- 7 ч
- Общая емкость релиза
- 25,9 ч
- Доработки в день
- 2,04 шт./день
- Емкость в день
- 3,55 ч/день
Проверить промежуточные вычисления
Суммы столбцов: 73 дня, 145 доработок, 60 ч аналитики, 129 ч разработки, 70 ч тестирования и 259 ч общих трудозатрат. Деление каждой суммы на 10 дает средние значения выше.
Общая емкость: (60 + 129 + 70) / 10 = 25,9 ч. Итог 259 ч уже включает все три вида работ и повторно в сумму не добавляется.
(15/5 + 20/10 + 17/7 + 12/5 + 18/9 + 10/6 + 9/4 + 12/9 + 25/11 + 7/7) / 10 ≈ 2,04 шт./день.
Отношение 14,5 / 7,3 ≈ 1,99 шт./день дает другой показатель и не заменяет среднее отношений 2,04 шт./день.
25,9 / 7,3 ≈ 3,55 ч/день.
Оценить бэклог нового релиза
- Приоритизируйте бэклог. Релиз-менеджер, владелец продукта и другие заинтересованные участники определяют приоритет задач.
- Назначьте плановый релиз. Для каждой задачи укажите версию предполагаемой поставки. «Планируется в версии» — пример поля учетной системы; в вашем трекере оно может называться иначе.
- Декомпозируйте задачи. Создайте подзадачи для аналитики, разработки и тестирования, чтобы видеть необходимые виды работ.
- Оцените подзадачи в часах. Учитывайте сложность, доступные ресурсы и время, а также фактические данные по аналогичным задачам.
- Рассчитайте плановые трудозатраты. Суммируйте оценки отдельно по видам работ, затем сложите аналитику, разработку и тестирование в общую емкость релиза. Каждая оценка подзадачи учитывается один раз.
- Сравните план с историей. Сопоставьте плановую общую емкость со средней емкостью выпущенных релизов.
Фактические списания прошлых релизов и плановые оценки нового релиза служат разным целям: не объединяйте их в один исторический показатель.
Что делать при превышении емкости
Если плановая емкость выше исторической средней, это сигнал обсудить риск снижения качества, задержек или переноса контрольных точек. Само превышение не является автоматическим запретом или доказательством невозможности поставки.
Релиз-менеджер инициирует обсуждение с лидами команд и представителями бизнес-заказчика. В методологии предусмотрены следующие варианты.
- Перенести задачи в следующий релиз. Снизить объем работ в текущем составе.
- Пересмотреть приоритеты и состав. Исключить из плановой версии задачи с более низким приоритетом.
- Согласовать перенос контрольных точек. Обсудить сроки с бизнес-заказчиком, если критичные задачи не укладываются в план.
- Привлечь дополнительные ресурсы. Рассмотреть усиление команд на этот релиз. Добавление людей само по себе не гарантирует ускорения.
Емкость описывает объем работы, но не заменяет проверку готовности результата. Проверки качества на этапах релиза представлены в материале Quality Gates: пороги качества релиза.