Waterfall — история большой ошибки

Waterfall — одно из базовых понятий в менеджменте проектов.

Но о термине бесконечно спорят уже десятки лет: кто-то называет Waterfall методологией, кто-то системой, кто-то говорит, что никакого «вотерфолла» вообще нет.

Попробуем разобраться, что всё это значит, и копнём в историю.

Waterfall сегодня

Сформулируем определение так, как его воспринимают на рынке сейчас.

Waterfall — это каскадный подход в управлении проектами. 

Если кто-то говорит «мы работаем по вотерфоллу» — значит, что активности в проекте идут одна за другой, предиктивно и последовательно — за шагом А идёт шаг Б. 

В Waterfall-подходе команда детально планирует на старте, собирает требования к продукту, чётко определяет будущую цель и стремится её достичь. При этом редко возвращается на предыдущие этапы.

Такие последовательные шаги похожи на сход воды со склона, поэтому подход назвали «водопадом».

Утрированно: так будет выглядеть процесс разработки приложения по Waterfall.

1. Сбор требований к продукту.
2. Анализ требований.
3. Проектирование: разработка архитектуры приложения, отрисовка макетов интерфейсов.
4. Разработка.
5. Тестирование: приложение проверяют на баги и соответствие требованиям.
6. Внедрение: приложение выкатывают на всех пользователей.
7. Поддержка и сопровождение: исправление ошибок и другие улучшения.

На практике «чистого Waterfall» не бывает. Это упрощённая идеальная модель. В реальности в строгий каскадный процесс часто вмешиваются типичные «эджаиловые» элементы: прототипирование, циклы обратной связи и прочее.

Чем отличается от Agile

Главное — видением будущего:

• В Waterfall команда на старте точно знает, каким должен быть продукт.
• В Agile команда формулирует ценности продукта в ходе тестирования гипотез и анализа рынка.

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

А в Waterfall, наоборот, всё определено: какой продукт мы делаем, сколько уйдёт времени и денег на работу. Но эта строгость играет и против «водопадной» модели — проект теряет гибкость и хуже реагирует на изменения требований или рынка.

Парадокс Waterfall

Теперь вернёмся к истории. Считается, что американский инженер космических программ Уинстон Ройс первым предложил концепцию «водопадной» разработки. В 1970 году он написал статью «Управление разработкой крупных программных систем».

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

Однако Ройс не упоминает в статье термин «Waterfall». Более того, рассказывая о каскадной модели, он тут же говорит, что…

Строго линейный процесс несёт большие риски и может привести к провалу проекта.

Уинстон Ройс

Инженер космических программ

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

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

Кто придумал Waterfall

Случайность и рынок.

Ройс считал, что разработка — это сложный процесс, в котором должно быть всё: тестирование и анализ продукта, откат на предыдущие этапы и много-много документации.

На иллюстрации ниже — идеальная структура по мнению Уинстона Ройса. Не очень похоже на банальную «лесенку» Waterfall.

Однако Ройса всё равно записали в авторы Waterfall. Сделали это его коллеги. Вот, к примеру, одно из самых ранних упоминаний термина «Waterfall» в статье 1976 года.

Со временем от оригинальной идеи американского инженера мало что осталось.

На рынке популяризировали максимально упрощённую каскадную модель — ту, что изобразил Ройс на первой схеме, когда разработка идёт строго сверху вниз без отклонений, — и назвали её Waterfall.

❌ Waterfall ✅ Предиктивный подход

Есть простое решение для тех, кто не хочет разбираться в этой путанице и ввязываться в бесконечные споры Agile VS Waterfall (и правильно: это не поможет вам лучше управлять проектами).

Используйте вместо «Waterfall» термин «предиктивный подход».

Предиктивный подход — это подход к реализации проекта, при котором ожидаемые содержание, сроки, стоимость и другие аспекты можно определить на ранних этапах проекта и дальше они не будут претерпевать существенных изменений.

Как выглядит процесс работы в предиктивном подходе:

• В начале проекта у вас есть ожидания конечного результата.
• Эти ожидания вы конкретизируете через требования и технические задания.
• Далее разрабатываете план достижения конечного результата.
• Приступаете к реализации плана. Несмотря на возникающие отклонения, стараетесь придерживаться базового плана.
• В конце получаете финальный продукт.

Предиктивный подход актуален для проектов, требующих тщательного планирования, таких как строительство и проведение масштабных мероприятий.

Что выбрать: Waterfall VS Agile

При определении подхода в проекте ориентируйтесь на таблицу:

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

Если вы работаете в стартапе, где нужно постоянно тестировать продукт, гибко меняться под рынок и экспериментировать — выбирайте адаптивный (Agile).

Не ограничивайте себя. Комбинируйте подходы и выбирайте инструменты под специфику каждого проекта.