Что такое Kanban?
Kanban — это agile-методология, основанная на визуализации работы, ограничении незавершённой работы и оптимизации потока. В отличие от Scrum, Kanban не использует time-boxed спринты. Вместо этого рабочие элементы непрерывно проходят через серию этапов от «К выполнению» до «Готово».
Слово «Kanban» пришло из японского языка и означает «визуальный сигнал» или «карточка». Методология зародилась в производственной системе Toyota в 1940-х годах и была адаптирована для разработки программного обеспечения Дэвидом Андерсоном в 2000-х.
Для QA-инженеров Kanban предлагает принципиально иной способ работы по сравнению со Scrum. Понимание обоих подходов помогает адаптироваться к любой командной среде.
Основные Принципы Kanban
1. Визуализация Рабочего Процесса
Всё, над чем работает команда, видно на Kanban-доске. Каждая карточка представляет рабочий элемент, а её позиция на доске показывает текущий статус.
2. Ограничение Незавершённой Работы (WIP)
Каждая колонка на доске имеет максимальное допустимое количество элементов. Это лимит WIP. Когда колонка заполнена, новые элементы не могут войти, пока существующие не продвинутся вперёд.
3. Управление Потоком
Цель — плавный, предсказуемый поток работы через систему. Заблокированные элементы, узкие места и длинные очереди — сигналы о том, что что-то требует внимания.
4. Явные Политики
Правила перемещения элементов между колонками записаны и видны. Например: «Элемент может перейти в “Тестирование” только когда разработчик отметит его как code-complete и unit-тесты проходят».
5. Циклы Обратной Связи
Регулярные встречи (стендапы, ревью, ретроспективы) обеспечивают обратную связь о работе процесса.
6. Совместное Улучшение
Команда непрерывно ищет способы улучшить рабочий процесс на основе данных (cycle time, lead time, throughput).
Kanban-Доска с QA
Kanban-доска для команды разработки с выделенными активностями QA выглядит так:
WIP: 3] B --> C[Разработка
WIP: 4] C --> D[Code Review
WIP: 2] D --> E[QA Testing
WIP: 3] E --> F[UAT
WIP: 2] F --> G[Готово] end style A fill:#E0E0E0 style B fill:#BBDEFB style C fill:#C8E6C9 style D fill:#FFF9C4 style E fill:#F8BBD0 style F fill:#D1C4E9 style G fill:#A5D6A7
Ключевые колонки QA:
| Колонка | Лимит WIP | Роль QA |
|---|---|---|
| Бэклог | Нет | Проверка предстоящих элементов на тестируемость |
| Анализ | 3 | Уточнение критериев приёмки, определение подхода к тестированию |
| Разработка | 4 | Подготовка тест-кейсов, настройка тестовых данных |
| Code Review | 2 | Проверка покрытия тестами при code review |
| QA Testing | 3 | Выполнение функционального, регрессионного и исследовательского тестирования |
| UAT | 2 | Поддержка приёмочного тестирования, верификация исправлений |
| Готово | Нет | Проверка выполнения всех критериев качества |
Лимиты WIP и Почему Они Важны для QA
Лимиты WIP — сердце Kanban. Без них у вас просто красивый список задач.
Как Лимиты WIP Предотвращают Узкие Места в QA
Рассмотрим сценарий без лимитов WIP:
- Разработчики завершают 8 фич за неделю
- QA может протестировать 4 фичи за неделю
- Колонка QA Testing растёт на 4 элемента каждую неделю
- Через месяц у QA бэклог из 16 непротестированных фич
Это узкое место. Работа накапливается перед QA, и общий throughput команды ограничен пропускной способностью тестирования.
С лимитами WIP:
- Колонка QA Testing имеет лимит WIP равный 3
- Когда 3 элемента в тестировании, разработчики не могут передвинуть новые элементы в Code Review
- Это вынуждает разработчиков либо помогать с тестированием, исправлять баги, либо улучшать автоматизацию
- Узкое место становится видимым сразу, а не через месяц
Ключевой момент: Лимиты WIP не замедляют команду. Они показывают, где команда уже медленная. Если колонка QA всегда заполнена, команде нужна большая пропускная способность тестирования — а не более высокий лимит WIP.
Установка Правильного Лимита WIP для QA
Хорошая отправная точка для лимита WIP колонки QA Testing:
| Размер команды | QA-инженеры | Рекомендуемый лимит WIP |
|---|---|---|
| 3-5 человек | 1 QA | 2-3 элемента |
| 5-8 человек | 2 QA | 3-4 элемента |
| 8-12 человек | 3 QA | 4-5 элементов |
Начните консервативно и корректируйте на основе данных. Если колонка QA редко заполнена, снизьте лимит. Если элементы часто ждут перед QA, лимит может быть правильным, но вам нужна большая пропускная способность.
Тестирование на Основе Потока
В Kanban тестирование — не фаза, а часть потока. Это означает:
Тестируйте Когда Готово, а Не по Расписанию
В Scrum тестирование происходит внутри спринта. В Kanban вы тестируете элемент, как только он попадает в колонку QA Testing. Нет дедлайна «конца спринта», заставляющего вас спешить.
Фокусируйтесь на Одном Элементе
С лимитами WIP вы фокусируетесь на меньшем количестве элементов одновременно. Это снижает переключение контекста и улучшает качество тестирования. Тщательно протестировать одну фичу лучше, чем поверхностно протестировать три.
Pull, а Не Push
QA забирает работу из колонки Code Review, когда готов, а не получает работу от разработчиков принудительно. Это даёт вам контроль над рабочей нагрузкой и предотвращает перегрузку.
Измеряйте Cycle Time Тестирования
Отслеживайте, сколько времени элементы проводят в колонке QA Testing. Это ваш cycle time тестирования. Если он растёт, это сигнал проблемы:
- Элементы становятся сложнее
- Тестовые окружения нестабильны
- Требования неясны, вызывая переработки
Kanban vs Scrum: Взгляд QA
| Аспект | Scrum | Kanban |
|---|---|---|
| Временная структура | Фиксированные спринты (1-4 недели) | Непрерывный поток |
| Ритм тестирования | В рамках спринта | Непрерывно, по мере потока элементов |
| Планирование | Sprint Planning каждые 1-4 недели | Just-in-time, по мере появления ёмкости |
| Роли | PO, SM, Dev Team (с QA) | Нет предписанных ролей |
| Метрики | Velocity, sprint burndown | Lead time, cycle time, throughput |
| Релизы | В конце спринта | В любой момент, когда элемент достиг Done |
| Лучше для QA когда | Команде нужна структура и ритм | Команде нужна гибкость и быстрая доставка |
Когда Выбирать Kanban
Kanban работает лучше для QA когда:
- Исправление багов: Баги приходят непредсказуемо. Система на основе потока справляется с этим естественно.
- Команды поддержки: Текущая работа поддержки не вписывается в time-box спринтов.
- Множество приоритетов: Стейкхолдеры часто меняют приоритеты.
- Непрерывный деплой: Фичи выходят в продакшен по отдельности, а не пакетами.
Когда Выбирать Scrum
Scrum работает лучше для QA когда:
- Разработка нового продукта: Команда выигрывает от sprint goals и сфокусированных усилий.
- Сложные фичи: Sprint planning помогает координировать тестирование взаимосвязанных фич.
- Формирование команды: Церемонии Scrum строят сплочённость и коммуникацию.
Метрики Kanban для QA
Lead Time
Время от момента запроса рабочего элемента до его доставки. QA влияет на lead time через длительность тестирования.
Cycle Time
Время от начала работы над элементом до его завершения. Часть cycle time, приходящаяся на тестирование, напрямую под вашим контролем.
Throughput
Количество завершённых элементов за период времени (обычно за неделю). Отслеживайте throughput конкретно QA: сколько элементов проходят через колонку QA Testing в неделю.
Диаграмма Накопительного Потока
Этот график показывает количество элементов на каждом этапе во времени. Он визуально выявляет узкие места:
расширяется со временем] --> B[Тестирование — узкое место] B --> C[Решения: автоматизация,
больше ёмкости QA,
shift-left тестирование]
Упражнение: Спроектировать Kanban-Доску для QA-Команды
Вы — QA-лид команды из 7 человек (4 разработчика, 2 QA-инженера, 1 продакт-менеджер). Команда обслуживает работающую платформу e-commerce и занимается как разработкой новых фич, так и исправлением багов в продакшене.
Текущие проблемы:
- QA всегда перегружен — 10+ элементов ожидают тестирования в любой момент
- Исправления багов добираются до продакшена за 5+ дней
- Разработчики начинают новые фичи, пока их предыдущие фичи ждут QA
- Нет видимости того, над чем QA сейчас работает
Ваша задача:
Спроектируйте Kanban-доску, которая включает:
- Названия колонок и лимиты WIP для каждой колонки
- Как исправления багов обрабатываются иначе, чем фичи (expedite-дорожка или отдельный класс обслуживания)
- Политики перемещения элементов между колонками (особенно вход и выход из QA Testing)
- Какие метрики вы будете отслеживать и почему
- Как вы будете обрабатывать начальный переход из текущего перегруженного состояния
Подсказка
Рассмотрите следующие проектные решения:
- Дорожка «Expedite» (или swimlane) без лимита WIP позволяет срочным багам обходить нормальный поток
- Можно разделить QA Testing на подколонки: «В тестировании» и «Протестировано» для отображения прогресса
- Явные политики предотвращают споры: определите, что значит «готово для QA»
- Для обработки начального бэклога из 10+ элементов может понадобиться временная стратегия «дренажа»
- Подумайте о заблокированных элементах: что происходит, когда QA находит баг? Элемент возвращается в Разработку?
Пример решения
Дизайн Kanban-Доски
Раскладка доски:
| Дорожка | Бэклог | Ready | Dev (WIP: 4) | Review (WIP: 2) | QA Testing (WIP: 3) | QA Passed | Release (WIP: 2) | Done |
|---|---|---|---|---|---|---|---|---|
| Expedite | — | — | Без лимита | Без лимита | Без лимита | — | Без лимита | — |
| Фичи | Элементы | Уточнённые | Активная разработка | Code review | В тестировании / Протестировано | Верифицировано | Деплой | Live |
| Баги | Элементы | Триажированные | Исправление | Review | Верификация | Верифицировано | Деплой | Live |
Лимиты WIP:
- Dev: 4 (по одному на разработчика)
- Code Review: 2 (предотвращает бэклог ревью)
- QA Testing: 3 (управляемо для 2 QA-инженеров, ~1.5 элемента на каждого)
- Release: 2 (предотвращает конфликты деплоя)
- Дорожка Expedite: Без лимитов, но отслеживается отдельно
Политики колонок:
Ready → Dev:
- Критерии приёмки определены и утверждены PM
- QA проверил story на тестируемость
- Подход к тестированию задокументирован (хотя бы кратко)
Dev → Code Review:
- Код завершён с unit-тестами
- Покрытие unit-тестами ≥ 80% для нового кода
- Разработчик провёл self-testing happy path
Code Review → QA Testing:
- Code review одобрен минимум одним коллегой
- Фича развёрнута в staging/тестовом окружении
- Разработчик предоставил заметки для тестирования (что изменилось, на что обратить внимание)
QA Testing → QA Passed:
- Все критерии приёмки проверены
- Исследовательское тестирование завершено
- Нет открытых критических багов или багов высокой серьёзности
- Регрессионные тесты проходят
Метрики для отслеживания:
- Cycle time по типу: Фичи vs. баги — чтобы баги исправлялись быстро
- Cycle time QA testing: Среднее время в QA Testing — для выявления проблем с ёмкостью
- Throughput в неделю: Завершённые элементы — для отслеживания ёмкости команды
- Процент сбежавших багов: Баги в продакшене vs. пойманные в QA
- Время блокировки: Как часто и как долго элементы заблокированы — для выявления системных проблем
Стратегия перехода:
- Неделя 1: Применить лимиты WIP. Уже начатые элементы остаются.
- Неделя 2-3: По мере завершения элементов доска нормализуется. Не начинать новые, пока WIP не окажется в пределах лимитов.
- Неделя 4: Проанализировать данные cycle time. Скорректировать лимиты WIP при необходимости.
- На постоянной основе: Еженедельный анализ диаграммы накопительного потока для выявления трендов.
Продвинутые Практики Kanban для QA
Классы Обслуживания
Не все рабочие элементы одинаковы. Kanban использует «классы обслуживания» для обработки разных приоритетов:
| Класс | Пример | Обработка QA |
|---|---|---|
| Expedite | Сбой в продакшене | Бросить всё, тестировать немедленно, прицельная регрессия |
| Фиксированная дата | Регуляторный дедлайн | Планировать тестирование заранее, задержки недопустимы |
| Стандартный | Обычные фичи | Нормальный поток через доску |
| Нематериальный | Техдолг, рефакторинг | Тестировать при наличии ёмкости, низкий приоритет |
Swarming
Когда колонка QA достигает лимита WIP и элементы накапливаются, команда может провести «swarming» — разработчики временно помогают с тестированием. Это один из самых мощных механизмов Kanban для разрешения узких мест.
Как разработчики могут помочь:
- Выполнять предопределённые тест-кейсы
- Проводить тестирование на уровне кода (интеграционные тесты, API-тесты)
- Настраивать тестовые данные или окружения
- Проводить парное тестирование с QA-инженерами
Каденции Kanban (Встречи)
Kanban не предписывает конкретных встреч, но большинство команд используют следующие:
| Каденция | Частота | Фокус QA |
|---|---|---|
| Ежедневный стендап | Ежедневно | Сообщать о заблокированных элементах, брать новую работу |
| Встреча пополнения | Еженедельно | Проверять предстоящие элементы на тестируемость |
| Ревью доставки | Еженедельно/раз в 2 недели | Анализировать метрики качества, тренды cycle time |
| Ретроспектива | Ежемесячно | Улучшать поток тестирования, устранять узкие места |
Профессиональные Советы для QA в Kanban
Отслеживайте cycle time тестирования неукоснительно. Если среднее время элементов в QA Testing растёт неделя за неделей, поднимайте вопрос немедленно. Не ждите, пока бэклог станет неуправляемым.
Создайте явные критерии «готово для QA». Главная потеря в Kanban — взять элемент в тестирование и обнаружить, что он на самом деле не готов. Определите минимальные критерии (развёрнуто в тестовом окружении, unit-тесты проходят, заметки разработчика предоставлены).
Используйте подколонки внутри QA Testing. Разделите на «В тестировании» и «Протестировано, ожидает верификации» для отображения прогресса внутри этапа QA.
Автоматизируйте регрессионное тестирование. В Kanban вы тестируете элементы непрерывно. Запуск полной ручной регрессии для каждого элемента неустойчив. Автоматизируйте регрессионный набор, чтобы сосредоточить ручные усилия на новой функциональности.
Визуализируйте заблокированные элементы. Когда тест не проходит и элемент возвращается к разработчикам, отметьте его как заблокированный (красный флажок на карточке). Это делает переработку видимой и помогает выявлять паттерны.