Что такое WIP-лимит в Kanban? Для чего он нужен?

WIP-лимит в Kanban: назначение и применение

Что такое WIP-лимит

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

Пример Kanban доски с WIP-лимитами:

| To Do        | In Progress  | Review       | Done    |
| (no limit)   | (limit: 3)   | (limit: 2)   | (no limit)|
|              |              |              |         |
| Task 1       | Task 10      | Task 20      | Task 30 |
| Task 2       | Task 11      | Task 21      | Task 31 |
| Task 3       | Task 12      |              | Task 32 |
|              | Task 13      |              |         |

Если в "In Progress" уже 3 задачи, новую задачу нельзя там начинать, пока одна из текущих не будет завершена.

Назначение и преимущества WIP-лимитов

1. Снижение контекстного переключения (Context Switching)

Проблема без WIP-лимитов:

• Разработчик работает над Task A
• Появляется срочная Task B → переключается
• Появляется срочная Task C → переключается
• Контекстные переключения занимают 25-30% времени
• Результат: все задачи делаются медленнее, чем если бы делать одну за другой

Решение WIP-лимитом:

• Максимум 1-2 задачи на разработчика одновременно
• Разработчик сосредоточен на задачах
• Завершает одну → берёт следующую
• Повышается качество и скорость выполнения

2. Выявление узких мест (Bottlenecks)

WIP-лимиты как индикатор проблем:

Пример:

• In Progress: 3 задачи (на лимите)
• Review: 0 задач из 2 (недоиспользовано)

Это сигнал, что разработчики быстро пишут код, но рецензирование медленное. Нужно найти узкое место в процессе review (может, не хватает ревьюеров, или они отвлечены).

3. Улучшение потока работы (Flow Efficiency)

Без контроля:

• 50+ задач в "To Do"
• 30+ задач в "In Progress"
• 20+ задач ждут review
• Полная хаос, сложно понять приоритеты

С WIP-лимитами:

• In Progress: max 5
• Review: max 3
• Ясная очередь
• Легче управлять приоритетами
• Задачи быстрее доходят до Done

4. Снижение WIP-объёма

Lead Time (время от идеи до готового продукта) снижается пропорционально объёму WIP:

Lead Time = (WIP размер) / (Throughput)

Пример:
- WIP: 20 задач, Throughput: 5 в неделю → Lead Time = 4 недели
- WIP: 5 задач, Throughput: 5 в неделю → Lead Time = 1 неделя

Меньше задач в работе = они быстрее доходят до production.

5. Повышение прозрачности и предсказуемости

• Менеджмент видит реальное состояние:
  • Сколько задач в работе
  • Где узкие места
  • Когда задача будет готова
• Возможно спланировать более точно
• Клиентам можно дать более реалистичные сроки

Как установить оптимальные WIP-лимиты

1. Анализ пропускной способности (Throughput)

Шаг 1: Собери данные за 2-4 недели

• Сколько задач закончилось (Done) в неделю
• Сколько в среднем задач одновременно в работе (WIP)

Шаг 2: Вычисли Little's Law

Cycle Time (Lead Time) = WIP / Throughput

Пример:
- Throughput: 10 задач в неделю
- WIP: 20 задач
- Cycle Time: 20 / 10 = 2 недели на задачу

Если хочешь 1 неделю → WIP = 10

2. Практические рекомендации

Для "In Progress" (активная разработка):

• WIP = (Количество разработчиков) × (1 до 1.5)
• Если 5 разработчиков → WIP = 5-7

Для "Review" (код-ревью):

• WIP = (Количество ревьюеров) × (1 до 2)
• Если 2 ревьюера → WIP = 2-4

Для "Testing" (тестирование):

• WIP = (Количество тестировщиков) × (1 до 1.5)

3. Экспериментирование

• Установи начальный WIP
• Отслеживай Cycle Time и Throughput
• Понижай WIP на 1-2 и смотри, как меняется скорость
• Найди оптимум (обычно 3-7 для средней команды)

Типичные ошибки

Ошибка 1: WIP-лимит слишком высокий

• Результат: он не работает как инструмент, становится "recommendation"
• Люди по прежнему берут слишком много

Ошибка 2: WIP-лимит слишком низкий

• Результат: люди часто ждут, пока освободится место
• Lead Time растёт, а не падает

Ошибка 3: Разные лимиты для разных людей

• Может привести к справедливости (хороший разработчик делает больше)
• Но усложняет контроль

Ошибка 4: Игнорирование узких мест

• WIP-лимит показывает проблему, но не решает её
• Нужно анализировать и улучшать процесс

Практический пример: Scrum + Kanban

В Agile окружении WIP-лимиты комбинируют со спринтами:

| Backlog    | Sprint      | In Progress | Review   | Done     |
| (no limit) | (no limit)  | (max 3)     | (max 2)  | (no limit)|
|            |             |             |          |          |
| Epic 1     | User auth   | Profile API | Tests    | Payment  |
| Epic 2     | Payments    | Forms       | Review 1 | Auth     |
| Epic 3     | Reports     | Dashboard   |          |          |

В sprint всё спланировано, но WIP-лимиты контролируют параллельную работу внутри sprint'а. Это помогает команде доделывать sprint'ы на время.