Сегодня как то гуляя по просторам интернета задался вопросом.

Согласно методике Agile -> Scrum  необходимо итерациями получать требования от заказчика, в том числе и после показания временного решения. В том числе что то изменять в уже существующем коде.

Однако с другой стороны считается, что если что то приходиться изменять в текущем коде, то это обходиться намного дороже, чем если бы изначально аналитик составил описание.  (то есть фаза исправлений на этапе анализа стоит дешевле, чем фаза исправлений на этапе разработки).

При этом, если идет такой "поток задач", то откуда берется зафиксированная конечная архитектура решения и как можно гарантировать что:
1) Себестоимость проекта не "съедает"  маржу
2) Система выполнена качественно, а не в виде "нагроможденных" блоков программы
3) Что заказчик, принимая работы согласиться под свою ответсвенность подписаться под ТЗ (или тем документом, который описывал систему), которе будет неактуально на конец работ ?


Вот, хотелось бы понять

Никак нельзя это гарантировать. Поэтому Agile и рекомендуется к использованию только опытным и слаженным командам.

Согласно методике Agile -> Scrum  необходимо итерациями получать требования от заказчика, в том числе и после показания временного решения. В том числе что то изменять в уже существующем коде.

Это неправда сразу по нескольким пунктам.
1. Scrum  это постулирует, Agile - нет.
2. RUP, MSF и водопад постулирует порционное итерационное поступление требований.
Принципиальное отличие состоит в распределении весов этих поступлений в зависимости от времени.

При этом, если идет такой "поток задач", то откуда берется зафиксированная конечная архитектура решения и как можно гарантировать что:
1) Себестоимость проекта не "съедает"  маржу
2) Система выполнена качественно, а не в виде "нагроможденных" блоков программы
3) Что заказчик, принимая работы согласиться под свою ответсвенность подписаться под ТЗ (или тем документом, который описывал систему), которе будет неактуально на конец работ ?

Никак нельзя. Если делать по Scrum  что-то более-менее приличное по размеру, ну хотя бы юзкейсов на 500, то результат скорее всего окажется "несколько неожиданным". При этом Scrum  будет неплохо подходить для поддержки подобной системы, при условии, что разрабатывали его по более пригодному для таких систем ЖЦ. И то через несколько лет Scrum-а даже при гениальной начальной архитектуре и дизайне получится нечто не очень потребное. Но к этому времени, к счастью система устареет и ее будет логично просто заменить.

Поэтому Agile и рекомендуется к использованию только опытным и слаженным командам.

Это неправда сразу по нескольким пунктам.
1. Как утверждают продавцы гербалайфа "консультанты" их SCRUM всегда лучше.
2. Agile всего лишь утверждает, что люди важнее процессов. Т.е. люди там могут быть разной опытности.
3. RUP так же "рекомендуется к использованию только опытным и слаженным командам."

В основе RUP лежат следующие принципы:

    * Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
    * Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
    * Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
    * Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
    * Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
    * Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Я правильно понял, что Agile больше подходить для маленьких и иногда средних проектов (по сложности системы)?

Я правильно понял, что Agile больше подходить для маленьких и иногда средних проектов (по сложности системы)?

Нет, неправильно.

Scrum действительно больше подходить для маленьких  (до десяти человеко лет) и почти никогда не подходит для средних проектов.
Что касается сложных, то непонятно как мерить... Пожалуй, что не стоит применять Scrum для разработки встроенного ПО. Банковских систем. Систем критичных к разделению прав. И т.д.
Agile же вообще вполне может использовать полный набор артефактов и ролей из RUP. И не перестанет при этом быть Agile. Также никто не мешает разрабатывать одновременно по ГОСТ и Agile. В том числе и очень сложные и очень большие системы.