В последние десятилетия ИТ-индустрия живет в парадигме «победившего Agile». Любое сомнение в его эффективности клеймится как приверженность «устаревшему водопаду». Однако при более глубоком анализе выясняется, что Agile — это не эволюция управления, а искусная маркетинговая надстройка, которая борется с вымышленными врагами и подменяет системное проектирование ритуальным ремесленничеством.
1. Битва с тенью: миф о «Водопаде»
Главный антагонист Agile — «Водопадная модель» (Waterfall) — в реальности никогда не существовал как общепринятая инженерная практика. Уинстон Ройс в своей статье 1970 года привел линейную схему как пример того, как делать не надо, сразу же предложив итерации и обратную связь.
Все мировые инженерные стандарты до и после Ройса всегда учитывали итерационный характер проектирования. Agile-движение создало «соломенное чучело» — образ неповоротливого линейного процесса — и героически победило его. Эта победа была виртуальной: Agile победил не плохую методологию, а здравый смысл, представив естественную итеративность как свое уникальное изобретение.
2. Адаптивность или «эффект метронома»?
Agile называют адаптивным методом, но это логическая ошибка. Адаптация — это способность системы изменять свое внутреннее устройство или алгоритм поведения при изменении среды. В Agile этого механизма нет.
· Жесткий цикл: Процесс Agile ригиден — это всегда фиксированные спринты и ритуалы. Система не «гнется» под среду, она просто механически повторяет один и тот же такт.
· Дискретизация вместо гибкости: Agile не адаптируется, он лишь увеличивает частоту проверок. Это не адаптивная система, а метроном. Если команда движется к катастрофе, в Agile она просто будет биться о стену чаще (каждые две недели), но сам механизм движения остается неизменным.
2. Антагонизм к проектированию: смерть «сверху вниз»
Agile является прямым антагонистом классического нисходящего проектирования (Top-Down Design). Вместо того чтобы сначала спроектировать систему в целом, обеспечив её концептуальную целостность (как завещал Фредерик Брукс), Agile навязывает «возникающую архитектуру» (emergent design).
На практике это означает отказ от архитектурного планирования в пользу «лоскутного» наращивания функционала. Система превращается не в здание, построенное по чертежу, а в фавелу, где новые комнаты пристраиваются к старым без учета фундамента. Это не «быстрая разработка», а накопление технического долга, который со временем делает любые изменения запредельно дорогими.
3. Отказ от управления в пользу рефлексии
Agile — это не управление в прямом смысле слова, так как в нем отсутствует фундаментальная категория — план. Классическое управление проактивно: оно строит траекторию к цели. Agile же перешел к «рефлексивному управлению» (управлению по раздражителям).
Это работа в режиме «метронома»: спринт — демо — ретроспектива. Если среда меняется, Agile-команда не адаптируется системно, она лишь чаще сверяется с реальностью. Менеджер в такой системе перестает быть «лучшим инженером» и превращается в фасилитатора — секретаря, который следит за соблюдением ритуалов, не неся ответственности за техническую состоятельность продукта.
4. Ложная гибкость
В системной инженерии гибкость — это способность системы переходить между заранее предусмотренными режимами без изменения структуры. Agile же предлагает прямо противоположное: изменение структуры (кода) при каждом изменении требований.
То, что в Agile называют гибкостью, правильнее назвать пластичностью или хрупкостью. Система не «гнется» — её постоянно перелепливают из куска пластилина. В итоге стоимость изменений не снижается, как обещает манифест, а растет экспоненциально, потому что структура системы не была спроектирована как гибкая изначально.
5. Регресс к "лучшим практикам"
Agile относится к эмпирическим методам управления, основа которых — «лучшие практики». Это возврат к донаучному, цеховому ремесленничеству.
Как пекарь в древности случайно добавил дрожжи и передал этот «секрет» ученикам, не понимая химии процесса, так и Agile-коучи передают ритуалы (стендапы, карточки, доски), не понимая физики управления сложными системами.
Инженерия знает, почему это работает (на основе моделей).
Agile знает только, как принято делать (на основе «лучших практик»).
Этот эмпиризм работает на уровне простых веб-приложений («пекарен»), но катастрофически проваливается при создании сложных систем (ОС, СУБД, авиация), где требуется научный расчет и жесткое проектирование, а не метод проб и ошибок.
7. Конец эпохи: волна разочарования
Сегодня мы наблюдаем перелом: количество критических статей от ведущих инженеров и теоретиков (таких как Дэйв Томас) растет лавинообразно. Профессионалы осознают, что:
· Agile не масштабируется на серьезные системы.
· Он создает «архитектурный долг», который невозможно выплатить.
· Он подменяет инженерное мастерство бюрократией фреймворков (типа SAFe).
Серьезные системы по-прежнему разрабатываются серьезными специалистами, которые используют нисходящее проектирование и системную инженерию. Они работают «как надо» именно потому, что игнорируют «гибкие» догмы.
Комментарии (28)
MonkAlex
27.06.2026 15:55Задайте себе вопрос, почему индустрия решила что аджайл хорош. Внезапно окажется, что 90% разработки про какие-нибудь сайты, с разной тематикой, динамикой, сложностью и нагрузкой.
aeder
27.06.2026 15:55Всё очень просто. Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения.
Как только начинается разработка системы для промышленности/индустрии, со сроками жизни разработки измеряемой в десятилетиях - немедленно получается тот же самый "итеративный водопад". Проектирование сверху вниз, начинающееся с концепции, ТЗ, архитектуры, плана работ, описания интерфейсов, и далее - то же самое по каждой из подсистем.
Аджайл идеально подходит, когда разработчики в сотый раз клепают ровно такую же хрень, какой занимались до этого 99 раз. Обычно это какой-нибудь стандартый проект с БД, бизнес-логикой и веб-интерфесом. Тут действительно можно работать без плана и документации, и быстро реагировать на быстроменяющиеся хотелки заказчика.
Dhwtj
27.06.2026 15:55Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения
Забавно. То же самое я слышал про LLM
Anarchon
27.06.2026 15:55Некоторым людям просто нужно выпячивать свои подходы и свою работу, а остальное низводить до "треша". "Аргументы" у них всегда одинаковые будут.
gmanaz192
27.06.2026 15:55Agile придумали в тех коллективах где план как бы мешает самоорганизации сотрудников для разработки программы, но это должен быть очень сплочённый коллектив. В нынешних реалиях Agile больше работает на имидж сотрудников или же создаёт им возможность легально бить баклуши, так как если Agile в коллективе с соответствующим ТЗ нет, то значит с этим коллективом что-то не так как многие по шаблону думают, на самом деле такие коллективы сейчас просто редкость, люди другие и трава не такая зелёная.
Format-X22
27.06.2026 15:55Просто нет серебряной пули.
В стартапе очень важно уметь повернуть в тот момент, когда понял что движешься не туда. Очень часто изначально было одно виденье, сделали прототип, запустили, а оказало что половина бизнес-кейсов совсем иная нужна. Переделали, замерили метриками, поняли что вот тут вообще не перспективно, а это фичу надо развивать, потому что именно она понравилась пользователям. А заранее это нельзя узнать, потому что чтобы узнать - надо сделать и показать. На бумаге одно, а практика - критерий истины.
Оттуда и рождается подход по припиливанию фич сбоку, проверкой гипотез и прочего. Не обязательно что каждые две недели, но достаточно часто нужно менять вектор движения. И уже не раз, не два и не три было доказано что сделать сразу хорошо - это худший из возможных вариантов. А вот когда стартап стабилизировался, бизнес налажен - приходит время сделать как надо. Обычно это переписывание с нуля, иногда на другой стек. И вот тогда приходит время долгосрочного планирования.
Проблема в том что подход стартапов применяют везде, в том числе там где это совсем не нужно или даже критически вредно. Более того - тот же вотерфол, который водопад, это ведь тоже аджайл/скрам, только спринт может длиться 6 месяцев. В аджайле/скраме тоже есть планирование, обычно это созвон, доска с тикетами и прочим. Просто план на 2 недели. А 2 недели потому что так удобно, хотя кто-то делает и месяц. И потом следование четкому плану, иногда с этапами, а в конце ретроспектива. И планирование там есть и хорошее, но для горизонта в 2 недели. Если умножить это время на 20 или на 30 - это же тот же ватерфол. И два часа созвона превращается тогда уже в 60 часов, тогда то и проектирование системы влезает и всё что нужно чтобы поработать ближайшие полгода.
Проблема не в аджайле и скраме, проблема в карго-культе и не правильном выборе кванта времени под конкретный проект. Вот и весь секрет.
GidraVydra
27.06.2026 15:55То, что в Agile называют гибкостью, правильнее назвать пластичностью или хрупкостью.
Сразу видно, что автор не абы кто, а целый ИНЖЕНЕР (произносить строго с придыханием).
Судя по тексту, слово "инженер" и его производные - единственное, что автор знает об инженерном деле, но слово ему это очень нравится, и он решил использовать его как символ своей борьбы за всё хорошее против всего плохого.
UberManager
27.06.2026 15:55во-первых, не путай теплое с мягким - эджайл это принципы, а ты пишешь про скрам (по сути)
Во-вторых, эджайл имеет ограниченное применение: мелкие и квалифицированные команды, которые еще должны быть мотивированы
Спасибо автору за пояснение массам про вотерфолл вначале, красава!
На практике любой проект - гибрид, отличается только баланс предиктива/итератива
Мой опыт показывает: эджайл применим в допиливании внедренного продукта, в дендро-факельном продакшене - последнее не всегда плохо (например: у вас два дня на продукт с нуля в uat)
olegtsvetkov
Agile — это манифест о том, как в динамично меняющемся мире делать реально полезные системы для пользователей, а не пилить сферического коня в вакууме.
В Agile нет спринтов и ритуалов. В нём нет системы контроля и планирования. В нём нет бюрократии и требований к проектированию.
Всё это есть в процессах, которые выстраиваются в командах разработки. Например, SCRUM, который зачастую превращался в SCREAM со всеми описанными пороками.
Но вопрос: это проблема SCRUM или результат работы руководителей этих команд?
В системах, где цена ошибки — это человеческая жизнь (Авиация, АЭС, пр.), нужна соответствующая система контроля качества. Agile или нет не важно.
Менеджер не должен быть «лучшим инженером», как и не должен быть «фасилитатором» — оба состояния вредны. Руководитель должен быть полноценным руководителем (а этому неплохо поучиться, чтобы не способствовать развитию Scream).
«Изменение структуры (кода) при каждом изменении требований» — это маркер, что именно инженерная команда «не понимает физики управления сложными системами». Ведь команда оказалась неспособна понять суть бизнеса компании и спроектировать систему, которая отвечает потребностям компании.
Но в целом, я согласен с идеей, что мы свернули куда-то не туда в разработке, но Agile тут явно не причём.
misha_ruchk0
Зачастую в системах реального времени (Авиация, АЭС, пр.) одним контролем качества не обойдешься. Такая система должна быть изначально целиком правильно спроектированна и затем построена без отклонений от проекта. Слово Agile, лично я, тут даже на горизонте не вижу.
onets
Таки чтобы понять суть бизнеса и спроектировать систему - это разве не этап бизнес-анализа и проектирования (или другими словами первые два этапа waterfall)?
У нас в компании уже 1,5 года скрам, и только сейчас дали 3 дня в конце спринта на анализ задач, которые идут в следующий спринт. 3 дня это на ВСЕ задачи (5-7, порой до 10 штук на программиста). Выделенного бизнес/системного аналитика у нас нет. И если задачи оказываются не готовы - их заменяют другими задачами, на которые уже не остается времени даже на такой минимальный анализ.
olegtsvetkov
Понимание бизнеса не строится на анализе задачек спринта.
Сходите к вашему CEO/продакту/бизнес-лидер/etc и узнайте откуда деньги на весь банкет, кто ваши пользователи/клиенты и что им важно. Может пару custdev проведите сами или в гембу сходите, если есть возможность.
Появление аналитика только усилит все проблемы из статьи. Ведь человек за ЗП мидл разработчика будет должен, как ТОПовый эксперт уметь и в бизнес, и в архитектуру, и в разработку, и в эксплуатацию, и в продукт.
В своё время про всё это хорошо рассказал Филипп Дельгядо ещё в 2021 году — https://habr.com/ru/companies/oleg-bunin/articles/598925/. Рекомендую.
Ну а по «только сейчас дали 3 дня» повторю мысль из моего комментария выше: Возможно вам просто нужен тимлид, который имеет хороший опыт руководителя в ИТ.
onets
Да, да все верно... Анализ то начинается задолго до задачек в спринте. Про три дня - это лайт версия, когда программист читает задачу и задает вопросы product owner и пытается предсказать за сколько
нот он угадает мелодиюsp / hr он сделает эту задачу. На безрыбье и рак рыба.Я ходил в гембу с product owner и у нас была конференция для клиентов и я даже в какой-то мере проводил пресейл (хотя им не являюсь). Только по итогу - один клиент хочет предсказание закупок на склады, и показывает примеры из другого софта, которые, тем не менее, его не устраивают. А другой кучу всего и сверху еще 200 тысяч заказов в день (мы столько не вытянем в данный момент).
С ходу эти задачи не сделать. Не смотря на то, что у меня в голове сразу строится примерный план, как это можно было бы сделать - все равно нужна более детальная аналитика, плотная работа с solution architect, c sales team, да и вообще все это организовать и всех попинать. Тогда и появится шанс превратить это в детальный план, который может привести к тому, что эти два клиента к нам придут.
А должен ли это все делать рядовой, хотя и ведущий, программист?
olegtsvetkov
Должен.
Каждая система — это отражение домена бизнеса и взаимодействия отдельных акторов в нём. Если мы не понимаем домен бизнеса, то не можем оптимально построить систему. Чтобы понять домен — нужно делать всё вышеперечисленное.
Но ИМХО все там будем в любом случае. AI постепенно закрывает самую долгую часть работы разработчика — написание кода. Поэтому постепенно внимание будет перераспределяться до состояния и швец, и жнец, и на дуде игрец (продакт-инженер-дизайнер в терминальной стадии).