Kanban для тестировщика – шпаргалка тестировщика

Как устроена доска

Работа течёт слева направо, а сигнал на новую задачу идёт справа налево: освободилось место – вытянули следующую. Это вытягивающая система: никто не "накидывает" задачи в работу.

Границу "в работе" команда договаривается сама. Всё, что между этими двумя линиями, – незавершённая работа, и именно её и лимитируют.

Доска, которую можно сломать

Двигай карточки вправо. Пропускная способность команды фиксирована: 2 задачи в день – столько людей, столько и рук. Включи режим без лимитов и посмотри, что произойдёт со сроком.

Очередь0

В работе0 / 2

Проверка0 / 2

Готово0

WIP 0

Throughput 2 / день

Прогноз cycle time 0 дн.

Самая старая карточка –

Нажми на карточку, чтобы протолкнуть её в следующую колонку. Начни с очереди.

Прогноз считается по закону Литтла: cycle time = WIP / throughput. Пропускная способность от количества начатых задач не растёт – растёт только очередь. Поэтому 12 задач в работе при throughput 2 в день дают срок 6 дней вместо 1,5. Работы столько же, ждут все дольше.

WIP-лимит: зачем себя ограничивать

Что даёт лимит

Задачи заканчиваются, а не начинаются. Заканчивать выгоднее: ценность приносит только то, что доехало до прода.
Узкое место видно сразу. Упёрлись в лимит проверки – значит, тормозит проверка, а не разработка. Без лимита это не видно, задачи просто копятся.
Меньше переключений. Каждое переключение между задачами стоит контекста, и в тестировании особенно: заново поднять окружение, вспомнить данные.
Появляется повод помогать. Мест в работе нет – иди разгребать проверку, а не начинай новое.

Как ставить лимит

Начни с текущего числа задач в работе и снижай, пока не начнёт колоть.
Грубый старт: примерно по 1–2 карточки на человека в колонке.
Лимит вешают на колонку или на несколько колонок сразу, включая "ждёт проверки".
Лимит на буферных колонках (Ready, Ждёт релиза) – самое полезное: именно там прячется простой.
Лимит, который никогда не срабатывает, слишком высокий и бесполезен.

Типичный обход лимита: завести колонку "ждёт тестирования" без лимита и складывать туда всё. Формально лимит разработки соблюдён, фактически незавершённая работа та же самая, только теперь она в буфере. Лимит должен покрывать всё, что уже начали и ещё не закончили.

Метрики потока

Метрик всего четыре, и все они считаются из одной пары дат: когда карточка стартовала и когда финишировала. Остальное – производные графики.

Метрика	Что меряет	Как считается	О чём говорит
WIP Work in Progress	Сколько карточек начали и ещё не закончили	Просто посчитать карточки между стартом и финишем	Растёт – жди роста сроков. Единственная метрика, на которую ты влияешь прямо сейчас
Cycle time	Сколько прошло от старта работы до готовности	Дата финиша минус дата старта, для завершённых карточек	Смотрят не среднее, а перцентиль: "85% задач едут не дольше 9 дней"
Throughput	Сколько карточек финишировало за период	Просто счёт: 8 карточек за неделю	Основа прогноза. Заменяет velocity: не требует оценок вообще
Work item age	Сколько дней незавершённая карточка уже в работе	Сегодня минус дата старта	Единственная метрика про будущее: показывает задачу, которая протухает прямо сейчас

Cycle time и lead time – не одно и то же

Cycle time – от момента, когда команда взяла задачу в работу, до готовности. Это метрика команды.

Lead time (его же зовут customer lead time) – от момента, когда клиент попросил, до момента, когда получил. Он включает всё ожидание в очереди. Клиенту важен именно он, и он всегда больше.

Разница между ними – это чистое ожидание. Если cycle time 3 дня, а lead time 21 день, чинить надо не скорость команды, а очередь и приоритизацию.

Графики, которые из этого строят

Cumulative Flow Diagram (CFD). Слои по колонкам. Расширяющийся слой – там копится работа, там узкое место.
Cycle time scatterplot. Точка на каждую завершённую задачу. По нему берут перцентили: 50%, 85%, 95%.
Aging chart. Незавершённые карточки по возрасту относительно перцентилей. Карточка выше линии 85% – идёт к срыву.
SLE (Service Level Expectation). Договорённость вида "85% задач закрываем за 9 дней или меньше". Не обещание, а прогноз с вероятностью.

Среднее cycle time почти всегда врёт. Распределение перекошено: куча быстрых задач и длинный хвост из застрявших. Среднее ляжет между ними и не опишет ни те, ни другие. Обещать по среднему – значит промахиваться примерно в половине случаев. Поэтому в Kanban говорят перцентилями.

Практики Kanban

Kanban не переустраивает команду: он накладывается на то, что уже есть, и меняет процесс эволюционно. Никаких новых должностей и обязательного перехода в понедельник.

Практика	Что делать	Что это значит для тебя
Визуализировать	Вынести на доску весь поток, включая ожидание и блокировки	Заведи явные колонки для ожидания стенда и данных. Пока простой не виден, его нет
Ограничить НзР	Поставить лимиты на колонки и соблюдать их	Твой рычаг против "накидали десять задач, разбирайся"
Управлять потоком	Смотреть на метрики, разгребать узкое место, а не грузить свободных	Данные вместо "мне кажется, мы медленно тестируем"
Сделать политики явными	Записать правила перехода между колонками прямо на доске	Здесь ты пишешь, что значит "готово к проверке": какие данные, какой стенд, какие критерии
Внедрить петли обратной связи	Регулярные встречи разного масштаба (каденции)	Место, где ты приносишь цифры по багам и по времени регресса
Улучшать совместно, эволюционно	Менять процесс мелкими шагами по модели, а не революцией	Один эксперимент за раз, иначе не поймёшь, что сработало

Классы обслуживания

Без них любая задача, которую громко попросили, становится срочной. Класс обслуживания договаривается заранее и вешается на карточку.

Класс	Правило	Пример	Что проверяешь
Ускоренный Expedite	Едет вне очереди и может нарушить WIP-лимит. Обычно разрешён один такой слот на доске	Прод лежит, платежи не проходят	Проверяешь только затронутое и сразу. Полный регресс – после
Фиксированная дата	Есть внешний дедлайн, штраф за срыв	Изменение по закону с датой вступления	Планируешь проверку с запасом: сроки известны заранее
Стандартный	Обычная очередь по приоритету, работает SLE	Новая фича из бэклога	Обычный цикл: анализ, кейсы, проверка, регресс
Нематериальный Intangible	Ценность не сейчас, но потом дорого. Берут, когда есть окно	Рефакторинг, техдолг, чистка автотестов	Сюда попадают твои автотесты и стенды – если не попадут, времени не будет

Когда всё срочное – ничего не срочное. Если expedite-задач больше одной за раз, доска превращается в очередь по громкости голоса, и метрики перестают что-либо предсказывать.

Каденции: семь петель обратной связи

Полный набор из метода Канбан. Целиком его почти никто не проводит: обычно живут первые две и что-то из ревью. Знать список стоит – спрашивают.

Каденция	Частота	О чём
Канбан-митинг	Ежедневно	Идём по доске справа налево, ищем застрявшее и блокеры. Не по людям, а по карточкам
Собрание по пополнению	Обычно раз в неделю	Что вытягиваем в работу следующим, по какому классу обслуживания
Собрание планирования поставки	Раз в неделю	Что и когда отдаём клиенту, что готово к релизу
Ревью сервиса поставки	Раз в две недели	Метрики конкретной команды: cycle time, throughput, где встали
Ревью рисков	Раз в месяц	Блокеры и их причины: почему стенд опять недоступен третий раз за квартал
Операционное ревью	Раз в месяц	Взаимодействие команд, узкие места между ними
Ревью стратегии	Раз в квартал	Куда вообще идём, какие сервисы нужны рынку

Роли и ценности

Обязательных ролей в Kanban нет. Метод накладывается на существующие должности: были тимлид и продакт – они и остались. В методе Канбан описаны две необязательные роли, и их иногда спрашивают.

Service Request Manager (SRM)

Отвечает за то, что берём в работу: общается с заказчиками, понимает их потребности, ведёт пополнение очереди. Ближайший аналог – Product Owner, но без обязательств на спринт.

Service Delivery Manager (SDM)

Отвечает за то, как течёт работа: следит за потоком, снимает блокеры, ведёт каденции. Ближайший аналог – Scrum Master или тимлид. Иногда встречается как Flow Manager.

Девять ценностей

ПрозрачностьИнформация о работе открыта всем, включая проблемы.

БалансСпрос не должен превышать возможности. Иначе очередь растёт вечно.

СотрудничествоПоток – общая ответственность, а не эстафета через забор.

КлиентоориентированностьСмотрим на систему глазами того, кто ждёт результат.

ПотокРабота должна течь непрерывно, простой – это дефект процесса.

ЛидерствоУлучшение может предложить любой, не только тот, у кого должность.

ПониманиеЗнать свой текущий процесс, прежде чем его менять.

СогласиеИзменения принимаются командой, а не спускаются приказом.

УважениеК людям, их опыту и текущим должностям.

Чем отличается от Scrum

Коротко: Scrum – фреймворк с фиксированными спринтами, подотчётностями и событиями, его внедряют как есть. Kanban – метод улучшения того процесса, который уже работает: ролей и итераций не требует. Их часто совмещают: Scrum-события плюс доска с WIP-лимитами. Подробно – шпаргалка "Scrum".

Ось	Scrum	Kanban
Ритм	Спринты фиксированной длины	Непрерывный поток, релиз по готовности
Ограничение работы	Sprint Backlog: команда обязуется на спринт	WIP-лимит на колонку, обязательств на период нет
Изменения в объёме	Внутрь спринта новое не влезает без разговора с PO	Приоритет очереди меняется в любой момент, кроме уже начатого
Метрики	Velocity, burndown	Cycle time, throughput, WIP, work item age
Роли	Три подотчётности обязательны	Ролей не требует, две опциональные
Внедрение	Как есть: выкинул элемент – перестало работать	Поверх текущего процесса, эволюционно
Когда подходит	Продуктовая разработка с планируемым объёмом	Поддержка, поток входящих запросов, платформенные команды

Вопросы, на которых валятся

По истории: берут распределение cycle time за последние пару месяцев и отвечают перцентилем – "85% похожих задач мы закрывали за 9 дней или быстрее". Оценивать каждую задачу для этого не нужно, нужны две даты на карточку. Для больших наборов задач считают прогноз методом Монте-Карло по throughput.

Идти помогать там, где затык. Правильный ответ звучит именно так: "перестать начинать, начать заканчивать". Разработчик садится проверять руками, тестировщик разбирает блокеры, кто-то чинит стенд. Простой отдельного человека дешевле, чем простой всей системы. Взять новую задачу "чтобы не сидеть без дела" – худший вариант: это и есть то, что удлиняет сроки.

Источников два, и формулировки в них разные. Метод Канбан Дэвида Андерсона – шесть практик, каденции, классы обслуживания, роли SRM и SDM. Kanban Guide – более короткий документ, где всё сведено к трём вещам: определить и визуализировать поток, активно управлять элементами в потоке, улучшать поток. Метрики там же: WIP, throughput, cycle time, work item age. Обе версии живые, противоречий по сути нет.

Пометить блокером прямо на доске и оставить в колонке – она продолжает занимать место в лимите. Именно это и нужно: блокер должен мешать всем, а не только тебе. Если блокированную карточку убрать с доски "чтобы не мешала", команда о ней забудет, а лимит освободится под новую задачу. Причины блокеров разбирают на ревью рисков.