Agile, Scrum и Kanban простыми словами: в чём разница и что выбрать IT-команде

Agile — это подход к разработке, при котором команда выпускает продукт небольшими частями, часто получает обратную связь и меняет план по ходу работы. Scrum и Kanban — два самых распространённых способа работать по этому подходу: Scrum строит работу вокруг коротких спринтов с фиксированными ролями и событиями, Kanban — вокруг непрерывного потока задач на доске с ограничением работы в процессе.

Статья для основателей, руководителей и тимлидов IT-команд в Казахстане, которые хотят понять, что стоит за этими словами, и выбрать рабочую модель для своей команды. Разберём принципы Agile, устройство Scrum и Kanban, их отличия, гибрид Scrumban, как всё это настраивается в таск-трекере и на чём обычно спотыкаются команды при внедрении.

Agile: ценности, а не методология

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

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

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

Главное, что стоит понять: Agile не говорит, сколько встреч проводить и какие колонки рисовать на доске. Это набор ценностей. Конкретные правила дают фреймворки и методы, которые на нём построены, в первую очередь Scrum и Kanban. Поэтому фраза «мы работаем по Agile» сама по себе ничего не говорит о том, как устроена работа команды.

Частое заблуждение — что Agile означает работу без плана и сроков. Это не так. План есть, но он короткий и пересматривается регулярно, а долгосрочные цели живут в дорожной карте продукта. Сроки тоже есть: команда, которая стабильно работает итерациями, прогнозирует их точнее, потому что опирается на фактическую скорость прошлых итераций, а не на оценку, сделанную полгода назад.

Scrum: роли, спринт, события и артефакты

Scrum — самый формализованный из Agile-подходов. Его правила описаны в Scrum Guide, действующая редакция вышла в 2020 году. Команда работает спринтами длиной не больше месяца, на практике чаще одна-две недели. В конце каждого спринта должен быть готовый к использованию результат.

Роли. В Scrum Guide они называются зонами ответственности. Команда обычно не больше десяти человек.

Роль	За что отвечает	Типичная ошибка
Product Owner	Ценность продукта, порядок задач в бэклоге, цель продукта	Роль отдают директору, у которого нет на неё времени
Scrum Master	Работоспособность процесса, снятие препятствий, обучение команды	Превращается в секретаря, который ведёт протоколы
Разработчики	Создание инкремента, план спринта, качество	Ждут подробного ТЗ вместо участия в планировании

События. Спринт — контейнер для остальных четырёх.

Событие	Длительность по Scrum Guide	Зачем
Планирование спринта	До 8 часов для месячного спринта, для двухнедельного меньше	Выбрать цель и задачи на спринт
Daily Scrum (дейли)	15 минут	Сверить движение к цели спринта и препятствия
Обзор спринта (демо)	До 4 часов для месячного спринта	Показать результат заказчику, обновить бэклог
Ретроспектива	До 3 часов для месячного спринта	Найти, что улучшить в работе команды

Артефакты и обязательства к ним: бэклог продукта с целью продукта, бэклог спринта с целью спринта, инкремент с критериями готовности (Definition of Done). Цель спринта часто пропускают, а зря: без неё спринт превращается в список задач, и при первом срочном запросе никто не понимает, что можно отложить.

Подробно о том, как вести спринты в трекере по дням, мы рассказали в статье про спринты и Agile-поставку в Plane.

Kanban: поток, доска и WIP-лимиты

Kanban пришёл в разработку из производственной системы Toyota. В отличие от Scrum, в нём нет ролей, спринтов и обязательных встреч. Kanban Guide, последняя редакция которого вышла в мае 2025 года, описывает три практики:

1. Визуализировать workflow. Нарисовать этапы, через которые проходит задача, и показать каждую задачу карточкой на доске.
2. Активно управлять задачами в работе. Ограничивать их количество WIP-лимитами, следить, чтобы задачи не застревали.
3. Улучшать workflow. Регулярно смотреть на метрики и менять процесс.

WIP-лимит — центральная идея Kanban. Это ограничение на число задач, которые одновременно находятся на этапе или у человека. Например, не больше двух задач «В работе» на разработчика и не больше трёх задач в «Ревью» на команду. Когда лимит достигнут, новую задачу не берут: сначала помогают довести начатое. Звучит контринтуитивно, но именно так сокращается время от начала задачи до результата.

Как выглядит канбан-доска

Канбан-доска для IT-команды обычно состоит из пяти-шести колонок: «Входящие», «К работе», «В работе», «Ревью», «Тест», «Готово». В заголовке рабочих колонок пишут лимит, например «В работе (4)». У колонки «Входящие» лимита нет, туда падает всё новое, а команда раз в день или раз в неделю решает, что переходит в «К работе» и в каком порядке.

Полезный приём — горизонтальные полосы (swimlanes). Верхнюю полосу отдают срочным задачам вроде упавшего продакшена, у неё свой маленький лимит, например одна задача на команду. Остальная работа идёт в обычной полосе. Так срочное не теряется, но и не съедает всю мощность команды. Если карточки скапливаются перед «Ревью» или «Тестом», это и есть узкое место, которое видно без отчётов.

Kanban Guide предлагает следить за четырьмя метриками потока: количеством задач в работе (WIP), пропускной способностью (сколько задач завершено за период), возрастом задачи в работе и временем цикла (сколько заняла задача от старта до готовности). Для руководителя последняя метрика самая понятная: она отвечает на вопрос клиента «когда будет готово».

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

Критерий	Scrum	Kanban
Ритм	Спринты фиксированной длины	Непрерывный поток
Планирование	В начале каждого спринта	По мере освобождения мощностей
Роли	Product Owner, Scrum Master, разработчики	Не заданы, используются существующие
Обязательные встречи	Планирование, дейли, обзор, ретроспектива	Нет, команда выбирает сама
Изменения в работе	Состав спринта по возможности не меняют	Новую задачу можно взять в любой момент
Ограничение работы	Объёмом спринта	WIP-лимитами на этапах
Главные метрики	Выполнение цели спринта, скорость команды	Время цикла, пропускная способность
Кому подходит	Продуктовая разработка с регулярными релизами	Поддержка, DevOps, поток заявок и багов

Короткое правило выбора. Если команда может планировать на две недели вперёд и срочного в работе немного, Scrum даст ей ритм и предсказуемость. Если больше половины работы приходит внезапно и не может ждать следующего спринта, Kanban честнее: он не делает вид, что план существует.

Ни один подход не лучше другого в целом. Разные команды в одной компании могут работать по-разному: продуктовая разработка спринтами, поддержка и DevOps по Kanban. Важно, чтобы внутри одной команды правила были едиными и понятными всем, а руководитель видел обе картины в одном трекере.

Scrumban: когда нужен гибрид

На практике многие команды приходят к смеси двух подходов, её называют Scrumban. Из Scrum берут регулярное планирование, обзоры и ретроспективы. Из Kanban — непрерывный поток задач и WIP-лимиты.

Scrumban хорошо подходит в трёх ситуациях:

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

Типичная схема: раз в неделю или две команда проводит короткое планирование и пополняет колонку «К работе», задачи берутся по WIP-лимитам, для срочного выделена отдельная полоса на доске с отдельным лимитом, а ретроспектива проходит по расписанию. Как устроить поток багов и срочных задач с приоритетами и SLA, мы разобрали в статье про баг-трекинг и workflow.

Как это выглядит в таск-трекере

Agile можно вести на стене со стикерами, но как только команда работает удалённо или проектов больше одного, нужен трекер. Ниже соответствие понятий в двух системах, которые чаще всего выбирают IT-команды в Казахстане.

Понятие	Jira	Plane
Бэклог продукта	Бэклог проекта	Бэклог проекта
Спринт	Sprint на Scrum-доске	Cycle (цикл)
Крупная фича	Epic	Epic как тип задачи, Module
Канбан-доска	Kanban-доска проекта	Layout «Доска»
WIP-лимит	Ограничения на колонках доски	Правило команды, контроль через представления
Отчёты	Burndown, скорость, накопительная диаграмма потока	Прогресс цикла, дашборды
Поиск и фильтры	JQL	PQL

Настройка в обоих случаях начинается одинаково: четыре-пять статусов, отражающих реальные этапы, один бэклог, понятные типы задач. Ошибка — пытаться сразу настроить всё, что умеет инструмент. Сравнение Jira и Plane по остальным критериям — в статье Plane или Jira в 2026 году.

Типичные ошибки внедрения в казахстанских IT-командах

По нашему опыту внедрений, команды спотыкаются не о теорию, а о привычки.

• Scrum ради Scrum. Компания вводит все события, но не меняет способ принятия решений. Дейли превращается в отчёт руководителю, ретроспектива — в формальность без изменений.
• Product Owner без полномочий. Роль формально есть, но приоритеты всё равно меняет основатель в личной переписке с разработчиками.
• Спринт без цели. В спринт набрасывают всё, что накопилось, и в конце закрывается половина задач.
• Бэклог в нескольких местах. Часть задач в трекере, часть в чате с клиентом, часть в голове у тимлида.
• Kanban без лимитов. Команда называет доску канбаном, но у каждого по шесть задач «В работе», и ни одна не доходит до конца.
• Ретро без действий. Проблемы обсуждают каждые две недели, а изменения не вносят. Через два месяца ретро перестают проводить.

Контекст Казахстана. Сильная WhatsApp-культура ломает Agile чаще, чем что-либо другое. Клиент или руководитель пишет разработчику напрямую, задача уходит в работу в обход бэклога, и план спринта перестаёт что-то значить. Рабочее правило: любой запрос из мессенджера превращается в задачу в трекере, а решение о том, брать ли её в текущий спринт, принимает Product Owner. Второй местный нюанс — распределённые команды между Алматы, Астаной и удалёнкой и двуязычие: дейли и ретро лучше проводить в одном видеоканале по расписанию и заранее договориться о языке задач в трекере, чтобы описания были понятны всем.

С чего начать: план на первый месяц

Неделя	Что делаем	Результат
1	Собираем все задачи в один бэклог, выбираем Scrum или Kanban, договариваемся о статусах	Единый бэклог, 4–5 статусов, назначен Product Owner
2	Первый спринт или запуск канбан-доски с WIP-лимитами	Команда работает только из трекера
3	Дейли по 15 минут, правило «запросы из чата — только через задачу»	Срочное видно на доске, а не в переписке
4	Демо результата и первая ретроспектива, одно-два изменения в процессе	Понятно, что работает, а что поменять

Не пытайтесь внедрить всё сразу. Одна команда, один бэклог, один месяц честной работы дадут больше, чем трёхдневный тренинг по методологиям для всей компании. Общий порядок перехода от задач в мессенджерах к системе мы описали в статье как внедрить таск-трекер в компании.

Как мы это делаем

Мы начинаем с диагностики: смотрим, какая работа приходит в команду, сколько в ней срочного, кто принимает решения о приоритетах и где сейчас живут задачи. По итогам предлагаем модель (Scrum, Kanban или Scrumban) и минимальную настройку трекера под неё, обычно в Jira или Plane. Затем запускаем пилот с одной командой на два-три спринта или месяц работы по Kanban, проводим вместе с командой первые планирования и ретроспективы и только после этого переносим подход на остальные команды.

Если хотите выстроить Agile-процесс вместе с трекером, а не отдельно от него, посмотрите страницу внедрения таск-трекеров Jira и Plane: там описан процесс, сроки и что входит в результат.

---

Источники. Agile-манифест: agilemanifesto.org. Scrum Guide 2020: scrumguides.org. Kanban Guide 2025: kanbanguides.org. Репозиторий Plane: github.com/makeplane/plane.

Термины простыми словами

Agile

Набор ценностей и принципов разработки: короткие итерации, частая обратная связь, готовность менять план. Не методология, а способ мышления.

Scrum

Фреймворк для работы короткими спринтами с тремя ролями, пятью событиями и тремя артефактами. Даёт команде ритм планирования и релизов.

Kanban

Метод управления потоком работы: визуализация этапов на доске, ограничение задач в работе и постоянное улучшение процесса.

Спринт

Отрезок работы длиной не больше месяца, обычно одна-две недели, с целью и набором задач. В конце команда показывает результат.

Product Owner

Человек, который отвечает за ценность продукта и порядок задач в бэклоге. Решает, что команда делает в первую очередь.

WIP-лимит

Ограничение числа задач в работе одновременно. Заставляет доводить начатое до конца и показывает узкие места процесса.

Ретроспектива

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

Scrumban

Гибрид Scrum и Kanban: регулярное планирование и ретроспективы плюс непрерывный поток задач с WIP-лимитами.