Waterfall, или каскадная модель, строится на последовательных этапах: каждый следующий опирается на результат предыдущего.
Для руководителя проекта и заказчика разработки главный вопрос практический: подходит ли такая последовательность их задаче или лучше выбрать гибкий подход вроде Agile. От этого решения зависят сроки, бюджет и то, насколько дорого обойдутся изменения требований.
Дальше разобраны принципы, преимущества и недостатки Waterfall, отличие от Agile, критерии выбора подхода и гибридные схемы.
.jpg)
- Что такое методология Waterfall
- Принципы и особенности водопадной модели
- Как работает Waterfall по этапам
- Преимущества и недостатки водопадной модели
- Отличие методологии Waterfall от Agile
- Когда стоит применять модель Waterfall
- Примеры каскадной модели в стандартах и регламентах
- Гибридные подходы Waterfall и Agile в проектах
- Коротко о главном
Что такое методология Waterfall
Waterfall, или каскадная («водопадная») модель — подход к разработке программного обеспечения (ПО) и управлению проектами, при котором работа идет последовательными этапами: следующий этап начинается после завершения предыдущего, а результат каждого этапа фиксируется в документации.
Эту схему связывают с Уинстоном Ройсом, который в статье 1970 года описал последовательные фазы разработки больших программных систем. Сам Ройс назвал простую реализацию такой схемы рискованной и допускал итерацию между соседними фазами. Слова «waterfall» в его статье нет, а запрет любых возвратов — упрощенная трактовка его схемы. Сегодня каскадную модель применяют при управлении проектами и чаще всего сравнивают с гибкими методологиями.
В типовой схеме выделяют семь этапов, хотя у разных авторов их число и названия различаются.
- Формулировка требований к задаче.
- Проектирование.
- Реализация: программирование и написание кода.
- Воплощение — объединение различных частей продукта в одно целое.
- Тестирование.
- Установка.
- Поддержка.
В других версиях методологии этапов больше или меньше. Например, первым может идти формирование идеи продукта и только затем формулировка требований к нему, а после тестирования обычно устраняют выявленные недочеты. Весь путь от анализа требований до создания работающей системы и ее поддержки образует жизненный цикл разработки. Общее правило остается прежним: следующий этап начинается после успешного завершения предыдущего.
Принципы и особенности водопадной модели
В основе Waterfall лежит несколько принципов: требования фиксируются в самом начале проекта, а каждый этап заканчивается документом, на основе которого команда создает следующий результат. Заказчик, как правило, участвует при формулировке требований и приемке результата, а тестирование проводится в конце, когда продукт уже собран.
Особую роль в этой схеме играет документирование. Ройс писал в 1970 году, что без высокой степени документирования управление разработкой ПО невозможно, и называл жесткое соблюдение требований к документации первым правилом управления. Подробные документы позволяют заранее спланировать работу и сверять с ними результат каждого этапа.
Из-за последовательности основная нагрузка ложится на проектирование: на нем нужно учесть все существенные сценарии и исключить ошибки. Ройс отмечал, что тестирование в конце цикла разработки — первое событие, на котором проявляются проблемы со временем выполнения, памятью и вводом-выводом, и тогда может потребоваться крупная переделка проекта. Это как построить самолет: если конструктор с проектировщиком неправильно рассчитали прочность фюзеляжа, условно говоря, это выяснится только на испытаниях готовой машины.
До начала разработки сверьте требования и проектную документацию с заказчиком и командой.
.jpg)
Как работает Waterfall по этапам
Процесс разработки по Waterfall идет строго по порядку, и на каждом этапе готовится результат, который становится входом для следующего. На примере разработки компьютерной игры видно, что именно создается и принимается на каждом шаге. Цифры в примере условные.
- Определение требований. Технических (по сути — составление технического задания (ТЗ) для программистов), финансовых (определение бюджета), временных (сроки реализации проекта) и других. В примере с игрой это выглядит так: герой бегает и стреляет во врагов, бюджет составляет миллион долларов, срок — 24 месяца. В реальном проекте требования описывают подробнее.
- Проектирование. Все требования собираются в документацию. Для программистов это логика игры, дизайн героев и многое другое.
- Реализация. Написание кода по документации, подготовленной на предыдущих этапах.
- Воплощение — соединение частей программы в единое целое.
- Тестирование. Проверка готовой игры на ошибки. Найденные дефекты исправляют до выпуска продукта, а возврат к более ранним этапам обходится дорого.
- Установка. Выпуск продукта на рынок и установка приложения на устройствах конечных пользователей (для коробочной версии) либо доступ к облаку (если ПО поставляется как услуга по SaaS-модели, то есть как облачный сервис по подписке).
- Техническая поддержка. Сопровождение продукта в эксплуатации: выпуск обновлений, устранение ошибок и другие работы.
Этапы различаются и тем, кто на них работает: сначала аналитики и проектировщики, затем программисты, в конце тестировщики и служба поддержки. Поэтому при передаче проекта между командами особенно важна полнота документации.
Преимущества и недостатки водопадной модели
Недостатки методологии и ее преимущества вытекают из одного свойства: этапы идут последовательно, а требования фиксируются заранее. Когда требования устойчивы, такая схема дает предсказуемость. Когда они меняются, каждое изменение приходится вносить в уже согласованные документы и в уже выполненную работу.
- Изменения после старта обходятся дорого. Если заказчик на полпути решил добавить в ПО новый функционал, придется пересматривать требования и документацию, а для этого нужна отдельная процедура управления изменениями.
- Тестирование проводится в конце. Ошибки проектирования вскрываются поздно. По оценке Ройса (1970), если на тестировании выясняется, что программа не укладывается в ограничения по времени выполнения или памяти, проект приходится переделывать, а перерасход по срокам или стоимости может достигать 100 %.
- Заказчик, как правило, видит результат поздно. До приемки он не видит работающий продукт, поэтому недоработки в требованиях замечают поздно, а сам продукт к релизу может устареть.
- Успех проекта зависит от проектирования и документации. Если требования или проект проработаны неполно, это отражается на всех последующих этапах.
- Больше формальностей. Подробное документирование и согласование этапов отнимают время, а идеи по улучшению продукта, которые появились по ходу работы, сложно внедрить.
У подхода есть и сильные стороны, которые работают при устойчивых требованиях и подробной документации.
- Команда и отдельные специалисты знают, что делать: работа расписана по этапам.
- Объем, сроки и бюджет согласуются заранее, пока требования остаются устойчивыми.
- Понятно, какой документ будет результатом каждого этапа, поэтому заказчику проще следить за ходом проекта.
- Взаимозаменяемость специалистов: подробная документация упрощает передачу работы другой команде.
Отличие методологии Waterfall от Agile
Waterfall строится на последовательных этапах с фиксированными требованиями, а Agile на коротких итерациях и постоянной обратной связи. Waterfall планирует весь проект заранее, Agile планирует ближайшую итерацию и корректирует курс по ее результатам.
Agile — подход к разработке, основанный на ценностях Agile Manifesto. Авторы манифеста ставят людей и взаимодействие выше процессов и инструментов, а работающее ПО выше исчерпывающей документации. Сотрудничество с заказчиком для них важнее согласования условий контракта, а готовность к изменениям важнее следования плану.
Здесь работа делится на итерации. Каждая итерация включает свой цикл проектирования, разработки и тестирования, то есть «микроводопад», поэтому ошибку, как правило, находят раньше, при тестировании ближайшей итерации, а не на финальном тестировании. Переделать небольшой участок проще и быстрее, чем весь продукт, а заказчик дает обратную связь в течение всей работы. Жесткие правила при этом не исчезают: Scrum, один из гибких фреймворков, по Scrum Guide задает роли скрам-мастера (Scrum Master), владельца продукта (Product Owner) и разработчиков, а спринты длятся не больше месяца.
Различия удобно сравнивать по критериям.
| Критерий | Waterfall | Agile |
|---|---|---|
| Планирование | Весь проект планируется заранее по этапам | Планирование на коротких итерациях, уточняется по ходу |
| Требования и изменения | Фиксируются в начале, изменения вносят через отдельную процедуру | Допускают изменения между итерациями |
| Участие заказчика | Как правило, в начале проекта и при приемке результата | Обратная связь в течение работы |
| Тестирование | После реализации, на готовом продукте | В каждой итерации |
| Документация | Подробная, результат каждого этапа | Не отменяется, но приоритет у работающего продукта (по Agile Manifesto) |
| Сроки и бюджет | Задаются заранее при устойчивых требованиях | Заданы рамками итераций, объем работы меняется |
| Риск ошибки | Ошибка проектирования вскрывается поздно | Ошибка, как правило, вскрывается раньше, в ближайшей итерации |
Главное различие — момент проверки решений. Waterfall проверяет их после реализации, Agile в каждой итерации.
Когда стоит применять модель Waterfall
Использовать каскадную модель оправдано, когда требования известны заранее и вряд ли будут меняться, а этапы и приемку нужно заранее закрепить в договоре и документации. Типичные условия:
- Сложные и нестандартные проекты, к которым невозможен шаблонный подход и всю техническую документацию нужно разрабатывать с нуля: подробное проектирование помогает увидеть проблемы до начала кода.
- Условия проекта заведомо неизменны, поэтому вносить правки в согласованные документы не придется.
- Возможна смена подрядчика или выполнение этапов разными исполнителями: по подробной документации проект могут продолжить другие специалисты.
- К результату проекта предъявляются четкие требования, и приемка идет именно по ним.
Если требования уточняются по ходу работы или нужна ранняя обратная связь от пользователей, лучше подойдет Agile.
Перед выбором подхода выпишите требования, которые заказчик готов подтвердить до старта: все, что останется вне этого списка, говорит в пользу итераций.
Примеры каскадной модели в стандартах и регламентах
Применение Waterfall удобно там, где требования и порядок приемки закрепляют заранее. Регламенты показывают, как отрасли описывают такую последовательность. Руководство Управления по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA) 1997 года по контролю проектирования медицинских изделий называет «традиционной моделью waterfall» последовательность фаз проектирования, но отмечает, что на практике между фазами нужны обратные связи, а для сложных изделий ближе параллельная разработка. По оценке Johner Institute, стандарт Международной электротехнической комиссии IEC 62304 для ПО медицинских изделий не предписывает конкретную модель жизненного цикла и считает допустимыми в том числе гибкие модели.
Стандарт 1990 года на создание автоматизированных систем ГОСТ 34.601-90 закреплял стадии и этапы работ в договоре и техническом задании, но допускал в зависимости от специфики системы выполнять отдельные этапы до завершения предшествующих стадий и параллельно во времени. По данным каталога стандартов, с 1 декабря 2023 года он не действует в России, сейчас применяют ГОСТ Р 59793-2021. Руководство FDA, IEC 62304 и ГОСТ 1990 года описывают этапы и документацию, но не требуют именно каскадной модели, поэтому каждая компания решает это по устойчивости требований своего проекта.
Гибридные подходы Waterfall и Agile в проектах
Гибридный подход — по определению авторов Agile Practice Guide, сочетание гибких методов с другими, негибкими техниками, например с этапным планированием.
На практике подходы часто сочетают. По данным мирового опроса Project Management Institute (PMI) (15-й Pulse of the Profession, 2024), использование гибридных подходов выросло с 20 % в 2020 году до 31,5 % в 2023 году, а показатели результата проектов при предиктивном, гибридном и гибком подходах сопоставимы: по объяснению PMI, большинство организаций теперь подбирают подход под свои проекты. В опросе Digital.ai 2025 года участвовали около 350 человек, преимущественно Agile-коучи и консультанты крупных компаний, и 74 % из них используют гибридные, смешанные или собственные Agile-модели; в этот показатель входят и сочетания внутри самих гибких практик.
Одно из возможных сочетаний: требования и архитектуру фиксируют заранее, а реализацию ведут итерациями с обратной связью после каждой. Такая схема может подойти, например, для проектов по разработке нового продукта, где часть требований известна с самого начала, а часть уточняется в работе.
Коротко о главном
- Waterfall — подход, при котором проект проходит этапы последовательно: следующий начинается после завершения предыдущего, а результат этапа фиксируется в документах.
- Основа модели — фиксированные требования, подробная документация и тестирование в конце, поэтому ошибки проектирования вскрываются поздно.
- Преимущества проявляются при устойчивых требованиях, а недостатки связаны с дорогими изменениями и поздней обратной связью от заказчика.
- Agile отличается короткими итерациями и обратной связью, а выбор между подходами зависит от устойчивости требований и того, можно ли проверять решения по ходу работы.
- Подходы часто сочетают: по опросу PMI, доля гибридных подходов выросла с 20 % в 2020 году до 31,5 % в 2023 году.
.png)
.png)
Комментарии (6)
Оставить комментарий