Продуктовая команда готовит новый раздел приложения, а сервисная команда принимает обращения в течение дня. Обеим нужна видимость работы, но одинаковый ритм им может не подойти. Скрам и канбан различаются способом управления этой работой: Scrum объединяет команду вокруг цели спринта фиксированной длительности, Kanban управляет движением отдельных задач через согласованный поток. Выбор зависит от того, можно ли сформулировать общую цель на короткий горизонт, насколько предсказуем входящий объём и когда команде нужна обратная связь. Доска покажет работу в обоих случаях; правила процесса команда определяет сама.
Чем различаются подходы
Scrum задаёт команде спринты, цель, три зоны ответственности и события для регулярной проверки результата; Kanban предлагает определить рабочий поток, управлять незавершённой работой и улучшать его по наблюдениям. По Scrum Guide Scrum — фреймворк для работы со сложными проблемами. Kanban Guide называет Kanban стратегией оптимизации потока ценности. Канбан-доска — способ показать состояния задач, но одно перемещение карточек ещё не означает, что команда применяет любую из этих систем целиком.
Сравнивать подходы удобнее по решениям, которые команде предстоит принимать в работе. Таблица фиксирует правила руководств; конкретная доска не обязана автоматически поддерживать каждое правило.
| Критерий | Scrum | Kanban |
|---|---|---|
| Ритм | Спринты фиксированной длительности до одного месяца; новый начинается после предыдущего. | Непрерывный поток; момент обзора команда выбирает под свой процесс. |
| Фокус | Одна цель спринта связывает выбранную работу. | Движение отдельных задач через определённый поток и контроль незавершённой работы. |
| Ответственность | Product Owner, Scrum Master и Developers — три зоны ответственности команды. | Руководство Kanban не задаёт такого набора ролей; ответственность определяет команда. |
| Новая работа | Состав работы можно уточнять с Product Owner, не ставя под угрозу цель спринта. | Задачу берут из очереди, когда есть мощность и соблюдены правила потока. |
| Проверка | Sprint Review рассматривает результат, ретроспектива — способ работы; проверки идут и внутри спринта. | Активные задачи и поток пересматривают непрерывно, по расписанию или сочетая оба способа. |
| Незавершённая работа | Scrum Guide не предписывает WIP-лимит как отдельный элемент фреймворка. | Команда явно определяет, как контролирует WIP — количество задач от начала до завершения. |
| Результат | Используемый Инкремент соответствует Definition of Done. | Готовность каждой задачи определяется границами и правилами выбранного потока. |
Скрам и канбан не отличаются наличием карточек: оба процесса можно визуализировать на доске. Разница становится видна в том, когда команда выбирает работу, на каком основании берёт следующую задачу и что считает проверенным результатом. Подробные практики канбана лучше изучить отдельно, прежде чем переносить слово «Kanban» на любую доску с колонками.
Как организована работа в Скраме
Работа в Scrum организована вокруг цели спринта: команда выбирает часть Product Backlog, планирует получение используемого Инкремента и проверяет результат со заинтересованными сторонами. Представим продуктовую команду, которая хочет дать пользователям возможность сохранять черновик новой формы. Цель спринта описывает проверяемое изменение продукта, а выбранные задачи — проектирование формы, сохранение данных и проверка сценария — служат способом достичь цели.
План не замораживается до конца спринта. Scrum Guide допускает уточнение и пересмотр объёма совместно с Product Owner по мере появления новых сведений, если цель спринта не поставлена под угрозу. Готовый Инкремент можно передать пользователям до Sprint Review; обзор спринта не служит обязательными воротами выпуска. Новое срочное обращение команда оценивает с учётом цели и текущего плана, а не автоматически добавляет в спринт или столь же автоматически отклоняет.
Что задаёт цель спринта
Цель спринта задаёт один результат, ради которого команда выбирает и меняет работу внутри спринта. В примере с формой цель — доступный пользователю сценарий сохранения черновика. Список карточек сам по себе целью не становится: часть действий может измениться, если команда найдёт более короткий способ получить тот же результат. Sprint Backlog объединяет цель, выбранные элементы Product Backlog и план их выполнения.
Используемый Инкремент должен отвечать общему стандарту готовности результата. Команда может завершить все карточки плана, но не получить пригодный Инкремент, если сохранённый черновик нельзя открыть повторно. Проверка опирается на работу продукта, а не на заполненность колонки «Готово».
Кто отвечает за решение по продукту
За решение о ценности и порядке Product Backlog отвечает Product Owner; Scrum Master помогает команде применять фреймворк и улучшать его практику; Developers создают используемый Инкремент. Scrum Guide описывает зоны ответственности, а не три обязательные должности в интерфейсе доски. Один человек не превращает себя в Product Owner выбором метки, и настройка колонки не проводит Sprint Review за команду.
В продуктовой работе эти различия устраняют конкретную неопределённость. Если приоритет нового требования спорен, вопрос о порядке Product Backlog адресуют Product Owner. Если команда не может получить результат из-за способа работы, Scrum Master помогает сделать препятствие видимым и устранить его. Developers решают, как выполнить выбранную работу и обеспечить качество Инкремента.
Как движутся задачи в канбане
В Kanban задачи движутся через определённый командой поток: участники договорились, когда задача начата, какие состояния проходит, как контролируется незавершённая работа и по каким правилам она переходит дальше. Представим сервисную команду: обращения приходят в течение дня, часть ждёт уточнений, часть уже проверяется. Колонки «Очередь», «В работе», «Ожидает ответа» и «Готово» показывают местонахождение обращений; правила входа и выхода команда записывает отдельно.
Kanban Guide требует определить способ контроля WIP и правила движения задач. Конкретный предел команда выбирает по своему процессу, а не получает универсальное число из руководства. Обращения, которые ждут ответа, тоже требуют явного правила: считать ли их незавершённой работой и кто возвращает карточку в активную работу после ответа. Разбор очереди и подготовка работы к выбору остаются отдельной практикой, а не появляются сами после добавления колонки.
Когда брать следующую заявку
Следующую заявку берут, когда в активной части потока появилась мощность и заявка соответствует согласованному правилу выбора. Например, команда закончила проверку одного обращения и освободила место в работе. Ответственный смотрит очередь, выбирает следующую заявку по приоритету и переносит карточку. Если все активные места заняты, новое обращение остаётся в очереди или проходит согласованное исключение.
Вытягивание не запрещает срочную работу. Команда заранее определяет, по какому признаку заявка получает исключение, кто принимает решение и какую текущую работу при этом откладывают. Без такого правила срочные карточки обходят очередь по личному впечатлению, и предел незавершённой работы теряет смысл.
Как заметить перегрузку потока
Перегрузку потока видно, когда число открытых обращений превышает договорённый предел или карточки задерживаются в одном состоянии дольше принятого ожидания. Сервисная команда может вручную подсчитать карточки «В работе» и «Ожидает ответа», затем уточнить, какое состояние создаёт очередь. Канбано показывает сами карточки и колонки; встроенные WIP-лимиты и автоматический расчёт метрик для такого анализа не подтверждены.
Сравнение сроков требует одинаковой начальной и конечной точек. Если команда решит сравнить полные сроки задач, ей понадобится фиксировать даты на выбранных границах и считать показатель отдельно. Вид карточки на доске не даёт готовой статистики и не объясняет причину задержки без разбора работы.
Как выбрать подход под тип работы
Подход выбирают по характеру входящей работы, устойчивости краткосрочной цели, моменту обратной связи и возможности контролировать незавершённые задачи. Таблица даёт предварительное решение, которое нужно проверить на реальном процессе; она не объявляет Scrum обязательным для разработки, а Kanban — обязательным для сервиса.
| Признак работы | Проверка команды | Ближе ритм Scrum | Ближе поток Kanban |
|---|---|---|---|
| Поступление задач | Приходит ли работа по мере выполнения текущей, требуя ответа до следующего планирования? | Основную работу можно выбрать на короткий горизонт. | Новые обращения входят в очередь неравномерно. |
| Общая цель | Можно ли назвать один проверяемый результат ближайшего цикла? | Да, выбранная работа складывается в Инкремент. | Задачи ценны по отдельности, общей цели цикла нет. |
| Обратная связь | Когда результат проверяют заинтересованные стороны? | Полезен регулярный обзор результата спринта. | Проверка нужна по мере завершения отдельных задач. |
| Незавершённая работа | Где возникает перегрузка и как команда ограничивает вход? | Команда учитывает мощность при выборе работы спринта. | Команда задаёт правила входа и вручную контролирует WIP в потоке. |
Для продуктовой команды из примера сначала стоит проверить, можно ли за спринт получить используемый сценарий сохранения черновика. Для сервисной команды важнее, чтобы новая заявка попадала в очередь, а исполнитель видел доступную мощность и правило выбора. Оба решения предварительны: если фактическая работа не соответствует допущениям, команда меняет организацию процесса, а не переименовывает колонки.
Когда полезен ритм спринта
Ритм спринта полезен, когда команда может сформулировать одну цель на короткий горизонт, выбрать работу для используемого результата и регулярно обсуждать его со заинтересованными сторонами. Стабильный состав и доступность участников помогают провести планирование, обзоры и ретроспективы. Продуктовой команде стоит проверить, не превращается ли каждая новая просьба в конкурирующую цель внутри спринта.
Фиксированная длительность создаёт момент проверки, но не гарантирует прогноз. Если цель нельзя назвать до начала работы или половину мощности постоянно забирают неожиданные обращения, команде придётся решить, как обрабатывать такой поток. Простое обещание «не менять спринт» противоречит возможности уточнять объём при сохранении цели.
Когда нужен непрерывный поток
Непрерывный поток нужен, когда отдельные задачи поступают неравномерно и их результат проверяют по мере завершения. Сервисная команда принимает обращения разных приоритетов; ей полезно увидеть очередь, ограничить одновременно открытые случаи и назвать правило для срочных заявок. Обзор работы можно проводить регулярно, но ждать конца спринта для передачи завершённого обращения незачем.
Kanban не освобождает команду от договорённостей о качестве. Переход в «Готово» должен означать проверенный результат, а контролируемое число задач не заменяет приоритет. Если команда лишь создала доску и продолжила начинать каждую новую заявку сразу, стратегия управления потоком ещё не задана.
Как совмещать практики без путаницы
Практики совмещают под конкретное затруднение: команда может планировать общую цель и проводить ретроспективы, одновременно визуализируя работу и контролируя WIP. Scrum Guide допускает применять разные техники внутри фреймворка; Kanban Guide допускает дополнять другие способы доставки ценности. Но название «Scrum» уместно, только если команда сохраняет его обязательные элементы, а не выбирает одни встречи и отбрасывает остальные.
Например, продуктовая команда оставляет спринтовую цель, а на доске вручную отмечает договорённый предел задач «На проверке». Предел нужен, если проверки скапливаются и не дают получить используемый Инкремент. Обратная ситуация: сервисная команда ведёт непрерывный поток и раз в неделю обсуждает задержки; регулярный обзор не делает её процесс спринтом.
Слово «Scrumban» не решает организационный вопрос само по себе. Команда должна назвать цель каждого заимствования, правила выбора новой работы и способ проверить результат. В Канбано нет подтверждённого переключателя Scrum ↔ Kanban или предустановленного режима Scrumban; доска служит местом визуализации выбранных правил.
Как проверить выбор на доске Канбано
Выбор на доске Канбано проверяют на одной неделе реальной работы: команда отображает существующие этапы, создаёт карточки для текущих задач, называет правила движения и записывает возникшие ожидания. Недельная проба не доказывает, что метод окончательно выбран; она показывает, какие допущения о входящем потоке и доступной мощности не совпали с работой.
Начните с одного вида работы. Для сервисной команды карточкой будет обращение, для продуктовой — часть работы над результатом спринта. Не смешивайте оба типа на одной пробной доске, если у них разные правила входа и готовности. Для настройки этапов можно собрать доску процесса и затем изменить колонки под фактический путь работы.
Какие колонки отражают процесс
Колонки должны отражать состояния, между которыми работа действительно переходит. Сервисная команда может начать с «Очередь», «В работе», «Ожидает ответа», «Готово»; продуктовая — с «Выбрано», «В работе», «На проверке», «Готово». Оба набора — редакционные примеры. Команда сама определяет момент начала и завершения задачи, смысл ожидания и человека, который принимает результат.
Если карточка стоит в «На проверке», а ответственный уже считает её завершённой, граница готовности неоднозначна. За неделю отмечайте такие расхождения рядом с конкретной карточкой и решайте, какое правило колонки требуется уточнить. Канбано поддерживает настраиваемые доски и колонки, но не выбирает эти правила за участников.
Что записывать в карточке
В карточке записывают ожидаемый результат, исполнителя и дату, если она нужна задаче; описание, метки, чек-лист и вложения добавляют по рабочему случаю. Для обращения описание может содержать вопрос и условие ответа, а вложение — предоставленный клиентом файл без лишних персональных данных. Для задачи спринта карточка может содержать ссылку на согласованный результат проверки. Подтверждённые поля Канбано показывают информацию, которую внесла команда, но не рассчитывают цель спринта и WIP автоматически.
В конце пробной недели команда сверяет четыре наблюдения: сколько новых задач вошло, сколько было завершено, где карточки ожидали ответа и удалось ли сохранить выбранную цель. Числа берут из реальных карточек, не придумывая успешность пилота заранее. Если очередь растёт, а работа не выходит из проверки, уточняют мощность и правила входа. Если цель спринта постоянно меняется из-за незапланированных обращений, отделяют поток обслуживания от продуктового результата.
Какие ошибки мешают выбору
Выбору мешают три ошибки: назвать любую доску Kanban, считать состав спринта неизменным и ждать от инструмента встроенных WIP-лимитов с готовой аналитикой. Каждая ошибка подменяет рабочее правило видом интерфейса. Команда может нарисовать одинаковые четыре колонки для двух процессов, но в одном выбирать работу ради цели спринта, а в другом — вытягивать следующую заявку при появлении мощности.
Неподвижный план спринта тоже плохой критерий сравнения. Scrum Guide защищает цель спринта, но допускает уточнение объёма совместно с Product Owner. Если продуктовая команда узнала о новом препятствии, она обсуждает изменение плана, а не делает вид, что новых сведений нет. Изменение цели — другой вопрос и может потребовать нового решения о спринте.
В Канбано можно вручную видеть карточки, назначать исполнителя и перемещать работу между колонками. Подтверждений встроенного WIP-лимита, автоматического измерения cycle time или burndown для описанной проверки нет. Если команде нужны такие показатели, она заранее определяет способ внешнего подсчёта или выбирает другой инструмент. Доска помогает повторить пробу, но не заменяет управленческое решение.
Скрам выбирают, когда работа складывается в проверяемую общую цель и команда готова поддерживать ритм спринта. Канбан применяют, когда важнее управлять непрерывным потоком отдельных задач, явно контролируя незавершённую работу. Для сомнительного случая достаточно начать с реальной недели: определить границы задачи, договориться о правилах входа и проверить, где выбранный режим расходится с фактической работой.
Если хотите провести такую пробу на собственной доске, можно открыть доску Канбано и вручную зафиксировать выбранные правила на текущих задачах.