Velocity прошлого спринта не говорит, сколько команда сделает в следующем
Команда закрыла 300 story points за спринт.
Можно взять это число и запланировать на следующий примерно столько же. Формально логично.
Фактически двое разработчиков уходят в отпуск, появляется несколько срочных багов, а новый сотрудник пока тратит больше времени на погружение, чем на задачи.
И план перестаёт сходиться.
На Хабре вышел интересный кейс тимлида, который два года прогнозировал загрузку команды не по средней velocity, а по её фактической доступной ёмкости.
Он проанализировал 16 спринтов и обнаружил, что количество эффективных человеко-дней менялось от 94 до 211.
Разница больше чем в два раза.
Velocity сама по себе этих изменений не показывает. Она говорит, сколько команда сделала раньше, но не объясняет, какими ресурсами был получен результат.
Автор предложил считать производительность на эффективный человеко-день, учитывая:
— рабочие дни и отпуска; — доступность специалистов; — поддержку и операционные задачи; — исторический темп команды; — переработки.
С переработками особенно интересно.
Представим, что команда закрыла спринт только благодаря трём вечерам работы сверх графика.
Если считать такой результат новой нормой, следующий план станет ещё амбициознее. Команда снова переработает, а метрика покажет рост производительности.
Получается положительная обратная связь, только положительного в ней мало: переработки постепенно превращаются в обязательное условие выполнения плана.
Поэтому дополнительную выработку автор исключает из расчёта устойчивого темпа.
За 16 спринтов получилось:
— прогноз — 3587 SP; — фактический результат — 4130 SP; — в 13 спринтах команда сделала не меньше прогноза; — медианная абсолютная ошибка отдельного прогноза — около 18%.
Это не идеальная точность. Но такой прогноз хотя бы учитывает, какая команда действительно будет выполнять работу, а не предполагает, что следующий спринт — копия предыдущего.
У подхода есть ограничения.
Story points должны оставаться достаточно стабильными. Состав команды не должен полностью меняться каждые несколько спринтов. Незапланированную работу тоже придётся учитывать, иначе формула будет точно считать неполные данные.
И я бы не делал из этого вывод, что теперь каждой команде срочно нужна метрика производительности на человеко-день.
Для Kanban-команд лучше могут подойти исторический throughput, cycle time и вероятностное прогнозирование.
Главная идея шире конкретной формулы.
Планировать нужно исходя из способности системы выполнять работу, а не из количества задач, которое хотелось бы увидеть в конце спринта.
И хороший прогноз не должен требовать постоянного героизма.
Если план выполняется только благодаря переработкам, проблема не в недостаточной продуктивности разработчиков.
Проблема в плане.
Источник: Хабр, «Почему тимлид не может сказать, сколько команда сделает в следующем спринте, и как я это посчитал».
