Scrum vs Kanban vs Waterfall: сравнение методологий управления проектами

О чём этот гайд

Выбор методологии управления проектом — одно из самых важных решений на старте. Ошибка стоит дорого: Waterfall в стартапе загонит в каскад переделок, Scrum в стройке породит хаос. Разберём три главных подхода.

Waterfall (Каскадная модель)

Суть

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

Фазы: Требования → Проектирование → Разработка → Тестирование → Внедрение → Поддержка.

Плюсы

• Понятный план и бюджет с самого начала
• Полная документация на каждом этапе
• Легко контролировать подрядчиков: «отдал ТЗ — принял результат»
• Предсказуемость: заказчик точно знает, что получит и когда

Минусы

• Требования должны быть зафиксированы до начала разработки
• Тестирование только в конце — ошибки требований всплывают поздно и стоят дорого
• Заказчик видит результат через месяцы после старта
• Не терпит изменений: любое новое требование запускает лавину пересогласований

Когда применять

• Строительство, инфраструктура, промышленность — физический мир не прощает переделок
• Госпроекты — жёсткие регламенты, ГОСТы, сметы
• Проекты с фиксированным бюджетом и сроками — когда заказчик платит за конкретный результат
• Аутсорсинг с фиксированной ценой (Fixed Price) — объём работ известен заранее

Не применяйте Waterfall, если требования могут измениться в процессе.

Scrum

Суть

Проект разбит на спринты (обычно 2-4 недели). Каждый спринт даёт готовый к использованию инкремент продукта. Команда получает обратную связь после каждого спринта и корректирует курс.

Роли

• Product Owner — голос заказчика, управляет бэклогом, определяет приоритеты
• Scrum Master — фасилитатор, защищает команду от внешних помех, следит за соблюдением Scrum
• Команда разработки — кросс-функциональная, 3-9 человек

Артефакты

• Product Backlog — упорядоченный список всего, что нужно сделать
• Sprint Backlog — задачи на текущий спринт + план их выполнения
• Increment — готовый результат спринта, соответствующий Definition of Done

События

• Sprint Planning (планирование спринта) — до 8 часов
• Daily Scrum (ежедневная планёрка) — 15 минут
• Sprint Review (обзор спринта) — демонстрация результата
• Sprint Retrospective (ретроспектива) — анализ процесса

Плюсы

• Быстрая обратная связь от пользователей/заказчика
• Возможность менять приоритеты каждый спринт
• Прозрачность: каждый знает, кто чем занят
• Команда сама оценивает задачи и берёт ответственность

Минусы

• Требует дисциплины: Daily Scrum без модерации превращается в часовые совещания
• Не подходит для проектов, где результат нельзя «нарезать» на инкременты (мост, завод)
• Сложно оценить общий бюджет и сроки на старте
• Заказчик должен быть доступен для обратной связи каждый спринт

Когда применять

• Разработка ПО — особенно customer-facing продукты
• Стартапы — когда продукт и рынок ещё не определены
• Проекты с высокой неопределённостью — когда требования будут меняться
• Кросс-функциональные команды 3-9 человек

Kanban

Суть

Непрерывный поток задач через визуализированную доску. Нет спринтов, нет фиксированных итераций. Задачи «протекают» через столбцы: To Do → In Progress → Done.

Ключевые принципы

1. Визуализация — доска с колонками (физическая или электронная)
2. Ограничение WIP (Work In Progress) — максимум N задач в колонке «В работе»
3. Управление потоком — измерение времени прохождения задачи (Lead Time, Cycle Time)
4. Явные правила — Definition of Done для каждой колонки
5. Непрерывное улучшение — анализ узких мест (bottlenecks) через Cumulative Flow Diagram

Плюсы

• Минимальное сопротивление внедрению: можно начать с текущего процесса, не ломая ничего
• Гибкость: приоритеты можно менять хоть каждый день
• Прозрачность узких мест: сразу видно, где задачи скапливаются (обычно In Progress или Review)
• Идеален для поддержки и эксплуатации: баги, инциденты, мелкие задачи

Минусы

• Без ограничения WIP Kanban превращается в неуправляемую свалку задач
• Нет естественного ритма поставки (как спринты в Scrum) — нужна самодисциплина
• Сложнее планировать релизы: задачи выходят непрерывно, а не пакетом
• Не хватает церемоний Scrum (ретроспектива, обзор), которые держат команду в тонусе

Когда применять

• Поддержка и эксплуатация — баги, инциденты, запросы в техподдержку
• Команды с непредсказуемым потоком задач — когда каждый день прилетает новое
• Маркетинг, HR, юристы — творческие/сервисные функции
• Scrumban — гибрид: спринты Scrum + ограничение WIP как в Kanban

Сравнительная таблица

Scrumban: гибридный подход

Многие команды приходят к гибриду:

• Спринты из Scrum (ритм поставки)
• Ограничение WIP из Kanban (оптимизация потока)
• Ретроспектива из Scrum (рефлексия процесса)
• Pull-система из Kanban (разработчик сам берёт задачу, а не получает назначение)

Scrumban снижает стресс дедлайнов (спринт — это не жёсткое обязательство, а прогноз), но сохраняет регулярность поставок.

Как выбрать: чек-лист

1. Требования известны заранее? → Да → Waterfall. Нет → Scrum или Kanban.
2. Результат можно поставлять инкрементально? → Нет (мост, дом) → Waterfall. Да → Scrum/Kanban.
3. Заказчик доступен для регулярной обратной связи? → Да → Scrum. Нет → Kanban или Waterfall.
4. Поток задач предсказуем? → Да → Scrum. Нет → Kanban (поддержка, инциденты).
5. Команда готова к Scrum-церемониям? → Да → Scrum. Нет → Kanban (начните с доски и WIP-лимитов).
6. Нужен план на полгода? → Да → Waterfall. Нет → Scrum/Kanban.
7. Размер команды 3-9 человек? → Да → Scrum. Больше → Scrum of Scrums, Less, SAFe.
8. Проект с фиксированной ценой (Fixed Price)? → Да → Waterfall (или Scrum с фиксированным бэклогом).

Типовая ошибка: «Water-Scrum-Fall»

Классический антипаттерн: требования собирают водопадным методом (3 месяца аналитики), потом «разрабатывают по Scrum» (6 спринтов), потом тестируют водопадным методом (2 месяца QA). Это худшее из обоих миров.

Как избежать: если выбрали Scrum — аналитика, разработка и тестирование идут в каждом спринте. Definition of Done включает «протестировано».

Связанные статьи: Архитектурные роли в ИТ: кто какую методологию выбирает, P3.Express: лёгкий фреймворк управления проектами, Методологии планирования: от SMART к OKR, CLEAR, PACT, OKR: полный гайд