Канбан после трёх колонок: WIP, возраст задач и диаграммы потока
Что ограничивает незавершённая работа, как различаются четыре метрики потока и почему одна и та же доска может давать разные отчёты при другой настройке статусов.
Доска показывает не только исполнителя
В руководстве Kanban University метод описан как дополнение существующего способа работы, а не обязательная замена всех процессов организации. Его предмет — движение работы через систему. Поэтому доска может отражать не фамилии сотрудников, а подготовку, выполнение, проверку и ожидание решения: состояния, через которые проходит результат услуги.
Для такой визуализации нужны явные правила. Руководство перечисляет порядок пополнения доски, критерии завершения этапа, WIP-ограничения, обслуживание разных классов задач и договорённости о встречах. Название колонки «Проверка» не отвечает само по себе на вопросы, кто принимает работу, что считается завершением и когда карточку можно передать дальше.
Правила размещаются заметно, рядом с доской, и согласуются участниками процесса. Они могут меняться вместе с рабочим порядком. Это отличает канбан-систему от статичного отчётного плаката: сама структура показывает то, как работа действительно передаётся между состояниями. Для профессиональных услуг предметом управления часто выступает невидимый запас незавершённых запросов, а не физические детали на складе. Карточка делает эту единицу наблюдаемой, но её смысл задаётся конкретной услугой и договорённостями.
WIP-лимит ограничивает начатое, а не число идей
Atlassian определяет WIP-ограничение как максимум работ в определённом состоянии процесса. В примере разработческой доски лимит установлен на review. Когда проверка переполнена, проблема видна в конкретной колонке; завершение написания кода одним исполнителем ещё не означает готовый результат всей системы.
Если следующий этап занят, участник может помочь с проверкой или совместной работой, а не немедленно открыть ещё одну независимую задачу. При этом число WIP не обязано совпадать с количеством людей: оно описывает допускаемую незавершённую работу. Наличие свободного исполнителя и наличие свободного места в выбранном участке процесса — разные состояния.
В материале Atlassian начальная настройка опирается на наблюдение среднего количества работ в состояниях. Там же отмечен антипаттерн: поднимать лимит всякий раз, когда команда в него упирается. Постоянное превышение может указывать как на слишком узкое ограничение, так и на проблему самого процесса. Изменение цифры и устранение причины накопления поэтому являются разными действиями. Иллюстрация перегруженной доски показывает этот тип ситуации как учебный пример.
Четыре метрики отвечают на четыре вопроса
The Kanban Guide в редакции мая 2025 года выделяет WIP, throughput, возраст работы и cycle time. WIP считает уже начатые, но не законченные единицы. Throughput — количество завершённых за выбранную единицу времени, именно число работ, а не сумму условных баллов. Эти показатели описывают запас в системе и выход из неё соответственно.
Work Item Age измеряет время от начала до текущего момента только для незавершённой работы. Cycle Time измеряет отрезок от начала до завершения уже законченной единицы. Поэтому старая карточка, всё ещё стоящая в работе, может не попасть в привычную выборку завершённых, хотя её возраст уже велик. Это не противоречие между двумя метриками: они относятся к разным состояниям.
Точки начала и завершения задаются в Definition of Workflow. Там же определяется Service Level Expectation: вероятностное ожидание длительности на основе исторических cycle time. Оно включает период и вероятность, а не только одну обещанную дату. Изменение границ процесса меняет и смысл измерений.
| Метрика | Что измеряет |
|---|---|
| WIP | Начатые, но не законченные работы |
| Throughput | Завершённые работы за единицу времени |
| Work Item Age | Время текущей незавершённой работы |
| Cycle Time | Время от начала до завершения |
Источник: The Kanban Guide: Flow Metrics
Control chart зависит от выбранных состояний
В Jira company-managed spaces control chart отображает время работ в выбранных статусах за заданный период. Документация различает cycle time от начала работы и lead time от регистрации запроса до завершения. Для второго варианта в расчёт включают и состояния до фактического начала исполнения. Поэтому два отчёта одной команды могут показывать разные интервалы без ошибки арифметики.
Точка соответствует отдельной работе либо группе; доступны среднее, скользящее среднее и область разброса. Можно менять период, колонки, фильтры и swimlanes. В примере процесса Development временной интервал складывается из In Progress и In Review. Повторное открытие завершённой работы добавляет соответствующее время, а не стирает первоначальный путь.
Отдельно описаны ситуации, влияющие на выборку: карточки с неверно записанным статусом, закрытые дубликаты и ещё не завершённая работа. Фильтрация здесь определяет, какие данные вообще участвуют в измерении. Удаление неудобной реальной долгой задачи и исключение ошибочной записи не являются одинаковыми операциями, хотя визуально оба действия могут уменьшить среднее. В отчёте содержательный смысл имеют и число, и правило отбора.
CFD показывает накопление по этапам
Cumulative Flow Diagram — областная диаграмма состояний во времени. Горизонтальная ось задаёт даты, вертикальная — количество карточек; цветовые области связаны со статусами или колонками. Если область расширяется по вертикали, соответствующий участок, как правило, накапливает работу. Это отличается от графика длительности одной законченной задачи.
В документации Jira подчёркнута привязка CFD к доске. В выборку попадают работы, соответствующие её сохранённому фильтру. Начальная и конечная колонки определяются сопоставлением статусов на самой доске. Поэтому переименование колонки, изменение фильтра и реальное изменение процесса не следует смешивать: они могут повлиять на видимый отчёт разными способами.
Atlassian показывает и обратное движение: карточку, уже попавшую в Done, возвращают в To Do, после чего накопленные значения промежуточных этапов пересчитываются по описанному правилу. CFD не является просто фотографией текущего числа карточек, разложенных на столе. В нём важна история прохождения состояний. Для чтения такого графика нужны сведения о фильтре, периоде и карте колонок, а не только форма цветной полосы.
Как поток сочетается со спринтом Scrum
Kanban Guide for Scrum Teams описывает дополнительные практики потока внутри Scrum, не отменяющие Sprint и его события. Definition of Workflow может охватывать путь внутри спринта и за его пределами. Ограничение WIP создаёт pull-подход: новая работа начинается при наличии вместимости, а не только потому, что появился очередной запрос.
Руководство прямо различает измеренный WIP и политику его ограничения. Кроме лимитов, предполагается активное управление: внимание к заблокированным, стоящим в очереди и стареющим работам. Метрики используются на существующих событиях Scrum. Исторический throughput помогает обсуждению вместимости на Sprint Planning, а Daily Scrum рассматривает препятствия и возраст текущих элементов.
Новый отдельный набор обязательных встреч для этого не требуется. На ретроспективе команда рассматривает определения потока, ограничения, размеры передаваемых партий и другие правила. Изменения могут происходить и внутри спринта, когда обнаруживается соответствующая проблема. Так спринт задаёт регулярный цикл проверки и адаптации, а доска и данные показывают непрерывное движение отдельных работ. Это два масштаба наблюдения одного процесса, а не необходимость выбрать только календарь или только карточки.
