Выбор между гибкой разработкой по схеме скрам (Scrum) и методом канбан (Kanban) начинается не с доски и не с красивых карточек. Сначала смотрят на характер работы: есть ли понятные циклы, меняется ли поток задач, кто задаёт приоритеты и как часто команда получает обратную связь.
Чем скрам отличается от канбана
Скрам строит работу короткими циклами со сроком, целью и набором задач на спринт. Канбан управляет непрерывным потоком: задачи двигаются по доске, а команда следит за очередью, загрузкой и временем прохождения работы.
На практике разница ощущается уже в первый понедельник. В скраме команда собирает спринт, договаривается о цели, берёт объём работы и затем защищает этот объём от лишнего шума. В канбане жизнь устроена иначе: новая задача попадает в очередь, получает приоритет и движется по колонкам без привязки к спринту. Если заявка срочная, её не ждут две недели. Её берут, когда появляется место в работе.
Отсюда рождается разная дисциплина. Скрам требует ритма: планирование, короткие ежедневные встречи, обзор результата, разбор процесса. Канбан требует честности на доске: сколько задач висит, где застряли карточки, кто перегружен, почему работа стареет в колонке. Звучит сухо, но именно здесь обычно вскрывается неприятная правда. Команда занята не тем, что много делает, а тем, что много начинает.
| Критерий | Скрам | Канбан |
|---|---|---|
| Ритм работы | Спринты на одну-четыре недели | Непрерывный поток задач |
| Планирование | Перед началом спринта | По мере появления и освобождения ресурса |
| Роли | Владелец продукта, скрам-мастер, команда | Жёстких ролей нет |
| Изменения в работе | Нежелательны внутри спринта | Встраиваются через очередь и приоритет |
| Главная метрика | Достижение цели спринта | Скорость прохождения задач через поток |
Когда команде подходит скрам
Скрам выбирают, когда продукт развивается через заметные версии, гипотезы и измеримый результат спринта. Метод хорошо работает там, где команде нужен общий фокус, единый ритм и регулярная обратная связь от заказчика или владельца продукта.
Представим команду, которая делает личный кабинет, мобильное приложение или внутренний сервис для сотрудников. У неё есть список функций, ожидания пользователей, ограничения по срокам и несколько спорных идей. Здесь скрам даёт полезную рамку: на ближайший спринт берётся не всё подряд, а набор задач под одну цель. Например, не «делаем авторизацию», а «даём пользователю вход по номеру телефона и восстановление доступа».
Скрам дисциплинирует разговоры о приоритетах. Владелец продукта отвечает за очередь задач, команда оценивает объём, скрам-мастер убирает препятствия в процессе. Не магия, конечно. Если владелец продукта пропадает, планирование превращается в гадание у доски. Если команда берёт в спринт больше, чем способна закончить, метод быстро становится декорацией.
Хороший сигнал в пользу скрама — потребность в завершённых кусках продукта. Не отчётах о занятости, а работающем результате, который показывают людям и проверяют на деле. Да, встречи иногда раздражают. Особенно когда их ведут ради календаря. Но при живом продукте они возвращают команду к главному вопросу: что изменится для пользователя через две недели?
- У продукта есть владелец, который решает приоритеты.
- Задачи связываются в цель спринта, а не живут отдельной кучей.
- Команда может защищать спринт от постоянных внешних перебросок.
- Результат показывают регулярно, а обратная связь влияет на следующий цикл.
Когда канбан даёт больше пользы
Канбан выбирают для потока разнородных задач, где работа приходит постоянно и не укладывается в спринты. Метод особенно полезен поддержке, эксплуатации, редакциям, юридическим и операционным группам, где ценится скорость реакции и видимость очереди.
В канбане нет театра с обещанием закрыть всё к пятнице, если сама природа работы живёт иначе. Сегодня пришла ошибка на проде, завтра договор, послезавтра просьба от крупного клиента. При такой картине спринт часто ломается под давлением входящих задач. Канбан не ругается с реальностью. Он делает её видимой.
Главный инструмент здесь — доска с колонками. «В очереди», «в работе», «на проверке», «готово» — названия меняются, смысл тот же. Команда видит, где копится пробка. Если в проверке лежат десять карточек, бесполезно начинать одиннадцатую разработку. Нужно разгрузить проверку, иначе поток захлебнётся.
Кстати, канбан часто спасает команды, уставшие от псевдоскрама. Бывает, спринты есть, планирования есть, доска есть, а задачи всё равно залетают каждый день сбоку. В таком случае честнее признать потоковый характер работы. Не ломать людей под церемонии, а ограничить число задач в работе и мерить, как долго карточка идёт от входа до готовности.
- Опишите реальные этапы работы, а не желаемую схему из презентации.
- Задайте лимит задач для колонок, где чаще всего образуется очередь.
- Разберите старые карточки: у каждой должен быть хозяин и следующий ход.
- Смотрите не на занятость людей, а на возраст задач и задержки между этапами.
Как выбрать метод без споров о моде
Выбор делают по типу работы, частоте изменений и зрелости ответственности в команде. Если нужен ритм поставки продукта — берут скрам; если важен контроль входящего потока — берут канбан; при смешанной работе методы соединяют.
Самая частая ошибка — выбирать метод по названию, а не по боли. Руководитель слышит, что скрам «ускоряет», команда рисует доску, заводит встречи, а через месяц все ненавидят утро. Причина обычно простая: метод лечил не ту болезнь. Если главная беда в том, что задачи приходят хаотично, один спринт не спасёт. Если беда в отсутствии продуктовой цели, одна канбан-доска тоже не вытянет.
Посмотрите на неделю команды без прикрас. Сколько задач приходит внезапно? Кто решает, что делать первым? Как часто работа возвращается с проверки? Есть ли момент, когда результат показывают заказчику? Ответы быстро разводят методы по разным полкам.
| Ситуация | Подходящий выбор |
|---|---|
| Команда делает продуктовые версии и проверяет гипотезы | Скрам |
| Задачи приходят каждый день из разных источников | Канбан |
| Есть продуктовая разработка и отдельный поток срочных заявок | Скрам для развития, канбан для поддержки |
| Нет владельца приоритетов | Сначала назначить ответственного за очередь |
| Команда перегружена начатыми задачами | Канбан с лимитами незавершённой работы |
Гибриды не грех. Многие команды ведут разработку в спринтах, а срочные дефекты и запросы поддержки пропускают через отдельную канбан-дорожку. Тут нужна договорённость о цене срочности: если всё срочное, значит, приоритетов нет. Жёсткая фраза, зато рабочая.
Какие признаки показывают, что метод выбран неверно
Метод выбран неверно, если он прячет проблемы, а не раскрывает их. Скрам не должен превращаться в отчётность ради отчётности, а канбан — в склад карточек без ограничений и ответственности.
У скрама тревожный знак — вечный недозавершённый спринт. Команда планирует десять задач, закрывает пять, переносит четыре, одну забывает, а потом повторяет тот же сценарий. Виноват не календарь. Чаще всего задачи слишком крупные, приоритеты скачут, а владелец продукта не режет лишнее.
У канбана другой симптом: доска растёт, но поток не движется. Карточек много, статусов много, разговоров много. Готового мало. Тогда нужны лимиты, разбор зависших задач и запрет на новое начало, пока старая работа не прошла узкое место. Неприятно? Да. Зато честно.
Финальный выбор редко делается навсегда. Команда взрослеет, продукт меняется, поток задач тоже. Скрам хорош, когда нужен общий ритм и результат спринта; канбан силён там, где работа идёт непрерывной лентой и требует ясной очереди.
Если убрать названия, останется простой вопрос: что мешает доводить работу до готовности? Ответ на него ценнее любой методички. С него и начинается выбор, который действительно выдержит понедельник, срочные письма и ту самую доску, на которую все смотрят чуть устало после обеда.