Репликант2 Mik Prokoshin:
Насчет XP - как раз ситуация с точностью до наоборот ! Он ориентирован именно на динамически развивающиеся проекты. Его можно использовать и при полностью определенном ТЗ, применяя только к кодированию, но более ощутима выгода именно тогда, когда начиная проект, можешь только догадываться - что тебя ждет впереди.

Откуда такая информация/мнение? XP в отличие от формального RUP работает без всяких спецификаций требований (видение, UCS, SRS и т.п) или в условиях когда требования не определены, т.к в XP: а) постоянно присутствующий заказчик-пользователь (on-site customer), б) быстрое прототипирование и дизайн (если использовать терминологию RUP)

Основные идеи, которые меня заставляют так думать - это рефакторинг и требование реализовывать минимально необходимый функционал (хотя никто не мешает использовать эти практики при других процессах).
а) в большинстве случаев изменения ТЗ носят характер уточнений изначально не выявленных проблемных участков. В этом случае, как правило, данные моменты очень сильно помогают, т.к. происходит "плавное" изменение кода применительно к измененным условиям. Обычно очень часто оптимизация ТЗ и кода буквально сливается в единый процесс и дает эффективно тот результат, которого хотелось добиться (вопрос "когда останавливаться при такой оптимизации" - отдельный);
б) при кардинальном изменении части ТЗ (смена условий хозяйствования и т.д.) мы можем быть более уверенными, что имеем легко модифицируемый, не слишком сильно связанный код без больших кусков, реализованных "на всякий случай" и отправляемых в корзину, что улучшает условия изменений.

В качестве минуса XP на "живых" системах, конечно же, следует рассматривать "дополнительную" работу по исправлению автоматических тестов. Но тут соотношение эффективности автоматического/ручного тестирования все равно будет зависеть от конкретных условий/людей ведущих проект.

Главное, что IMHO XP подход позволяет постоянно иметь весь код "близкий к оптимальному" (этот термин мне обсуждать не хотелось бы - долгая это песня, да и у каждого свои критерии), а не "заплатки", как это более вероятно при других процессах.

Репликант Основные идеи, которые меня заставляют так думать - это рефакторинг ..

А как связаны объем рефакторинга и ТЗ? При наличии ТЗ (т.е это требования, например, функциональные, а не архитектура) рефакторинг также может применяться. Вопрос в объеме рефакторинга, т.е в XP он является важнейшей деятельностью, улучшающей качество архитектуры и кода. В RUP он также может использоваться, но в RUP есть проектировщик и модель архитектуры , к-рую по идее проще улучшать в CASE-средстве, чем рефакторить (с тестированием); программист в RUP тем более может рефакторить код по своему усмотрению, а также влиять на архитектуру, но в гораздо меньшей степени, чем в XP
Как связаны - было рассказано в след. абзацах. Модель архитектуры Вы в CASE средстве измените, но разница может cказаться в объеме изменений. Рефакторенные код/архитектура есть наиболее гибкие/легко изменяемые, как показывает мне мой опыт.

Репликант .. и требование реализовывать минимально необходимый функционал (хотя никто не мешает использовать эти практики при других процессах).
"требование реализовывать минимально необходимый функционал" - что именно имеется в виду?
А какие здесь варианты ? Имеется в виду, то, что в RUP не регламентировано оставление кусков старого кода (скорее есть некая тенденция к минимальным изменениям), а вот XP обязывает оставить только необходимый минимум, старые куски вычистить, с учетом всего этого отрефакторить код/архитектуру.

Репликант б) при кардинальном изменении части ТЗ (смена условий хозяйствования и т.д.) мы можем быть более уверенными, что имеем легко модифицируемый, не слишком сильно связанный код без больших кусков, реализованных "на всякий случай" и отправляемых в корзину, что улучшает условия изменений.
"слишком сильно связанный" - что именно имеется в виду? "реализованных "на всякий случай" - если имеется в виду функциональность про запас, то в RUP ничего такого нет, а в XP это вообще как бы запрещается
Я должен объяснzть что есть связанность кода (объектов, модулей и т.д.) ? Она часто увеличивается вследствие практики "заплаток". А по поводу "в RUP ничего такого нет" - те, кто ему следует, как правило придерживаются методики "минимальные изменения", что может вредить делу. XP указывает явно на необходимость полного рефакторинга.

Репликант Главное, что IMHO XP подход позволяет постоянно иметь весь код "близкий к оптимальному" (этот термин мне обсуждать не хотелось бы - долгая это песня, да и у каждого свои критерии), а не "заплатки", как это более вероятно при других процессах.
Действительно, если термин нельзя определить, то лучше его не обсуждать, т.к обсуждать просто нечего :o) А что плохого в "заплатках", если они выполнены грамотно, т.е не разрушают архитектурную целостность, качество и т.п?
Плохого то, что чем больше заплаток, тем сложнее разбираться другим программистам, имеющим дело с этим кодом, сложнее его модифицировать в дальнейшем и т.д. Т.е. кол-во "заплаток" растет, пока не превысит некоторого порога, после которого проще выбросить весь кусок и переписать заново. XP позволяет сгладить этот процесс.