Прощаемся с Agile

Размышление о том, почему Agile всегда был туманно определённой идеологией, решавшей проблемы, уже решённые серьёзными инженерами ещё в 1970-х, и почему появление LLM вернуло нас к разработке по спецификациям — тому самому подходу, который Agile когда-то отверг.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Прощаемся с Agile

Saying Goodbye to Agile Автор: Lewis Campbell Оригинальный текст:

14 апреля 2026

Покойся с миром, Agile, мы едва тебя знали.

И я говорю это буквально — потому что никто так и не понял, чем же он был.

Agile накрыл нашу индустрию как цунами. Но стоило только подвергнуть его сомнению, как некий голос (возможно, доносящийся из разрыва в облаках?) неизменно сообщал нам: «ах, но это же не Настоящий Agile — в Манифесте ни слова не сказано ни о Ежедневных Стендапах, ни об Agile-коучах». Однако, если прочитать сам Agile-манифест (2001) — этот первоисточник нашей просвещённой Новой Эры Программного Обеспечения, — то обнаруживалось, что на самом деле он нам почти ничего и не говорит. В лучшем случае это была череда расплывчатых банальностей («Сотрудничество с заказчиком важнее согласования условий контракта»), а в худшем — коммерчески нежизнеспособных тезисов («Приветствуйте изменения требований даже на поздних стадиях разработки»).

Так что если Agile-индустрия делала Agile Неправильно, а сам манифест был почти лишён смысла, то чем же он был на самом деле?

«Призрак бродит по Software — призрак Waterfall»

Agile всегда определялся прежде всего через то, чем он не является — а не являлся он Waterfall. Если вы не делаете Agile, то вы делаете Waterfall, а Waterfall Не Работал.

Вот только о том, что Waterfall не работает, мы знали ещё с 1970 года; и Уинстон У. Ройс детально объяснил, почему, рекомендуя вместо этого:

• Начинать с проектирования программы.
• Создавать прототип программы, чтобы собрать информацию для уточнения требований.
• Вовлекать заказчика («вовлечение должно быть формальным, глубоким и непрерывным»).

Всё это впоследствии было объявлено инновациями Agile. На самом деле всё это было написано через год после высадки на Луну.1

И даже в том десятилетии это была не единственная работа, уходящая от Waterfall. Статья Белла и Тайера 1976 года, в которой впервые и был введён термин «Waterfall»2, в конце эмпирического исследования сообщает:

Так что очевидно: итеративная разработка не была чем-то новым и продолжала совершенствоваться в десятилетия, предшествовавшие Agile3. Waterfall не был последним словом техники, пока Манифест нас не освободил. И никто из серьёзных людей не сомневался в эффективности требований и спецификаций.

Spec-Driven Development (разработка на основе спецификаций)

К добру это или к худу, доступность дешёвых LLM, обученных на огромных массивах программного кода, изменила то, как многие из нас программируют компьютеры, и, можно утверждать, сместила сам дух времени в разработке ПО.

Одно из однозначно положительных последствий — то, что специалисты по ПО снова пишут спецификации. LLM — как и многие из нас — плохо справляются с неоднозначностью, и точная формулировка задач оказывается эффективным инструментом для генерации корректного кода. Agile говорил нам: «Работающий продукт важнее исчерпывающей документации». Spec-Driven Development говорит нам: «Исчерпывающая документация создаёт работающий продукт». И на самом деле, с LLM или без них, нет ничего нового под солнцем. Цитируя Ройса:

Читая тексты 1970 и 1976 годов, приходится задаться вопросом: что же такого нам действительно принёс 2001-й? Agile был определён расплывчато и продавался как решение того, что уже было решено полвека назад серьёзными инженерами, чьи статьи были куда осмысленнее. По мере того как наша область продолжает меняться — и, как мы надеемся, эволюционировать, — пришло время взглянуть на вещи свежим взглядом и отправить Agile на свалку истории, где ему и место.

Сноски

1. Остаётся только гадать, как же программисты Apollo Guidance Computer смогли совершить такой подвиг, программируя без Story Points и не зная, что «Постоянное внимание к техническому совершенству и качественному проектированию повышает гибкость». ↩
2. Употреблённый, разумеется, в качестве примера того, как делать не надо. ↩
3. Мне очень хотелось втиснуть сюда пару отсылок к «No Silver Bullet» Фреда Брукса, но я стараюсь держать эти посты короткими. У меня также в списке чтения Spiral Model Боэма. ↩

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot