Agile, Scrum и Kanban: в чём разница

В 2001 году семнадцать разработчиков сформулировали Agile-манифест - четыре ценности и двенадцать принципов. Суть в том, что в условиях высокой неопределённости бессмысленно расписывать проект на год вперёд: требования всё равно изменятся. Лучше двигаться короткими итерациями, показывать рабочий результат заказчику и корректировать курс.

Четыре ключевые ценности agile звучат так:

• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее жёстких контрактов;
• готовность к изменениям важнее следования первоначальному плану.

Обратите внимание: ни слова про спринты, доски или роли. Это и есть agile - рамка ценностей. А вот как именно нарезать работу на итерации и кто за что отвечает, решают уже фреймворки. Scrum и Kanban - два самых популярных способа «приземлить» agile на ежедневную практику. Поэтому формулировка «agile scrum отличия» немного некорректна: Scrum - это подмножество agile, а не его альтернатива.

Три роли в Scrum:

• Владелец продукта (Product Owner) - отвечает за бэклог, расставляет приоритеты, решает, что важнее для бизнеса.
• Скрам-мастер (Scrum Master) - следит, чтобы процесс работал, убирает препятствия, защищает команду от хаоса. Это не начальник, а скорее тренер.
• Команда разработки - те, кто делает продукт. Самоорганизуется и кросс-функциональна: внутри есть все нужные компетенции.

Пять событий (церемоний) спринта:

• Планирование спринта - команда набирает задачи на ближайшие 1-4 недели и оценивает их в story points.
• Ежедневный стендап - короткая 15-минутная синхронизация: что сделал, что буду делать, что мешает.
• Сам спринт - фиксированный отрезок, внутри которого набор задач в идеале не меняется.
• Обзор спринта (демо) - показ готового инкремента заказчику и сбор обратной связи.
• Ретроспектива - команда обсуждает, что в процессе улучшить к следующему спринту.

Ключевая идея: в конце каждого спринта должен быть готовый, потенциально поставляемый инкремент. Это даёт предсказуемость - заказчик видит результат каждые две недели, а команда по velocity понимает, сколько успеет в будущем. Платой за предсказуемость становятся ритуалы: если их игнорировать, Scrum превращается в «скрам по названию», где есть стендапы, но нет ни целей спринта, ни ретро.

Базовые практики Kanban:

• Визуализируй работу. Все задачи - на доске с колонками, например «Бэклог - В работе - Ревью - Готово». Видно, кто чем занят и где затор.
• Ограничивай количество задач в работе (WIP-лимит). В колонке «В работе» не может быть, скажем, больше 3 задач на человека. Нельзя хвататься за всё сразу - сначала доведи начатое.
• Управляй потоком. Задачи тянутся слева направо. Освободился - берёшь следующую по приоритету, а не получаешь её сверху на весь спринт.

WIP-лимит - сердце Kanban. Именно ограничение незавершённой работы заставляет команду доделывать задачи, а не плодить десятки начатых. Когда колонка «В работе» забита, это сигнал: где-то узкое место, и новые задачи брать нельзя, пока не расчистится. Так канбан-доска сама показывает проблемы в процессе.

Kanban не требует менять структуру команды и не навязывает ритуалов. Поэтому его проще внедрить: достаточно вынести существующие задачи на доску и договориться о лимитах. Минус - меньше встроенной дисциплины по срокам: без спринтов и дедлайнов поток может «провисать», если за метриками никто не следит.

Важно: обе методологии - это agile. И Scrum, и Kanban строятся на самоорганизации, визуализации работы и частой обратной связи. Различаются они тактикой, а не базовыми ценностями.

Идея проста: взять у Scrum то, что даёт ритм и фокус (спринты, ретроспективы, оценку в story points), и добавить из Kanban то, что спасает от перегруза (визуальную доску и WIP-лимиты). Получается команда, которая работает релизами, но при этом не набирает в работу больше задач, чем может довести до конца.

Scrumban особенно удобен в двух ситуациях:

• Продуктовая команда + входящий поток. Основная разработка идёт спринтами, но параллельно прилетают баги и срочные правки - их ведут по канбан-полосе с лимитом.
• Переход с одного на другое. Команде тяжело сразу влезть в полный Scrum со всеми ритуалами - начинают с Kanban-доски и постепенно добавляют спринты.

Главное требование к инструменту здесь - чтобы доска поддерживала и спринты, и WIP-лимиты, и переключение представлений одной и той же задачи. В нашем трекере это решено через единый набор задач с тремя режимами: канбан, список и недельный вид. Вы не дублируете задачи под разные методологии - смотрите один бэклог под разными углами. Подробнее про работу с задачами есть в разделе возможностей.

• «Скрам без скрама». Завели стендапы, но нет целей спринта, ретро и владельца продукта. Получается планёрка ради планёрки.
• Kanban без WIP-лимитов. Просто доска с колонками - это ещё не Kanban. Без ограничения незавершёнки команда хватается за всё и ничего не доводит.
• Спринт, который постоянно меняют. Если в середине спринта набор задач переписывают, теряется весь смысл предсказуемости - это уже не Scrum.
• Оценка в часах вместо story points. Точные часы создают ложное ощущение контроля; относительная оценка по Фибоначчи честнее отражает неопределённость.
• Метрики ради метрик. Velocity и cycle time нужны команде для самонастройки, а не для того, чтобы руководитель сравнивал людей между собой.
• Инструмент против процесса. Когда трекер не умеет одновременно в спринты и WIP-лимиты, команда подстраивает процесс под софт, а не наоборот.

В нашем трекере один и тот же набор задач открывается в трёх режимах: канбан-доска с колонками и вытягиванием, список для быстрого редактирования и недельный вид под планирование. Не нужно вести три разных борда - вы переключаете представление, а данные те же. Для Scrum есть оценка в story points по Фибоначчи (1, 2, 3, 5, 8, 13), приоритеты, связи между задачами и фильтры с инверсией. Для Kanban - визуальный поток и гибкая работа с колонками.

Сверху на любую методологию накладывается то, чего в «голых» досках обычно нет: встроенный тайм-трекинг (старт-пауза-фиксация прямо из задачи), планирование загрузки команды по неделям в режиме «План/Факт», вики-база знаний с бесконечной вложенностью, чаты и голосовые комнаты на проект. То есть процесс и коммуникация живут в одном окне, а не размазаны по пяти сервисам.

Отдельный плюс для российских команд - это импортозамещение: продукт open-source и self-hosted, данные остаются на вашем сервере в РФ. Если вы как раз ищете, чем заменить ушедший из России стек, посмотрите разбор про замену Jira и про self-hosted-развёртывание на своём периметре. Кстати, по данным на 2026 год облако Jira Standard стоит порядка 7,91-9,05 $ за пользователя в месяц, а политика биллинга считает оплату по пиковому числу пользователей за период - это одна из причин, по которой команды переходят на открытые альтернативы.

• Старт. Веб-студия из 6 человек ведёт задачи в чате и таблице. Никто не понимает, кто чем занят, дедлайны горят.
• Шаг 1: Kanban. Заводят канбан-доску, выносят все задачи в колонки, ставят WIP-лимит 2 задачи на человека. Сразу видно затор на ревью - правки скапливаются у одного разработчика.
• Шаг 2: метрики. Через месяц смотрят cycle time: задача в среднем висит 9 дней, хотя работы там на 2. Поток понятен, узкое место - согласование с клиентом.
• Шаг 3: Scrumban. Под клиентские проекты вводят двухнедельные спринты с демо, а поток мелких правок оставляют на канбан-полосе с лимитом. Появляется предсказуемость по релизам.
• Итог. Команда не выбирала «agile или scrum» абстрактно - она выращивала процесс под себя, начав с простого Kanban и добавив ритм Scrum там, где он был нужен.