Какой WIP лимит выберешь для команды из пяти разработчиков?

Мой подход к выбору WIP-лимита для команды из пяти разработчиков

Выбор WIP-лимита (Work In Progress, ограничения незавершённой работы) — это не поиск магической формулы, а стратегическое решение, основанное на целях команды, зрелости процессов и характеристиках потока работ. Для команды из пяти разработчиков я бы не стал назначать жёсткое значение "сверху", а организовал бы экспериментальный подбор совместно с командой, следуя логике Kanban и теории ограничений.

Стартовые гипотезы и отправные точки

Исходя из опыта, для команды из 5 человек типичные стартовые значения лежат в диапазоне:

• Гипотеза 1 (консервативная): WIP-лимит = 5. "Один разработчик — одна задача". Это классический подход для начала внедрения Kanban. Он идеален для команд, страдающих от многозадачности и частых переключений контекста.

  Преимущества: Максимальная фокусировка, простота контроля, явная видимость простоя.
  Риски: Возможные простои из-за блокировок или если задача требует ожидания внешних ресурсов.
  

• Гипотеза 2 (прагматичная): WIP-лимит = 7-8. Это позволяет иметь небольшой буфер.

  Логика: 5 активных задач + 1-2 задачи в состояниях "ожидание ревью/тестов/развёртывания". Это покрывает естественные паузы в потоке.
  

• Гипотеза 3 (поэтапная): Дифференцированные лимиты по колонкам. Это более зрелый подход. Например, на доске с колонками "В работе", "Ревью", "Тестирование" лимиты могут быть:

  [Backlog] -> [В РАБОТЕ (WIP=5)] -> [РЕВЬЮ (WIP=3)] -> [ТЕСТИРОВАНИЕ (WIP=2)] -> [Готово]
  

    Здесь общий незавершённый объём может быть до 10 задач, но критический лимит на этапе активной разработки — 5, что предотвращает перегрузку программистов.

Процесс выбора и настройки лимита

Мой план действий с командой состоял бы из следующих шагов:

1. Анализ текущего потока (Data First). Перед любым решением мы 2-3 недели собираем данные на визуальной доске (Kanban или Scrum-борд) без каких-либо лимитов. Смотрим на:

    *   Среднее количество задач одновременно "в работе".
    *   **Среднее время выполнения (Lead Time)** и его вариативность.
    *   Точки накопления задач ("узкие места"), чаще всего это "Ревью" или "Тестирование".

1. Совместный workshop с командой. Обсуждаем цели:

    *   **Цель: Увеличить скорость?** → Возможно, начать с лимита 5-6, чтобы снизить переключения и ускорить завершение задач.
    *   **Цель: Повысить предсказуемость и качество?** → Выбираем консервативный лимит (5), чтобы уделять больше времени код-ревью и рефакторингу.
    *   **Цель: Снизить стресс от многозадачности?** → Лимит 5 — однозначный выбор.

1. Установка стартового лимита и запуск эксперимента. Допустим, после дискуссии мы стартуем с WIP = 5. Это правило жёстко визуализируем на доске.

2. Мониторинг и адаптация (самая важная часть). Мы регулярно (на ежедневных стендапах и ретроспективах) анализируем:

    *   **Часто ли столбцы "замораживаются" из-за достижения лимита?** Если да — это не проблема, а возможность. Команда фокусируется на "разблокировании" потока (например, все помогают проводить ревью), что системно улучшает процесс.
    *   **Появились ли регулярные простои у разработчиков?** Если задача заблокирована, а взять новую нельзя из-за лимита, возможно, стоит увеличить лимит на 1 или ввести правило для **блокированных задач** (например, они не учитываются в лимите, но маркируются красным стикером).
    *   **Как изменилось Lead Time и пропускная способность?** Это ключевые метрики. Мы смотрим на них через кумулятивную диаграмму потока (Cumulative Flow Diagram).

1. Итеративная корректировка. Раз в 1-2 спринта/цикла мы решаем: поднять, опустить или перераспределить лимиты. Например, если выясняется, что "горлышком" является этап тестирования, мы можем снизить лимит для "Разработки", чтобы меньше задач "выливалось" на тестировщиков, и ввести отдельный лимит для колонки "Тестирование".

Резюме и рекомендация

Для новой или страдающей от хаотичной многозадачности команды из 5 разработчиков я бы рекомендовал стартовать с WIP-лимита = 5. Это простое, наглядное и мощное правило, которое немедленно начинает выявлять проблемы в процессе. Для более зрелой команды, где поток отлажен, но есть цель оптимизировать загрузку, я бы предложил начать с дифференцированных лимитов, например, Dev: 5, Review: 3, Test: 2.

Главный принцип: WIP-лимит — это не константа, а инструмент для обучения и улучшений. Его ценность не в самом числе, а в тех системных дискуссиях о качестве, блокировках и потоке создания ценности, которые он провоцирует при каждом его достижении. Правильно подобранный лимит заставляет команду работать не быстрее, а умнее, фокусируясь на завершении начатого, а не на старте нового.