Kanban для непрерывного потока

Updated Jul 2026

Когда Scrum не подходит

Не каждая команда использует Scrum. Kanban -- это альтернатива, которая хорошо работает для команд с непрерывным потоком работы, а не ограниченными по времени спринтами. Команды поддержки, DevOps-команды и QA-команды с фокусом на сопровождение часто находят Kanban более естественным, чем Scrum.

Ключевые концепции Kanban

Визуальная доска

Рабочие элементы перемещаются по колонкам, представляющим этапы рабочего процесса. Каждый может видеть состояние всей работы одним взглядом.

| To Do    | In Progress | In Review | Testing   | Done      |
|----------|-------------|-----------|-----------|-----------|
| SHOP-901 | SHOP-789    | SHOP-654  | SHOP-456  | SHOP-321  |
| SHOP-902 |             |           | SHOP-457  | SHOP-322  |
| SHOP-903 |             |           |           | SHOP-323  |
|          |             |           |           | SHOP-324  |

WIP-лимиты

WIP (Work in Progress) лимиты ограничивают количество элементов в каждой колонке. Это самый важный и самый контринтуитивный принцип Kanban.

| To Do    | In Progress (3) | In Review (2) | Testing (3)  | Done     |
|          | WIP-лимит: 3    | WIP-лимит: 2  | WIP-лимит: 3 |          |

Если в колонке Testing WIP-лимит 3 и там уже 3 элемента, новые элементы не могут переместиться туда, пока один не выйдет. Это предотвращает перегрузку QA и заставляет команду помочь разблокировать тестирование, прежде чем начинать новую работу.

Почему WIP-лимиты работают

Без WIP-лимитов:

• Разработчики начинают 10 фич одновременно
• 10 полузавершённых фич накапливаются в «Testing»
• QA не успевает
• Всё «в процессе», ничего не «сделано»
• Переключение контекста убивает производительность для всех

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

• Разработчики завершают фичи, прежде чем начинать новые
• Элементы равномерно проходят через доску
• Если тестирование отстаёт, разработчики помогают с автоматизацией тестов или расследованием багов
• Команда завершает работу, а не начинает

Система вытягивания

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

Lead Time и Cycle Time

QA в Kanban

Тестирование как колонка, а не фаза

В Kanban тестирование -- это колонка на доске. Если элементы накапливаются в колонке Testing, у команды узкое место. Решение не «нанять больше QA» -- а сплотиться и помочь.

Как выглядит «сплочение»:

• Разработчики пишут автоматизированные тесты для своих фич
• Разработчики расследуют упавшие тесты и исправляют корневые причины
• PO помогает верифицировать бизнес-логику при исследовательском тестировании
• Команда фокусируется на завершении существующей работы, а не начале новой

Непрерывное тестирование

Без границ спринтов тестирование должно быть непрерывным. Нет «регрессии конца спринта» -- тесты запускаются на каждое изменение, и качество валидируется непрерывно.

Последствия для QA:

• CI-пайплайн должен быть быстрым и надёжным (без периода стабилизации)
• Автоматизированная регрессия должна быть комплексной (без ручного регрессионного спринта)
• Тестовые окружения должны быть всегда готовы
• Мониторинг заменяет периодическое тестирование (качество продакшена измеряется непрерывно)

Kanban vs Scrum: сравнение с точки зрения QA

Внедрение Kanban для QA

Шаг 1: Спроектируйте доску

Начните с простой доски и добавляйте колонки по необходимости:

Базовая:     To Do → In Progress → Done
Лучше:       To Do → In Progress → In Review → Testing → Done
Оптимально:  Backlog → Ready → In Dev → Code Review → QA Testing → Staging → Done

Шаг 2: Установите WIP-лимиты

Начните с щедрых лимитов и ужесточайте со временем:

Шаг 3: Измеряйте Lead Time

Отслеживайте, сколько времени элементы проходят от начала до завершения. Обращайте внимание на:

• Элементы, застревающие в «Testing» (узкое место)
• Элементы, мигрирующие между «In Progress» и «Testing» (проблемы качества)
• Элементы с очень длинным lead time (сложность или блокеры)

Шаг 4: Оптимизируйте поток

• Если Testing -- узкое место, добавьте больше автоматизации или попросите разработчиков помочь с тестированием
• Если Code Review -- узкое место, практикуйте парное программирование вместо асинхронного ревью
• Если элементы возвращаются из Testing, инвестируйте в лучшие требования (three amigos)

Дашборд метрик Kanban

Team Kanban Metrics (Last 30 Days)
──────────────────────────────────
Average Lead Time:    4.2 days (target: < 5 days)
Average Cycle Time:   2.8 days
Throughput:           12 items/week
Testing Bottleneck:   3 items waiting > 2 days this month
WIP Violations:       2 this month (both in Testing column)

Top Bottleneck:       Testing (average wait: 1.4 days)
Action:               Developer-written automation for standard flows

Практическое упражнение

1. Настройте Kanban-доску для QA-работы вашей команды (физическую или цифровую)
2. Добавьте WIP-лимиты к каждой колонке. Начните щедро и ужесточайте в течение 2 недель.
3. Отследите lead time для 10 элементов. Где элементы проводят больше всего времени?
4. Определите ваше главное узкое место и предложите решение (автоматизация, сплочение, изменение процесса)
5. Сравните ритм вашей команды: что подойдёт лучше -- Kanban или Scrum? Почему?