Двадцать задач в работе и пять готовых в неделю дают четыре недели ожидания. Эту арифметику не меняет ни одно название процесса. Поэтому спор «Канбан вообще Agile или нет» почти всегда уводит команду от настоящей поломки: перегруженного потока работы.
Вопрос всплывает в командах, которые устали от формального Scrum. Он кажется логичным. Но вместо разговора о ценности и потоке команда начинает спорить о терминах.
Почему сравнивать Agile и Канбан бессмысленно?
Потому что они живут на разных уровнях. Agile Manifesto 2001 года описывает ценности и принципы, а не инструкцию с ролями. Канбан описывает способ управлять потоком задач. Сравнивать их так же странно, как спорить, что важнее: здоровье или пульсометр.
Из этой путаницы и рождается ложный выбор. Канбан считают чем-то «попроще», компромиссом для тех, кто «не смог в Scrum». Agile при этом сводят к ритуалам и ролям. Отсюда выбор «либо Agile, либо Канбан», которого на самом деле нет.
В самом манифесте четыре ценности, и одна из них прямо касается спора: реагировать на изменения важнее, чем следовать плану. Под это определение подходит и Scrum с короткими итерациями, и Канбан с непрерывным потоком, и даже команда без всякой доски, если она регулярно пересматривает план по фактам.
Полезнее другой вопрос: как и зачем команда пользуется доской. От ответа зависит, будет ли она адаптироваться или просто красиво отчитываться.
Доска показывает поломки, которые спринт прятал
Когда процесс буксует, виноватым почти всегда назначают метод. Выбрали «не тот» фреймворк, отказались от Scrum, «не смогли внедрить Agile». Канбан в таких историях становится удобным козлом отпущения.
За этим стоит ошибка мышления. Процесс воспринимают как универсальное лекарство: выбрал правильный фреймворк, и всё заработало само. На деле ни Scrum, ни Канбан не заменяют управленческих решений и продуктового мышления.
Проблема обычно системная. Решения принимают ситуативно, приоритеты меняют под давлением, ограничения игнорируют. Продакт-менеджер оказывается крайним. Он работает при противоречивых ожиданиях и перегруженном потоке.
Канбан вскрывает это особенно болезненно. Очереди, перегрузка и блокировки перестают быть абстракцией: они висят на доске. Признать системную проблему трудно. Обвинить метод проще.
Agile, однако, как раз про работу с такими проблемами. Он не обещает комфорта, он обещает честность. Поэтому Канбан иногда кажется «не Agile»: он слишком Agile для системы, которая к честности не готова.
20 задач в работе означают 4 недели ожидания
Механику здесь задаёт закон Литтла. Джон Литтл доказал его в 1961 году в журнале Operations Research, задолго до любых досок. Для команды он записывается одной строкой.
Среднее время цикла = среднее число задач в работе / пропускная способность.
Посмотрим на расчёт. Команда держит в работе 20 задач и закрывает 5 в неделю. Значит, средняя задача идёт от старта до готовности 20 / 5 = 4 недели. Команда вводит WIP-лимит (предел незавершённой работы) в 10 задач и закрывает те же 5 в неделю. Время цикла падает до 10 / 5 = 2 недель. Люди не стали работать быстрее. Просто внимание перестало дробиться.
В бытовых единицах это выглядит так. При 5 готовых задачах в неделю команда закрывает одну задачу в рабочий день. Если в работе 20, каждая новая задача стоит в очереди за девятнадцатью другими.
Без ограничения незавершённой работы метода просто нет. Когда команда тянет двадцать задач параллельно, каждая ждёт в очередях. Переключения съедают время. Срок растёт, хотя все заняты.
У формулы есть границы, и их стоит назвать прямо. Закон Литтла не означает, что лимит ускорит любую команду. Он описывает средние для устойчивой системы, где входящий поток примерно равен выходящему. В неделю аврала, когда задач приходит вдвое больше, чем уходит, расчёт врёт. Честно применять его стоит на отрезке от 6 до 8 недель; одного спринта для этого мало.
Сам лимит тоже можно поставить плохо, и у каждой ошибки свой симптом. Слишком жёсткий лимит виден по людям, которые простаивают в ожидании ревью или согласования: значит, узкое место не в разработке, и его надо расширять там. Слишком мягкий лимит не виден никак: доска выглядит спокойной, а время цикла не меняется месяцами. Рабочее правило для старта: если на одного человека приходится больше двух задач в работе, лимит снижают, а через 3 или 4 недели смотрят, сдвинулась ли медиана.
Часть ошибок при переходе нормальна. Команды начинают с простой визуализации, без лимитов. Это правильный первый шаг: сначала сделать работу видимой, а оптимизировать её потом. Нормально и то, что эффект приходит не сразу.
Ошибка становится некомпетентностью в другой точке. Фраза «у нас Канбан, поэтому берём всё подряд» говорит об управленческом вакууме. Гибкостью тут и не пахнет. Если команда не смотрит на время цикла, Канбан превращается в список задач с колонками.
Правила входа и время цикла превращают доску в инструмент
Явные правила входа закрывают первый провал. Без политики «что берём в работу и на каком основании» доска наполняется всем, что кто-то счёл срочным. Явное правило даёт продакт-менеджеру редкую возможность. Он может обосновать отказ договорённостью, которую все видели заранее.
Измерение времени цикла закрывает второй. Канбан показывает, где застревает работа. Часто работа стоит в ожидании согласований и в прерываниях. Тогда меняется предмет разговора: чинить приходится процесс вокруг инженеров. Время от начала работы до поставки изменения недаром стоит среди четырёх ключевых метрик в книге Форсгрен, Хамбла и Кима «Accelerate» (2018): оно отражает весь путь задачи.
Но у метрики есть ловушка: показатель, ставший целью, перестаёт честно измерять. Если за время цикла начнут хвалить и ругать, команда быстро научится резать задачи на мелкие куски и закрывать их формально. Поэтому время цикла разбирают вместе с тем, что именно было поставлено.
Третий механизм: Канбан растёт постепенно. Канбан не внедряют как проект с дедлайном. Он развивается вместе с системой и ужесточает лимиты по мере того, как команда учится их выдерживать.
Когда команда ищет, что делать (discovery), Канбан даёт свободу: жёстких итераций нет, новые идеи можно брать в работу сразу. Но без правил отбора поток идей становится бесконечным. Выглядит как гибкость. На деле команда теряет фокус.
Когда команда делает и выпускает продукт (delivery), Канбан делает прогнозы честными. Он показывает, сколько работы система реально переваривает. Если приоритеты меняются постоянно, Канбан обвиняют в хаосе, хотя он лишь показывает отсутствие договорённостей.
В коммуникации доска снижает потребность в статус-митингах: вместо пересказа статусов на встрече разбирают задачи, которые дольше всех стоят в одной колонке. Если у такой задачи нет человека, который её разблокирует, чинить надо договорённости команды.
Что меняется, когда появляются лимиты
Ниже две типичные истории без названий компаний, цифры в них подобраны для наглядности.
Первая команда работала в Scrum и регулярно срывала спринты из-за внешних срочных задач. Продакт-менеджер постоянно оправдывался перед стейкхолдерами. Переход на Канбан затеяли, чтобы снизить давление. Спринты отменили, обязательства убрали, доску оставили.
Первые недели принесли облегчение. Потом стало ясно, что задач в работе больше, а завершённых меньше. Допустим, было 12 задач в работе, стало 22. Поток был перегружен и раньше, просто спринты это скрывали.
После разбора ввели WIP-лимиты и явные правила приоритизации. Брать всё подряд стало нельзя, и это вызвало сопротивление. Но время цикла постепенно сократилось, а команда начала честно говорить о возможностях системы.
Во второй компании Канбан висел давно, но считался чисто визуальным инструментом. Задачи двигались между колонками, а приоритеты менялись несколько раз в неделю. Руководство требовало скорости, команда жаловалась на перегрузку.
Первым шагом стал болезненный вопрос: почему задачи застревают? Команда начала фиксировать время прохождения. Главной проблемой оказались прерывания и ожидание внешних согласований.
Затем ввели простые лимиты и правила входа. Стейкхолдеры, привыкшие «проталкивать» срочное, сопротивлялись. Зато продакт-менеджер впервые спорил цифрами времени прохождения, и громкость голоса перестала решать. Слово «Agile» почти не звучало, но команда начала жить по его принципам.
В первой истории команда сняла ярлык Scrum и нашла Agile в ограничениях. Во второй ярлыка не было вовсе. Решали лимиты и правила входа.
Проверить такой эффект у себя несложно. Сравните медиану времени цикла за 6 недель до лимитов и за 6 недель после, на задачах похожего размера. Заодно отметьте, не менялся ли за это время состав команды и не ушёл ли крупный внешний заказчик: если менялся или ушёл, сокращение времени цикла придётся делить между доской и этими событиями.
Scrum или Канбан: решает характер входящего потока
У методов действительно разная механика. Scrum Guide 2020 строит работу вокруг фиксированной итерации: обязательство команды на спринт выражено целью спринта, а состав работы можно пересогласовать. Это даёт ритм и точки синхронизации. Но поток внешних срочных задач Scrum переносит плохо: каждое вмешательство бьёт по цели спринта.
Канбан итерацию не фиксирует. Работа втягивается по мере освобождения мощности. Управляют лимитами незавершённого и правилами приоритизации. Это устойчивее к непредсказуемому входу, но требует дисциплины, которую в Scrum частично задаёт рамка спринта.
Отсюда правило выбора. Если больше половины работы известно за две недели вперёд, ритм Scrum помогает. Если срочные запросы занимают заметную часть мощности, как в поддержке или платформенных командах, Канбан честнее. Он не заставляет притворяться, будто спринт можно защитить.
Возьмём команду из шести человек, которая закрывает около 40 задач за двухнедельный спринт, и 14 из них приходят уже после планирования. Это 35% мощности, которую спринт не видел заранее. В такой команде цель спринта срывает арифметика. Ей честнее перейти на поток с отдельной «дорожкой» для срочного и лимитом на неё, например не больше 2 срочных задач одновременно.
Выбор не обязан быть бинарным. Scrum Guide не запрещает WIP-лимиты внутри спринта, и многие команды держат ритм Scrum, а поток внутри итерации ограничивают по правилам Канбана. Решает то, видна ли перегрузка и есть ли механизм её снять.
Споры об этом бывают жаркими. Илья Казначеев в статье на Хабре (2024) назвал Scrum раком индустрии и насчитал «10 часов скрам-церемоний в неделю», опираясь на собственные наблюдения. Это мнение одного автора, и выбор метода на нём строить рискованно.
Отдельный упрёк к Канбану касается дедлайнов. Срок здесь прогнозируют по истории похожих задач. Допустим, 85% задач последних двух месяцев прошли от входа до готовности за 9 рабочих дней или быстрее. Тогда прогноз звучит так: «с вероятностью около 85% закончим за 9 рабочих дней». Это менее удобно, чем «к пятнице». Зато честнее даты, назначенной под давлением.
Работает прогноз только при одном условии: команда действительно измеряет поток. Без истории времени цикла Канбан остаётся визуализацией.
Шесть вопросов, чтобы проверить свой Канбан
На вопросы ниже отвечают «да» или «нет». Каждый пункт проверяется по доске или по данным за последний месяц.
- Видна ли на доске вся работа команды, включая срочные запросы «мимо очереди»?
- Есть ли WIP-лимит на каждой колонке «в работе», и превышался ли он реже раза в неделю?
- Записаны ли правила входа так, чтобы стейкхолдер мог прочитать их без продакт-менеджера?
- Считает ли команда время цикла хотя бы по последним 30 задачам?
- Разбирали ли за месяц хотя бы одну задачу, которая шла вдвое дольше медианы?
- Отказывала ли команда срочному запросу со ссылкой на лимит, а не на настроение?
Два «нет» подряд обычно и объясняют, почему Канбан «не работает». Чек-лист не доказывает, что команда делает правильную работу. Он проверяет только поток.
Канбан ускоряет поток, но не выбирает работу
У метода есть предел. Он управляет тем, как работа движется. Правильная ли это работа, он не решает. Если поток ускорился, а приоритеты выбраны неверно, команда просто быстрее идёт не туда. Поэтому Канбан стоит поверх продуктовой стратегии.
Это же объясняет, почему его часто внедряют неправильно. Повесить доску кажется простым шагом. Но без лимитов, правил и анализа доска ничего не меняет. Настоящий Канбан требует говорить «нет» и ограничивать входящий поток. Не все организации к этому готовы, поэтому метод обрезают до безопасного минимума.
Заменой Scrum Канбан тоже не является. Scrum даёт структуру и ритм, Канбан даёт управление потоком. Agile проявляется в способности адаптироваться и честно смотреть на собственную работу, какой бы фреймворк ни висел на стене.
Если команда спорит, Agile у неё или нет, полезнее посмотреть на одну цифру: сколько задач сейчас в работе на человека. Если больше двух, ярлык процесса уже ничего не объясняет.
Начать проще всего с подсчёта. Пока время цикла никто не считает, смена фреймворка только откладывает разговор о перегрузке.