Как посчитать Capacity команды тестирования

Как рассчитать Capacity команды тестирования

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

Основные компоненты Capacity

Capacity рассчитывается не просто как количество инженеров × рабочие часы. Необходимо учитывать несколько критических факторов:

1. Доступные человеко-часы: Базовая метрика.
2. Нетехническая работа (Overhead): Время, не связанное напрямую с тестированием.
3. Коэффициент доступности (Availability Factor): Учёт отпусков, больничных, обучений.
4. Технический долг и рутинные задачи: Поддержка существующих процессов.

Пошаговый алгоритм расчёта

Шаг 1: Определение базовой ёмкости

Рассчитываем общее количество рабочих часов за период (спринт, итерацию).

Общее количество часов = (Количество тестировщиков) × (Рабочих часов в день) × (Рабочих дней в периоде)

Пример: Команда из 3 QA. Спринт = 10 рабочих дней. Рабочий день = 8 часов. Базовая ёмкость = 3 × 8 × 10 = 240 человеко-часов.

Шаг 2: Учёт накладных расходов (Overhead)

Вычитаем время, которое тратится на регулярные, но не прямые задачи. Обычно это фиксированный процент (15-25%). Важно: этот процент калибруется на основе исторических данных.

• Ежедневные митинги (stand-up)
• Планирование спринта (sprint planning) и ретроспективы (retrospective)
• Обзоры требований (requirement reviews)
• Обучение и саморазвитие
• Внутрикомандное общение (Slack, почта)

Чистая ёмкость = Базовая ёмкость × (1 - Коэффициент накладных расходов)

Пример: При коэффициенте overhead 20%: 240 часов × 0.8 = 192 часа.

Шаг 3: Корректировка на доступность (Availability Factor)

Учитываем запланированные отсутствия: отпуска, больничные, корпоративные мероприятия, обучение.

Фактическая Capacity = Чистая ёмкость - Сумма часов запланированных отсутствий

Пример: Один инженер берет 1 день отпуска (8 часов). 192 - 8 = 184 часа.

Учёт особенностей и практические советы

Расчёт в часах — это основа, но для лучшего планирования я всегда дополняю его:

• Story Points или тест-кейсы: Переводите часы в более удобные для команды единицы. Если команда оценивает задачи в Story Points, рассчитайте Velocity (среднее количество поинтов за спринт) — это и будет вашим Capacity в поинтах. Например, если среднее Velocity = 30 SP, то именно на такой объём задач и стоит планировать следующий спринт.
• Контекстные факторы:

    *   **Сложность задач:** Один спринт может состоять из множества мелких багов, другой — из одной сложной E2E-проверки новой функциональности. Capacity в часах будет одинаковым, но фактическая производительность может отличаться.
    *   **Onboarding нового сотрудника:** Его Capacity в первые недели может быть 50% или меньше от полной.
    *   **Работа с техническим долгом:** Выделяйте фиксированный процент Capacity (например, 10-15%) на автоматизацию, поддержку тестовых стендов, улучшение процессов.

• Динамический пересчёт: Capacity — не константа. Её нужно пересматривать в начале каждого планировочного цикла, учитывая текущую ситуацию в команде.
• Инструменты: Используйте возможности Jira, Confluence или таблиц для автоматизации подсчётов. В Jira можно настроить дашборды, показывающие доступность команды на основе календарей.

Пример комплексного подхода

Предположим, команда из 4 QA-инженеров оценивает свою Capacity на 2-недельный спринт:

1. База: 4 чел. × 8 часов × 10 дней = 320 часов.
2. Overhead (20%): 320 × 0.8 = 256 часов.
3. Отсутствия: Два инженера на полдня на обучение (2 × 4ч = 8ч). 256 - 8 = 248 часов.
4. Работа с техдолгом (15%): Выделяем 248 × 0.15 ≈ 37 часов на задачи по автоматизации. Остается ~211 часов на тестирование новой функциональности.
5. Перевод в Story Points: Если в прошлом спринте команда выполнила задач на 40 SP, потратив те же ~211 часов, то Capacity текущего спринта = 40 SP.

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