Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Agile — это ценности, а не методология
Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
-
Готовность к изменениям важнее следования первоначальному плану.
Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.
Waterfall: миф о жестком подходе
Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.
Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:
Техническое задание
Эскизный проект
Технический проект
Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)
Внедрение (Подготовка и передача программы)
Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:
Устранение ошибок.
Развитие и усовершенствование продукта.
Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.
Почему возникает миф о несовместимости?
Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».
Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут:
- Давайте заново начнем.
Однако в реальности:
Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками.
Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum.
Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.
Синтез вместо конфронтации: гибридные подходы
На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например:
Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.
Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.
Как же выбирать методологию? Нужно опираться на критерии, а не догмы
Выбор между Waterfall и итерационными методами зависит от четырёх факторов:
Предсказуемость требований.
Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.Стоимость изменений.
В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.Регуляторные ограничения.
В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.Культура команды и заказчика.
Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.
Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum
Заключение: за пределами маркетинговых мифов
Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:
Какова степень неопределённости требований?
Какие ограничения накладывают регуляторы или бюджет?
Насколько команда и заказчик готовы к гибкости?
Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:
Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».
Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).
Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.
Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.
Комментарии (34)
dkfbm
01.12.2025 21:19В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Я свой первый эджайл проект делал для SwissRe: второй по величине в мире перестраховочной компании. Регулирования у них там никак не меньше, чем у банков. Очень даже возможно, ничто не мешает к моменту сертификации у регулятора подходить мелкими итерациями с непрерывной обратной связью от заказчика.
Cordekk Автор
01.12.2025 21:19Agile же не про итерации. А про документирование, согласования и соответствие конечного результата ожиданиям. Везде, где есть регуляторы и сертификации, будет много формализма и документации, поэтому чистый agile, когда все на личных договоренностях и на работающем продукте неприменим.
JBFW
Имхо, сейчас теоретики от IT уподобляются средневековым схоластам, ведущим дискуссии о количестве ангелов, умещающихся на острие иглы.
Методики, ценности, блаблабла.
Возьмем, например, строительство дома.
Для того чтобы он не развалился - нужен фундамент (да хоть 4 камня - это тоже фундамент!), для того чтобы построить правильный фундамент - нужно понимание как хотя бы примерно будет выглядеть этот дом в итоге, из чего он будет построен, каков порядок бюджета на строительство, и примерный желаемый срок.
А вон та картинка, про "хороший Agile" с самокатом - велосипедом - машиной прямо-таки наводит на мысль, что сначала надо построить хотя бы конуру, потом расширить ее до сарайчика, а потом доработать его до дома. И вкрячить сверху башню.
Так это не работает!
Чтобы построить башню - нужно закладывать такие бюджеты, ресурсы и сроки, что если у вас их нет - лучше ограничьтесь домиком, сразу, на этапе "я хочу".
И сразу же - делайте фундамент под дом, а не под собакину конуру: ПОТОМ переделывать выйдет дольше и дороже.
Почему люди думают, что в IT не так?
navferty
Потому что в IT действительно не так. Любая аналогия, как и приведённая Вами, подобна котёнку с дверцей.
Когда строится дом, уже на старте есть готовый план. И если в государстве есть нормальный надзор над строительной отраслью, никто в здравом уме не будет пытаться "добавить ещё пару этажей" или "а давайте вместо бетона попробуем использовать пластик" когда половина дома уже построена.
Когда реализуется IT проект, ситуация прямо противоположна. Начали пилить стартап, сделали наполовину бэкенд и на три четверти мобильное приложение - и тут выясняется, что приняли новый закон / конкуренты выкатили своё приложение / менеджеру пришла гениальная идея / подставьте свой вариант. Конечно, можно упереться и сказать "у нас есть утверждённое ТЗ, нам всё по барабану, продолжаем делать как планировали" - но в этом случае просто конкуренты (те из них кто был готов меняться на ходу) выиграют, а проект рискует провалиться.
Вообще, если и сравнивать проекты в IT со строительной отраслью, возможно лучше сравнивать не со строительством, а с проектированием. И вполне можно представить, что в ходе проектирования здания, когда большая часть проекта уже готово, заказчик вдруг выдвигает новые требования: да, возможно часть работы придётся выкинуть и переписать с нуля.
HardlinePeak936
Это называется хаос, анархия, плохая организация и т.д. в зависимости от конкретики :)
Бетон есть бетон, фундамент есть фундамент, дом есть дом. Без первого не сделать второе, без второго третьего. А уж какой там конкретно бетон и от какого производителя, какие строители, размеры и вид фундамента, какой дом... Ну, вы поняли — определят архитектора, проектировщики и прочие важные, причём сразу либо будут переделывать.
P.s. По картинке в начале статьи: она отбивает всякое желание работать с Agile, ведь судя по ней, тот требует поиска, изобретения и проектирования для каждого этапа по отдельности и с нарастающей сложностью (помимо реализации!). Согласитесь, проще спроектировать лишь автомобиль, чем скейтборд, самокат, мотоцикл и т.д., когда нужен лишь автомобиль. Да и не факт, что сможешь — там значительная разница в знаниях, технологиях и подходах ;)
navferty
Картинка действительно не очень удачная, потому что иллюстрирует реалии разработки софта на примере создания материальных продуктов, причём достаточно сложных. Для полноты аналогии следовало бы уточнить, что когда мы на первом шаге отдаём пользователю наспех сделанный самокат, есть шанс услышать "ой не, нам же нужно чтобы он держался на воде" или "а мы же хотели на нём летать". И в условиях неопределённости, сделать самокат и выкинуть его на второй итерации - всё же дешевле, чем полгода строить машину, только для того чтобы осознать что заказчик хотел совсем другое.
Так никто не спорит, что при строительстве настоящего дома, есть вполне устоявшиеся практики, и обычно ещё до начала строительства есть план, который не теряет актуальности в течение всего этого строительства (пусть и с некоторыми корректировками). Мой комментарий был как раз в том, что эта аналогия никак не подходит для IT проектов.
Ну что ж, проекты разные бывают, в том числе и в IT. От крупных многолетних проектов со стабильными требованиями до стартапов, где концепция может меняться очень резко. Для Вас - "хаос, анархия ", для кого-то - свобода. Изменчивость требований - необязательно плохая организация (хотя иногда это так), это может быть просто спецификой конкретной отрасли.
ValeryGL
Картинка была нарисована для объяснения "как неправильно понимать MVP" и потом завирусилась одна, без правильной третьей строки
JBFW
Это только так кажется )
Проектирование:
- для собачьей конуры достаточно пешей доступности - но уже надо учитывать инсоляцию (нагрев на солнце конуры) и ветра (чтобы не замерзла)
- для курятника - уже нужна транспортная (тачка с комбикормом должна проехать)
- для дома - коммуникации, водопровод, водоотведение
- для многоэтажки - парковочные площади, выезд на дороги со двора
И если заказчку выкатить проект "курятник на обрыве у реки", а он такой "мне понравилось, давайте переделаем под торговый центр!" - то будет нехорошо в итоге.
Cordekk Автор
Ну в строительстве и такое бывает, однако исполнители там как-то ответственнее относятся и просто сносят изначально построенное целиком.
В IT бывает, что не сносят
Dimly
Мозг человека вырабатывает дофамин при достижении целей или получении информации. В век смартфонов когда ты бездумно листаешь ленту - ты просто стал дофаминовым наркоманом, и теперь неспособен получить (дождаться) удовольствия от реализации длительного проекта. Ну если бумеры еще помнят тот катарсис от качественно сделанного монолита, то зумеры теряют интерес и эффективность - им никак без декомпозиции и MVP. Был такой фантастический рассказ классика - в будущем люди перестали ценить длинные музыкальные композиции и писали только джинглы, 5-10 секундные, типа для рекламы. Их напевали, под них танцевали. Туда и движемся.
Cordekk Автор
Основная мысль почему в IT не так, заключается в сравнении стоимости проектирования и создания итогового продукта.
В строительстве из-за высокой материалоемкости, создание готового продукта гораздо выше стоимости проекта. Поэтому дешевле сначала подготовить нормальный проект, а потом по нему строить. Но это не значит, что нет примеров, когда сначала построили конуру, а потом уже пристраивают к ней дом побольше.
В программной разработке стоимость проектирования будет не ниже, чем сама разработка, а в некоторых случаях без какого-то прототипа очень сложно определиться с проектом дальнейшего развития. В итоге это и выливается в то, что мы видим сейчас.
Cordekk Автор
об этом можно отдельную статью писать
navferty
Согласен с Вашей позицией. Пинганите, если напишете такую статью, будет интересно почитать.
ValeryGL
Хороший пример про эджайл и строительство : https://nbabaeva.medium.com/как-объяснить-дедушке-эджайл-и-скрам-за-5-минут-без-картинок-и-самому-лучше-понять-139ba51b5230
Эджайл скорее не про заложить фундамент под бытовку, а потом передумать и построить три этажа. Скорее так: построить бытовку под самую большую потребность, осмотреться, строить дальше по комнатам по мере того, как выявляются новые задачи. Если комнату пристроили, а оказалась не нужна - демонтировать или перестраивать. Да, итог будет не оптимальный с точки зрения архитектуры (а значит и удобства и надежности и масштабируемости). Но первые жильцы заедут максимально быстро. И построены будут только те комнаты, которые реально нужны (а в частных домах часто проектируют и строят неиспользуемые вещи типа балконов, бильярдных и тд).
JBFW
Опять выдуманный теоретический пример, как тот сферический конь в вакууме )
Практика строительства немного отличается ..
Cordekk Автор
По ссылке у меня ничего не загрузилось.
Но в целом, в деревнях и пригородах домов, которые достраивали и перестраивали, много.
Особенно это заметно в частном секторе в черте города.
JBFW
Ну да, а потом изба стоит на ленте, кухня пристроена к ней и стоит на кирпичах, зимой-летом это всё гуляет, рвет обои и дует в щели, просто хозяева уже приноровились и внимания не обращают.
Вот и с программами так же: иногда бывает кто-то начинает ругаться, что сайт кривой или там приложение работает хз как - а я смотрю и понимаю почему так получилось: связали А и Б вместе изолентой, поэтому когда нажимаешь на кнопку здесь - падает там, нужно просто привыкнуть и не нажимать...
Cordekk Автор
Да, с программами так же