В последние десятилетия ИТ-индустрия живет в парадигме «победившего 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).
Серьезные системы по-прежнему разрабатываются серьезными специалистами, которые используют нисходящее проектирование и системную инженерию. Они работают «как надо» именно потому, что игнорируют «гибкие» догмы.
ссылка на оригинал статьи https://habr.com/ru/articles/1052658/