Как определить сколько задач взять в спринт?

Определение объёма задач для спринта: методология и практические техники

Определение оптимального количества задач для спринта — это ключевой процесс в Agile-менеджменте, напрямую влияющий на успех проекта, моральный дух команды и качество результата. Этот процесс не является простой математической операцией, а представляет собой комплексную оценку, основанную на данных, экспертизе и согласованности команды. Вот основные методологии и практические шаги.

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

1. Использование исторических данных (Velocity Tracking):

    *   Это основа прогнозирования. **Velocity** — среднее количество единиц работы (story points, часы), которое команда завершает за спринт. Рассчитывается после нескольких спринтов.
    *   **Пример анализа в таблице или простом скрипте**:

    ```python
    # Пример расчета средней скорости (velocity) за последние 3 спринта
    completed_story_points_last_sprints = [35, 42, 38]
    average_velocity = sum(completed_story_points_last_sprints) / len(completed_story_points_last_sprints)
    print(f"Средняя скорость команды: {average_velocity} story points")
    # Эта цифра — первичный ориентир для нового спринта.
    ```

    *   Важно анализировать **тренды**, а не только среднее значение. Снижение velocity может сигнализировать о проблемах.

1. Планирование на основе ёмкости команды (Capacity Planning):

    *   Учитываются не абстрактные story points, а реальные доступные человеко-часы. Рассчитывается для каждого участника и всей команды.
    *   **Формула**: `Общая ёмкость = (Количество рабочих дней в спринте * Среднее количество рабочих часов в день) - Запланированные отвлечения (митинги, обучение, админ. работа)`.
    *   На практике это выглядит так:

    ```javascript
    // Пример расчета ёмкости для команды из 3 разработчиков на 2-недельный спринт
    const workingDays = 10;
    const dailyHours = 8;
    const plannedOverhead = 15; // часов на митинги и прочее
    const teamCapacity = (3 * (workingDays * dailyHours)) - plannedOverhead;
    console.log(`Фактическая ёмкость команды: ${teamCapacity} часов`);
    ```

    *   Затем задачи из бэклога оцениваются в часах (или переводятся из story points через исторический коэффициент) и выбираются так, чтобы их суммарная оценка не превышала ёмкость.

Практический процесс планирования спринта (Sprint Planning Meeting)

Определение объёма работы происходит во время сессии планирования спринта и включает следующие шаги:

1. Анализ бэклога продукта (Product Backlog):

    *   Владелец продукта (PO) представляет приоритетные задачи, готовые к разработке (т.е., прошедшие **backlog refinement** и имеющие четкие критерии приемки).
    *   Команда задаёт вопросы для полного понимания.

1. Обсуждение и оценка сложности:

    *   Команда обсуждает каждую задачу, выявляет технические нюансы, взаимозависимости и потенциальные риски.
    *   Если используется **story points**, может применяться техника покера планирования для быстрой относительной оценки.

1. Сравнение с прошлыми результатами и ёмкостью:

    *   **Project Manager** или **Scrum Master** демонстрирует историческую скорость и текущую рассчитанную ёмкость команды.
    *   Это создаёт **реалистичный контекст** и предотвращает чрезмерные обязательства.

1. Совместное принятие решения (Team Commitment):

    *   Ключевой момент Agile — команда сама решает, сколько работы она может взять, а не получает план сверху.
    *   На основе данных, понимания задач и чувства уверенности команда выбирает набор задач из бэклога, который:
        *   Соответствует или чуть ниже исторической скорости.
        *   Укладывается в рассчитанную ёмкость.
        *   Позволяет достичь **цели спринта** (Sprint Goal), которая является качественным ориентиром.

1. Учёт факторов риска и "буфера":

    *   Опытные команды никогда не планируют на 100% ёмкости. Я рекомендую оставлять **15-20%** на непредвиденные сложности, багфиксы, помощь коллегам или доработки.
    *   Это защищает от срыва спринта и снижает стресс.

Ключевые критерии успешного планирования объёма

• Реалистичность: План должен быть достижимым, а не "оптимистичным".
• Целостность: Выбранные задачи должны логично сочетаться и приводить к завершенному, тестируемому результату.
• Гибкость: Если в процессе спринта обнаруживается, что задача намного сложнее, план может быть адаптирован (например, задача заменена на менее сложную), но это должно обсуждаться с PO.

Заключение: Определение объёма задач — это баланс между данными (velocity, capacity), экспертизой команды и коммуникацией. Роль Project Manager здесь — фасилитировать процесс, обеспечивать наличие качественных данных и создавать атмосферу, в которой команда может сделать реалистичное и ответственное обязательство. Правильно определённый объём работы — это фундамент для устойчивого темпа разработки (sustainable pace), высокого качества и доверия внутри команды и с заказчиком.