А где в манифесте сказано, что сразу надо в продакшн ставить.
Это рассуждение десятилетней давности когда говорили, что Agile и большие проекты несовместимы.
Смею утверждать, что это неверно.
Более того взаимодействие людей должно быть важнее процессов. Хороший пример это недавняя ошибка в ПО Боинг.
Аналитик написал в ТЗ, что нужно использовать один датчик. Разработчики написали код, тестировщики протестировали. Все молодцы. 2 самолёта упало и миллиардные потери.
@ASoloschak в данном случае речь не про размер проекта, а про цену ошибки. Вы с 12ю принципами Agile знакомы? Они неотъемлемая часть Agile - манифеста. А там написано :
"Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев" - это как раз про итеративность поставки результата.
Это раз.
И ещё : "Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения" - то есть ценность во главе угла. Ценная часть продукта - такая, которой заказчик может пользоваться. Очевидно, что если пользоваться не сможет, то и ценности нет.
И наконец :
"Работающий продукт —основной показатель прогресса." - в ситуации _строительства_ АЭС как раз это и не получается. На этапе проектирования - да, и есть кейс Росатома, где они по Agile проектируют, а раз в итерацию эксперт в очках виртуальный реальности "ходит " по разработаной части проекта и показывает на ошибки.
Но в строительстве АЭС невозможно протестировать, до начала пуско-наладочных работ.