Тут наверно такое разделение даже в части Космоса, что когда чертежи Протона уже известны, и надо просто его серийно производить, это водопад. Но прежде, чем эти чертежи появились, это был эджайл. Потому что математический и вычислительный аппарат не позволял с адекватной точностью просчитать его поведение. Приходилось рисковать.

да откуда там аджайл? нормальный ниокр был, с кучей документации

про космос:

НЕТ: Люди и взаимодействие важнее процессов и инструментов.
НЕТ: Работающий продукт важнее исчерпывающей документации.
НЕТ: Сотрудничество с клиентом важнее согласования условий контракта.

Если система в целом понятна, но надо разобраться с 10%, это похоже на НИОКР. Но когда весь проект — один сплошной НИОКР, успешное завершение которого собственно совпадает с окончанием проекта, это и есть agile.

Выше было про TOGAF для 1С. Вот это agile для разработки клиентоориентированного продукта. Но agile позволяет ставить и другие цели. В том числе долететь до Луны, и 11 релиз таки долетает.

Довелось мне посетить музей авиационных двигателей в Гатчине.
Была очень интересная экскурсия, которую вел старичок такой что еле душа держится, зато живой участник еще въетнамской кампании.
Рассказывал историю становления отечественного двигателестроения, начиная с копипасты двигателей роллс-ройс.

В частности он сказал что как таковой модели истребителя Миг-29 не существует, это серия машин, каждая из которых уникальна.
Каждая машина постоянно дорабатывалась по результатам боевых вылетов.
Каждый новый экземпляр с доработками на основе анализа опыта боевых вылетов.

Но вряд ли они после каждого вылета радикально меняли конструкцию. Это скорее малые улучшения, нормальная часть эксплуатации, не противоречащая водопаду

Пардон, таки опечатался

На тему аджайла: мы таки идем по пути bimodal it,
делайте по аджайлу ваш фронтенд, для него он отлично подходит.

Изменения в ядре системы, транзакционной платформе, затрагивающие базовые бизнес-процессы, давайте-как делайте как следует, с проектирвоанием, тестированием, все как положено.

Ошибка в транзакционной платформе может привести к остановке бизнеса.
Ошибки на фронтенде это лишь временные неприятности.

итеративная доработка с анализом результатов итераций это основа любой инженерной и научной деятельности,
дихотомию ватерфолл-аджайл придумали менеджеры

В эджайле тестирование тоже есть, и документирование тоже есть. Херак-херак-впродакшн к эджайлу не имеет отношения.

но почему-то очень популярно в аджайл проектах, что дискредитирует аджал в глазах инженеров. никому ведь не хочется работать по уши в г-не

Потому что хороший аджайл дороже хорошего водопада, но не все оказываются к этому морально-финансово готовы.

В эджайле риски снижаются по масштабу, но вырастают по эскалации, повороты стоят дороже, потому что они осуществляются не на этапе обследования, а на этапе разработки.

Это, конечно, немного не про архитектуру, но имеет к ней отношение, так как вот вы правильно выделили: бухгалтерские операции строго регламентированы, там рекомендации и регламенты ЦБ и ФНС можно прям в первую версию ЧТЗ кидать и вперёд, и там именно водопад. Равно как и в микросервисах есть сервисы вроде matching engine, которые тоже водопад (как ни странно тоже рядом с деньгами). А есть в том числе морда, которую пока не потрогаешь, не узнаешь, и конечно морду, за ней API, а за ним read model развивается по agile.

То есть нарезка идёт по предметным областям и по методологии разработки, которые как и средства реализации для разных сервисов могут быть разные.

Воистину так.
Только вот незрелые умы некоторых руководителей до сих пор верят что аджайл это про дёшево и быстро.

Скупой платит дважды. А в прогинге трижды: с начала за аджайл, потом за водопад, потом за аджайл, но уже нормальный.

Водопад спасает то, что он рагламентирован в усмерть, и методология почти не меняется. Аджайл же очень многое даёт на откуп принимающим ситуативные решения, полагаясь на их здравую оценку. Чтобы делать хороший эджайл, его должны понимать как у исполнителя, так и у заказчика.

Уже на ВДНХ