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

Гибкая методология Agile: философия, а не инструкция

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

Вот они:

• люди и взаимодействие важнее процессов и инструментов;

• работающий продукт важнее подробной документации;

• сотрудничество с заказчиком важнее согласования условий контракта;

• готовность к изменениям важнее следования первоначальному плану.

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

На Agile строятся десятки конкретных методологий. Scrum и Kanban — самые распространённые. Но есть ещё экстремальное программирование XP, масштабированный Agile-фреймворк для крупных организаций SAFe, облегчённый Scrum для больших команд LeSS и другие.

Если вы слышите «мы работаем по Agile» — это значит только то, что команда придерживается этих ценностей. Как именно — зависит от конкретного фреймворка.

Scrum: когда нужна структура

Scrum — это конкретный фреймворк внутри Agile. У него есть роли, события и артефакты. Всё чётко.

Роли в Scrum

Product Owner (владелец продукта) — человек, который знает, чего хочет заказчик. Он ведёт список задач (бэклог) и расставляет приоритеты: что делать сначала, что потом, а что вообще не делать.

Scrum Master (мастер Scrum) — роль без властных полномочий. Он следит за тем, чтобы команда соблюдала правила Scrum, и убирает всё, что мешает работать. Если разработчику нужен доступ к серверу, а ИТ-отдел молчит уже три дня — это забота Scrum Master.

Dev Team (команда разработки) — люди, которые делают продукт. 3–9 человек. Они сами организуются и решают, кто что делает в рамках текущего спринта (итерации).

Как устроен спринт (итерация)

Работа в Scrum делится на спринты — короткие циклы длиной 1–4 недели. Каждый спринт заканчивается рабочим инкрементом продукта, который можно показать заказчику.

Sprint Planning (планирование спринта) — в начале каждого спринта команда берёт задачи из бэклога и решает, что сделает за следующие две недели.

Daily Scrum, или стендап (ежедневная встреча) — 15 минут каждое утро. Три вопроса: что сделал вчера, что сделаю сегодня, что мешает. Это синхронизация, а не планёрка.

Sprint Review (обзор спринта) — в конце спринта команда показывает, что сделала. Заказчик смотрит и говорит, что понравилось, а что менять.

Sprint Retrospective (ретроспектива) — команда обсуждает процесс, а не продукт. Что шло хорошо? Что мешало? Что изменим в следующем спринте?

Когда Scrum работает хорошо

Типичный пример: разработка мобильного приложения, запуск онлайн-курса, создание минимально жизнеспособного продукта — первой версии для проверки гипотезы, MVP .

Когда Scrum не подойдёт

Scrum требует дисциплины. Спринты, ежедневные стендапы, ретроспективы — это ритуалы, которые нельзя пропускать без потерь. Если команда работает удалённо в разных часовых поясах или задачи слишком непредсказуемые (например, поддержка и устранение багов), жёсткая структура спринтов будет раздражать, а не помогать.

Kanban: когда нужна гибкость

Kanban придумали не айтишники. В 1950-х годах инженер Toyota Тайити Оно разработал систему управления производством — карточки (kan) на доске (ban), которые показывали, на каком этапе находится каждая деталь. Позже разработчики адаптировали идею под управление задачами.

Принцип простой: задачи движутся по колонкам слева направо. Типичные колонки: «Сделать» → «В работе» → «На проверке» → «Готово». Каждая карточка — одна задача.

Ключевые правила Kanban

Ограничение незавершённой работы, или WIP-лимит (Work In Progress) — главная идея Kanban. Нельзя брать новую задачу, пока не закончена текущая. Если колонка «В работе» ограничена тремя задачами — четвёртую берут только после того, как одна из трёх перешла дальше.

Зачем? Потому что человек, который тянет семь дел одновременно, обычно не заканчивает ни одного в срок. WIP-лимит заставляет фокусироваться.

Поток задач — Kanban оптимизирует не отдельные задачи, а поток в целом. Если задачи застревают в одной колонке, это сигнал: там узкое место. Нужно разобраться, почему.

Нет спринтов. Задачи добавляются и выполняются непрерывно. Закончил одну — берёшь следующую из очереди.

Нет обязательных ролей — не нужен Scrum Master или Product Owner. Kanban накладывается на существующую структуру команды.

Когда Kanban работает хорошо

Типичный пример: отдел технической поддержки, редакция, команда маркетинга, юридический отдел, отдел HR.

Когда Kanban не подойдёт

Если продукт сложный, а команде нужно синхронизироваться и регулярно показывать результаты заказчику — Kanban может оказаться слишком свободным. Без спринтов и демо легко потерять ритм и приоритеты.

Сравнение: Scrum и Kanban рядом

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

Agile против Waterfall: когда гибкость не нужна

Иногда лучший выбор — это вообще не Agile. Водопадная модель (Waterfall, или каскадная) работает так: сначала полностью определяются требования, потом проектирование, потом разработка, потом тестирование, потом выпуск. Каждый этап закрыт перед началом следующего.

Это хорошо подходит, когда:

• требования абсолютно чёткие и не изменятся. Например, строительство по готовым чертежам;

• проект регулируется контрактом с фиксированным объёмом работ;

• ошибка на этапе разработки стоит дорого, как в авиации или медицине.

Agile хуже подходит для таких проектов именно потому, что предполагает изменения. Если заказчик точно знает, что хочет, и платит за конкретный результат, итерации и ретроспективы только увеличивают стоимость.

Scrumban (Scrum + Kanban): гибридный подход

На практике многие команды берут лучшее из Scrum и Kanban. Такой гибрид называют Scrumban.

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

Это удобно, если команда уже работает по Scrum, но чувствует, что некоторые процессы слишком жёсткие. Или, наоборот, работает по Kanban и хочет добавить больше структуры.

Как выбрать методологию: четыре вопроса

Чтобы не гадать, ответьте на четыре вопроса.

1. Насколько стабильны требования?

Требования меняются каждую неделю → Agile / Scrum.

Требования зафиксированы и меняться не будут → Waterfall.

Требования непредсказуемы, задачи приходят потоком → Kanban.

2. Какой у вас тип работы?

Создаёте новый продукт → Scrum.

Поддерживаете существующий → Kanban.

И то и другое → Scrumban.

3. Как устроена команда?

Есть Product Owner, который расставляет приоритеты, и команда, которая фокусируется на спринте → Scrum.

Нет выделенных ролей, задачи приходят от разных людей → Kanban.

4. Как часто нужно показывать результат заказчику?

Раз в 1–2 недели → Scrum.

Результат виден постоянно, демо не нужны → Kanban.

Если ответы указывают на разные варианты, попробуйте Scrumban. Работаете в одиночку — Kanban настроить проще всего, даже в простой таблице.

Что бывает, когда выбирают не ту методологию

Несколько реальных ситуаций.

Scrum в поддержке. Команда техподдержки внедрила спринты. Теперь баги фиксируются в бэклоге и ждут следующего спринта. Пользователи злятся: «Наш сервис упал три дня назад — когда починят?» Ответ «Возьмём в работу в следующем спринте» клиентов только разозлит, и они уйдут к конкурентам.

Kanban в продуктовой разработке. Стартап решил делать мобильное приложение по Kanban. Задачи добавляются постоянно, приоритеты меняются каждую неделю, демо нет. Через три месяца заказчик спрашивает: «А что уже готово?» Никто не знает — половина фич в работе, половина «почти готова». Заказчик не понимает, за что вообще заплатил деньги.

Waterfall в нестабильной среде. Компания потратила полгода на разработку фичи по утверждённому плану. За это время рынок изменился, а конкурент вообще выпустил то же самое. Фича вышла, но никому не нужна.

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

Коротко