Классическая модель Waterfall (каскадная) и гибкие методологии Agile (Scrum, Kanban и т. д.) представляют два принципиально разных подхода к управлению жизненным циклом разработки ПО. Ниже — подробное сравнение по ключевым аспектам.

1. Подход к планированию и изменению требований

Waterfall

• Обширное предварительное планирование: собирается полный набор требований (SRS), утверждается техническое задание.

• Любые изменения после старта работы требуют формального процесса управления изменениями (Change Control).

• Риски изменений велики: «поймать» новый сценарий на поздних этапах сложно и дорого.

Agile

• Эволюционное, итеративное планирование: требования уточняются и приоритизируются по спринтам или итерациям.

• Изменения приветствуются на любом этапе, процесс построен на адаптации под новые вводные.

• Минимизируются риски, каждый цикл (обычно 1–4 недели) приносит работающий инкремент.

2. Структура проекта и фазы

Этапы	Waterfall	Agile
Анализ требований	В начале проекта	Непрерывно, перед каждым спринтом
---	---	---
Проектирование	Полное (System Design) до кода	Lean- и just-in-time проектирование
---	---	---
Разработка	После завершения дизайна	Постепенные инкременты по спринтам
---	---	---
Тестирование	После полной разработки	В каждом спринте (автотесты, интеграция)
---	---	---
Внедрение	В конце проекта	Частичные релизы/демо по спринтам
---	---	---
Поддержка	Отдельная фаза	Непрерывная поддержка и рефакторинг
---	---	---

3. Роли и ответственность

Waterfall

• Чёткая иерархия: руководитель проекта (PM), бизнес-аналитик, архитектор, разработчики, тестировщики.

• Ответственность за результат концентрируется на PM.

Agile

• Кросс-функциональные, самоорганизующиеся команды: Product Owner, Scrum Master (или Agile Coach), разработчики, QA, дизайнеры.

• Распределённая ответственность: каждый отвечает за качество и сроки внутри итерации.

4. Документация

Waterfall

• Обширная документация на каждом этапе: BRD/SRS, TDD, дизайн-документы, планы тестирования, инструкции по эксплуатации.

• Большой объём формальных артефактов часто тормозит скорость.

Agile

• Минимально необходимая документация: user stories, acceptance criteria, Definition of Done, lightweight диаграммы.

• Фокус на рабочем ПО, а не на бумаге. Документация живёт рядом с кодом (Wiki, README, автогенерируемые API-спецификации).

5. Метрики и контроль прогресса

Waterfall

• Контроль выполняется по графику (Gantt chart), проценту выполнения фазы, по ключевым контрольным точкам (milestones).

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

Agile

• Прогресс измеряется Velocity (story points/spints), burn-down charts, cycle time.

• Прозрачность: любой момент видно, сколько историй закрыто и сколько осталось.

6. Управление рисками

Waterfall

• Основные риски выявляются в фазе анализа; потом переходят на исполнение с ограниченными возможностями реагирования.

• Позднее тестирование может выявить критические дефекты, дорогостоящие для исправления.

Agile

• Риски минимизируются короткими циклами: раннее тестирование, интеграция, демонстрация заказчику.

• Регулярные ретроспективы позволяют оперативно исправлять процесс.

7. Вовлечённость заказчика и пользователей

Waterfall

• Заказчик вовлечён на старте (сбор ТЗ) и в конце (приёмка).

• Долгие периоды «вне процесса» затрудняют корректировку курса.

Agile

• Заказчик (или его представитель — Product Owner) участвует в планировании каждого спринта и на регулярных демо.

• Своевременный фидбек позволяет быстро менять приоритеты и дорабатывать фичи.

8. Гибкость и адаптивность

Waterfall

• Сильно структурированный, мало адаптивный подход.

• Хорош для проектов с фиксированными требованиями и низкой вероятностью изменений (например, инженерное ПО с требуемыми стандартами).

Agile

• Максимально гибкий, обеспечивает быстрое реагирование на изменения.

• Идеален для инновационных, исследовательских проектов, стартапов, мобильных/Web-приложений.

9. Результат и качество

Waterfall

• Цель — выполнить все заранее спланированные фичи и только после этого протестировать.

• Может привести к «функциональному избыточному продукту» с недостаточным качеством UX.

Agile

• Цель — каждый спринт выпускать готовый к использованию продукт с минимальным набором функций (MVP), но высокого качества.

• Постоянный рефакторинг и CI/CD поддерживают кодовую базу в устойчивом состоянии.

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

Waterfall

• Проекты с жёсткими регуляторными или контрактными требованиями.

• Когда требования стабильны и понятны заранее (строительство, встраиваемые системы, крупные ERP-внедрения).

Agile

• Проекты с высокой степенью неопределённости требований.

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

Разница между Waterfall и Agile в первую очередь — это ментальность: план-drive vs value-drive, предсказуемость vs адаптивность, фазы-оригами vs итерационный процесс. Правильный выбор зависит от контекста, зрелости команды и характера продукта.