Что не понравилось в Waterfall

# Критика методологии Waterfall

Что такое Waterfall

Waterfall (Каскадная модель) — это традиционный подход к разработке ПО, где проект проходит последовательные фазы: требования → дизайн → реализация → тестирование → развёртывание → поддержка. Каждая фаза завершается перед началом следующей.

Основные проблемы Waterfall

1. Отсутствие гибкости

Если требования изменяются (а они ВСЕГДА меняются), очень сложно вернуться на предыдущие этапы:

Требования → Дизайн → Реализация → Тестирование → Развёртывание
     ↑                                                    ↓
     └────────────────────────── Очень сложно вернуться

Сейчас требования от заказчика изменяются во время разработки, а Waterfall этого не предусматривает.

2. Поздняя обратная связь

Вы получаете обратную связь только в конце проекта, когда уже потрачены все ресурсы:

• Требования согласованы на бумаге, но заказчик видит результат только через 6-12 месяцев
• Если результат не соответствует ожиданиям — переделывать всё очень дорого
• К концу проекта запросы заказчика уже устарели

3. Долгий Time-to-Market

Проект может разрабатываться годами, а конкуренты уже выпустят свой продукт. Например:

• Начали разработку в 2023 году
• К выпуску в 2025 году технологии устарели
• Заказчик уже потратил миллионы

4. Высокие риски

Все яйца в одной корзине:

• Если фаза дизайна была неправильной, ошибку найдут только в тестировании
• Переделка может быть невозможна или очень дорога
• Нет возможности контролировать риски на ранних этапах

5. Проблемы с коммуникацией

Технические специалисты не взаимодействуют с заказчиком в процессе разработки:

Анализатик ─→ Документация ─→ Разработчик ─→ Тестировщик ─→ Заказчик

По цепочке теряется информация, возникают недопонимания.

6. Предположение, что требования полностью известны

В реальности:

• Заказчик сам не знает, что ему нужно
• Требования становятся ясны только когда заказчик видит работающее ПО
• Невозможно указать все требования в начале проекта

7. Testing только в конце

Ошибки, обнаруженные в конце, очень дорогие в исправлении:

Затраты на исправление ошибки:
Найдена на этапе требований:  1x
Найдена на этапе дизайна:     3x
Найдена на этапе разработки:  5x
Найдена при тестировании:     10x
Найдена после развёртывания:  100x

8. Неопределённый конечный результат

Так как спецификация писалась в начале проекта, она часто:

• Неполная или неточная
• Не отражает реальные потребности
• Становится грузом, который замораживает разработку

Реальный пример: Проект провалился

2020: Требования — эксперты пишут 500-страничный документ
2021: Дизайн — 12 месяцев архитектуры и планирования
2022: Разработка — 18 месяцев кодирования
2023: Тестирование — находят критические ошибки в логике
2024: Попытка переделать — стоимость превышает бюджет в 3 раза
2025: Проект отменили, вложения потеряны

В Agile этот же проект:

• Разбили на спринты по 2 недели
• Показывали результаты заказчику каждый спринт
• Меняли требования на ходу
• Выпустили первую версию за 3 месяца

Сравнение с Agile

Когда всё ещё используется Waterfall

1. Критически важные системы — космос, авиация, ядерные станции (нельзя менять требования)
2. Заказчик очень чётко знает что хочет — редко
3. Контрактные проекты с фиксированным бюджетом — рискованно
4. Встроенные системы — часто нельзя обновить после выпуска

Даже в этих случаях используют гибридные подходы.

Вывод

Waterfall устарела для большинства проектов. Её критикуют за:

• Отсутствие гибкости
• Позднюю обратную связь
• Высокие риски
• Долгий Time-to-Market
• Плохую коммуникацию
• Дорогие переделки

Современный подход — Agile, который позволяет менять требования, получать ранний feedback и минимизировать риски.