Доска новая, WIP-лимиты нарисованы, а сроки срываются как при спринтах. В работу приходит двенадцать запросов в неделю, закрывается девять, и очередь растёт на три задачи каждую неделю, какой бы фреймворк ни висел на стене. Тут обычно и всплывает старый спор: а Канбан вообще Agile?
Канбан и Agile отвечают на разные вопросы
У этого вопроса будто бы есть ответ «да» или «нет». Его задают менеджеры, разработчики, скрам-мастера и руководители, когда пытаются навести порядок в процессах. Односложный ответ здесь вводит в заблуждение. Спорящие обычно говорят о разных вещах.
Путаница растёт из одной подмены: Agile воспринимают как набор фреймворков, а Канбан как один из них. Agile-манифест говорит о ценностях и принципах, фреймворков и ролей в нём нет. Канбан же служит способом управлять потоком работы: визуализировать его, ограничивать незавершённое и улучшать по данным. Дэвид Андерсон, который в 2010 году описал метод для ИТ-команд в книге «Kanban», вынес в её подзаголовок эволюционные изменения: начинают с того процесса, который есть, и меняют его постепенно. Понятия пересекаются, но лежат на разных уровнях. Вопрос «Agile ли Канбан» поэтому разумно переформулировать: поддерживает ли Канбан в этой команде прозрачность, обратную связь и адаптацию, о которых говорит манифест.
Scrum отвечает на тот же вопрос по-другому. Scrum задаёт ритм: спринт длиной до месяца, цель спринта как обязательство команды, фиксированные события с ограничением по времени. Канбан ритма не навязывает. Это и его сила, и главный риск, о котором ниже.
Канбан берут там, где управление уже сломалось
Стоит появиться проблемам с дедлайнами или перегрузом, и фокус смещается на выбор метода. Возникает версия: взяли не тот подход. Канбан в этой логике подают как спасение и берут, потому что «Scrum не взлетел» или «команда устала от спринтов». Что именно не работало и почему, почти не разбирают.
Ни Agile, ни Канбан не лечат плохие управленческие решения. Если приоритеты скачут, цели туманны, а ответственность размыта, плохо будет выглядеть любой подход, потоковый или итеративный.
Механизм поломки простой: среднее время прохождения задачи равно среднему числу задач в системе, делённому на пропускную способность. Больше задач при той же скорости означает более долгое ожидание для каждой.
Вернёмся к команде из начала статьи. Двенадцать запросов в неделю на входе, девять на выходе. Через восемь недель в системе накопится на 24 задачи больше, чем было. Если пропускная способность не изменилась, каждая новая задача будет ждать на две-три недели дольше. Ни спринты, ни доска это не исправят: исправить можно только вход, то есть решить, какие три запроса в неделю команда не берёт.
Решение о входе не обязательно звучит как отказ. Запрос можно отложить в отдельный список с датой пересмотра, перевести в класс обслуживания с более длинным сроком или вернуть заказчику с вопросом, что он уберёт из уже взятого. Важно, чтобы решение принимал конкретный человек, обычно владелец продукта, и чтобы оно было видно на доске. Иначе запрос всё равно окажется в работе, просто без записи.
В такой среде Scrum действительно часто не работает: спринты рвутся, планирование превращается в фикцию. Канбан кажется честнее, он показывает хаос, не пытаясь заранее его структурировать. Но если им оправдывают отсутствие управления, он становится ширмой. Поток визуализирован, доска красивая, а система принятия решений прежняя.
Честная проба отличается от бегства от решений
Пробовать Канбан стоит, вопрос в том, как. Ошибаться при выборе между Scrum, Канбаном и другими подходами неизбежно: контекст у каждой команды свой. Если команда видит, что работа плохо укладывается в спринты, и пробует поток как эксперимент с гипотезой и критериями успеха, из этого выходит обучение.
Критерии успеха лучше записать числами до старта. Например: за восемь недель медианное время прохождения задачи сократится с 12 до 8 дней, а доля задач, вернувшихся из тестирования, не вырастет выше 10%. Через восемь недель команда смотрит на цифры и решает, оставлять ли поток. Если время прохождения не сократилось, это тоже результат: значит, узкое место лежит за пределами команды, например в согласованиях или в ожидании другой команды, и следующий эксперимент должен быть про них.
Другое дело брать Канбан, чтобы ничего не менять. Когда подход выбирают, чтобы уйти от разговоров о приоритетах и ответственности, он начинает вредить. Признаки узнаются быстро. WIP-лимиты есть, колонки есть, метрики считаются, а решения по-прежнему принимаются интуитивно или под давлением. Ценности прозрачности и постоянного улучшения игнорируются, и доска меняет только расположение карточек.
Противоположная крайность тоже встречается: отвергать Канбан как «не Agile», потому что в нём нет итераций и ролей. Это выдаёт понимание Agile как набора ритуалов без принципов.
Доска показывает поток, решения принимают люди
Чтобы понять, Agile ли Канбан в конкретной команде, надо смотреть на повседневную практику: как люди принимают решения и реагируют на то, что видят на доске.
В повседневной работе Канбан силён тем, что показывает реальное состояние системы: очереди, узкие места и перегрузки становятся видимыми. Одна из самых отрезвляющих цифр здесь эффективность потока, то есть доля времени, когда над задачей действительно работают. Допустим, задача провела в системе десять рабочих дней, а активно ею занимались два. Эффективность потока 20%, и остальные восемь дней задача ждала: ревью, ответа заказчика, свободного тестировщика. Ускорять людей в такой ситуации бессмысленно. Сокращать надо ожидание.
Полезная привычка для ежедневной встречи: смотреть на возраст задач в работе. Если обычная задача проходит систему за девять дней, а какая-то карточка висит в колонке разработки двенадцатый день, разговор начинается с неё. Вопрос один: что ей мешает и кто может это убрать сегодня.
В Scrum улучшения встроены в ритм: ретроспектива наступает в конце каждого спринта, хочешь ты того или нет. В Канбане такого встроенного ритма нет, поэтому улучшения держатся на зрелости и дисциплине команды. Доска сама ничего не чинит. Зрелые команды поэтому сами вводят регулярные встречи: еженедельное пополнение очереди, где решают, что берут в работу, и ежемесячный разбор потока, где смотрят на время прохождения и причины задержек.
Искать, что на самом деле нужно клиенту, Канбан не мешает и не помогает. Если на вход приходят задачи с готовыми решениями, а гипотезы никто не пересматривает, дело в команде, а не в методе. Поток спокойно уживается с колонкой для проверки гипотез и отдельным классом обслуживания для исследовательских задач.
Прозрачность снимает часть догадок и скрытых конфликтов: всем видно, где работа застряла. Но если обсуждения ни к чему не приводят, прозрачность быстро становится фоновым шумом, на который перестают смотреть.
Зрелый Канбан держится на явных правилах
Зрелую систему видно и без опросов. В ней есть явные правила (в Канбане их называют политиками): как задача попадает в поток, по каким правилам расставляются приоритеты, что значит «готово». Есть классы обслуживания, которые говорят, какая работа идёт вне очереди и почему. Например, инцидент в продакшене идёт сразу, но таких задач в работе одновременно не больше одной, а задачи с фиксированной датой стартуют не позже чем за две недели до срока.
Есть и честный прогноз. Вместо обещания «сделаем к пятнице» зрелая команда опирается на историю: 85% задач этого типа проходят систему за девять дней или быстрее. Такой ответ полезнее заказчику, потому что он сразу видит и типичный срок, и риск. Для пачки задач работает то же правило. Если заказчику нужно двадцать задач, а команда за неделю закрывает от шести до десяти, честный ответ звучит как «от двух до четырёх недель», и разброс показывает риск лучше любой уверенной даты.
Там, где всё сводится к визуализации, картина обратная: колонки есть, а объяснить, почему работа движется именно так и что делать при перегрузе, никто не может.
Типичные поломки при переходе узнаются с первого взгляда на доску:
- Канбан заводят как замену управлению: доска есть, а решения по-прежнему никто не принимает.
- Явных правил нет, поэтому непонятно, как задача попадает в поток и когда считается завершённой.
- WIP-лимиты игнорируют, и без ограничения незавершённой работы поток превращается в обычный таск-трекер.
- За состояние системы в целом не отвечает никто.
- Побеждает культ скорости: карточки движутся, а качество и ценность уходят на второй план.
- Канбан и Scrum смешивают без логики: спринты вроде есть, но WIP не соблюдается.
Два оборота стоит держать за красный флаг. «У нас Канбан, поэтому планирование не нужно» обычно означает отсутствие стратегии: Канбан не отменяет планирование, он лишь не диктует его форму. «Канбан не Agile, поэтому ценности не важны» превращает подход в механический процесс, где карточки ездят по доске, а зачем, уже никто не спрашивает.
Две команды, одна доска и разные результаты
Как эти поломки выглядят в жизни, показывают две истории, сложенные из типичных случаев.
Первая команда работала по Scrum и постоянно срывала спринты. Бизнес вмешивался в середине итерации, примерно треть работы каждого спринта составляли срочные запросы, которых не было на планировании, люди выгорали. Scrum обвинили в негибкости и перешли на Канбан. Спринты убрали, ввели доску и WIP-лимиты, и первые недели показали реальный масштаб перегруза: в работе одновременно висело около тридцати задач на шестерых. Напряжение выросло, но появился материал для разговора. Команда ограничила вход, договорилась с бизнесом о еженедельном пополнении очереди и снизила WIP до двенадцати. Через два месяца медианное время прохождения задачи сократилось примерно вдвое, а прозрачность и обратная связь, о которых говорит Agile, появились именно через Канбан.
Во второй компании Канбан жил давно и формально числился «Agile-подходом». Доска настроена, время прохождения считается, руководство уверено, что команда работает гибко. На практике в работу попадало всё, что казалось важным в моменте. WIP-лимиты нарушались «по исключению», и исключения быстро стали нормой. Задачи приходили уже в виде готовых решений, и обсуждение улучшений сводилось к тому, как быстрее выпускать задачи.
Agile-коуч отложил доску и начал с управленческого уровня. Помог зафиксировать политики входа работы, договориться о классах обслуживания, сделать приоритеты явными. Это вызвало сопротивление: пришлось отказаться от части «срочных» задач. Постепенно поток стал стабильнее, команда начала завершать работу и перестала её накапливать. Канбан не превратился в Scrum и не обзавёлся итерациями, но заработал в духе Agile, потому что поменялось качество управленческих решений.
Когда фиксированный ритм Scrum выигрывает у потока
У Scrum в этом споре есть веский аргумент. Спринт заставляет принимать решения. Раз в две недели команда и владелец продукта обязаны сесть и выбрать, что важно, а что нет, и нельзя бесконечно откладывать неприятный разговор. Канбан без регулярных встреч позволяет откладывать его месяцами, пока очередь тихо растёт. Для команды, где управленческая культура слабая, жёсткий ритм может быть полезнее гибкости.
Этот аргумент верен, когда работа в основном плановая, продукт движется к квартальной цели и решения о приоритетах систематически откладываются. И слабеет, когда большая доля работы приходит непредсказуемо: поддержка, инциденты, запросы от продаж. Тогда спринт рвётся каждую неделю, и ритм превращается в фикцию.
Рабочее правило можно задать через долю незапланированной работы. Посчитайте за последние три спринта, какая часть закрытых задач не была на планировании. Если больше 30%, поток с явными политиками и еженедельным пополнением, скорее всего, подойдёт лучше. Если меньше и у продукта есть внятная цель на квартал, Scrum даст полезный ритм.
Тридцать процентов здесь ориентир, его стоит подстроить под свою команду, но сам подсчёт занимает полчаса и заменяет идеологический спор цифрой. Гибрид тоже возможен, если оба метода понятны: спринтовый ритм для продуктовой работы и отдельная полоса потока с WIP-лимитом для срочного.
Есть и граничные случаи, где оба подхода дают мало. Команде из трёх человек с одной крупной задачей на квартал не нужны ни WIP-лимиты, ни спринтовая церемония: хватит еженедельного разговора о том, что мешает. Команде, которая полностью зависит от внешнего подрядчика, доска покажет очередь, но управлять ею придётся через договор и сроки ответа подрядчика.
Для продуктовой разработки Канбан подходит, особенно при высокой неопределённости и нестабильном входящем потоке. Риск у него один: без работы с ценностью он аккуратно доставит не то, что нужно. Время прохождения и частота поставки хорошо описывают поток, но о том, нужна ли была сама поставка, не говорят ничего.
Пять вопросов, после которых спор закончится
Для своей команды хватит нескольких честных вопросов. Есть ли явные правила входа работы и критерии завершения? Соблюдаются ли WIP-лимиты на практике? Отвечает ли кто-то за поток целиком? Используются ли данные о времени прохождения для решений, или метрики считаются ради отчёта? Обсуждает ли команда ценность, или только скорость? Если на большинство вопросов ответ отрицательный, доска есть, а Канбана нет.
Результат измеряйте двумя цифрами. Основная: срок, в который укладываются 85% задач за последние четыре недели. Контрольная: доля задач, вернувшихся на доработку после «готово». Если первая цифра падает, а вторая не растёт, поток действительно стал лучше.
Для команды из начала статьи обе цифры пока бесполезны: при двенадцати запросах на входе и девяти на выходе срок для 85% задач будет расти каждую неделю, как ни перерисовывай колонки. Сначала нужна договорённость с заказчиками о трёх лишних запросах, и только потом метрики начнут что-то показывать. Пока вход больше выхода, сломанным будет выглядеть любой метод.