Как посчитать Velocity если член команды уходит в отпуск?

Учёт отпусков при расчёте Velocity в Agile

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

Основные принципы корректировки Velocity

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

Правильный подход — планировать меньший объём работы (меньший Sprint Commitment) на спринт с отпусками.

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

1. Метод "Идеально-доступных человеко-дней"

Самый распространённый и надёжный метод.

1. Рассчитайте общее количество идеальных человеко-дней в спринте.

    *   Длина спринта: 10 рабочих дней.
    *   Размер команды: 5 человек.
    *   Идеальный фонд: `10 дней * 5 чел. = 50 человеко-дней`.

1. Вычтите дни отсутствия.

    *   Один разработчик в отпуске 5 рабочих дней.
    *   Доступный фонд: `50 - 5 = 45 человеко-дней`.

1. Определите коэффициент доступности команды.

   # Пример расчёта на Python
   total_ideal_days = 10 * 5  # 50
   absence_days = 5
   available_days = total_ideal_days - absence_days  # 45
   availability_factor = available_days / total_ideal_days  # 0.9
   print(f"Коэффициент доступности команды: {availability_factor:.2f}")  # 0.90
   

2. Примените коэффициент к среднему Velocity команды (рассчитанному за последние 3-6 спринтов) для прогноза.

    *   Средний Velocity = 40 story points.
    *   Прогноз на спринт с отпуском: `40 * 0.9 = 36 story points`.

2. Метод "Прогнозирования на основе ёмкости (Capacity)"

Используется в большинстве инструментов (Jira, Azure DevOps). Вы явно задаёте уменьшенную ёмкость (Capacity) для каждого члена команды на период спринта.

• В планировании спринта вы указываете, что у разработчика А ёмкость = 0 часов/дней на 5 дней из 10.
• Инструмент автоматически пересчитает общую доступную ёмкость команды.
• Затем вы назначаете задачи, не превышая эту скорректированную ёмкость.

3. Метод "Скользящего среднего с учётом тренда"

Более продвинутый подход для зрелых команд.

• Рассчитывайте Velocity не просто как среднее арифметическое, а анализируйте тренд.
• Если в прошлых спринтах с аналогичной нагрузкой (отпусками) Velocity стабильно составлял ~85% от среднего, используйте этот эмпирический коэффициент.
• Формула может выглядеть так:

  Прогнозный Velocity = (Средний Velocity * Коэффициент_отпуска) * Коэффициент_тренда
  

Чего делать НЕЛЬЗЯ

• Не "забывайте" про отпуск и не планируйте полный объём. Это гарантированно приведёт к срыву спринта, выгоранию и техническому долгу.
• Не просите команду "работать за двоих". Это нарушает устойчивый темп (Sustainable Pace) — ключевой принцип Agile.
• Не корректируйте оценку задач (story points) в бэклоге. Story points оценивают относительную сложность, а не время выполнения. Они не должны меняться из-за календаря.
• Не используйте "пустые" story points для компенсации. Не добавляйте в спринт "скрытые" задачи или неучтённые часы.

Рекомендации для Project Manager / Scrum Master

1. Прозрачность и коммуникация: Открыто обсуждайте влияние отпусков на планирование с Product Owner и командой на Sprint Planning.
2. Работа с бэклогом: Вместо того чтобы брать меньше фич, можно договориться с Product Owner о том, чтобы взять в спринт одну большую задачу и несколько мелких/технических, которые можно безопасно перенести, если что-то пойдёт не так.
3. Долгосрочное планирование (Roadmap): Учитывайте запланированные длительные отпуски при долгосрочном прогнозировании (Release Planning). Это поможет управлять ожиданиями стейкхолдеров.
4. Анализ после спринта: На Sprint Retrospective обсудите, насколько точным был прогноз с учётом отпуска, и скорректируйте подход к планированию, если это необходимо.

Итог: Отпуск — это плановое событие. Корректный учёт его влияния через уменьшение прогнозного Velocity или ёмкости спринта — признак зрелого Agile-процесса, который учитывает человеческий фактор и стремится к реалистичным обязательствам. Это сохраняет здоровье команды и доверие заказчика.