當一個由敏捷過程開發的大型系統需要突然發生大規模變化而影響大多數情況時，使用敏捷技術的最佳途徑是什麼？這個迭代部分是否改變了？敏捷開發實踐如何受到普遍系統變化的影響？
例如，如果決定使中央系統成爲分佈式系統呢？或者選擇另一個大型普遍的例子。
應該說已經有了很大的改變，但它永遠不是一個完美的世界，這也是敏捷存在的原因之一，所以假設突然間引入了一個重大變化來震動基礎。
編輯總結解決方案：
「這個迭代部分是否改變了？」
從來沒有。
無論多麼「普遍」，改變似乎是，你仍然必須在迭代中增量工作，你可以管理。
您仍然需要優先考慮這些更改，並以繼續通過單元測試的方式進行更改，並且可以在需要時進行發佈。
例如，您可能會發現修復80％的系統是足夠的，您可能會釋放。或者可能需要在發佈之前修復100％的系統。
你還在增量工作。在衝刺。不管你何時發佈。
+1所有大規模更改只是一系列變相的小規模更改。此外，從空文本文件創建項目的時間不是最大的變化嗎？ – slebetman 2010-01-25 21:47:42
敏捷的*整點*是爲了適應變化。如果你在適應變化時立即拋棄敏捷，那麼你正在做一些非常錯誤的事情。 （OTOH，讓我們不要忘記，適應開發過程*本身*改變*就是敏捷。） – 2010-01-25 22:44:50
kindda。 從一輛汽車出發，變身爲一架飛機將會從另一件事中獲得完全不同的東西，從0開始，然後變形爲一架飛機。 當架構與原始架構截然不同時，您需要非常仔細地考慮如何更改。 – 2010-01-25 22:47:45
敏捷沒有神奇的答案。
有許多方法： -
情節的合理增量變化的路徑，該系統從一個杜彥武改變到另一個。如果你有合理的代碼，那麼你應該拋棄那些由於變更而變得多餘的代碼，並保持獨立於變更的東西。
如果事情真的不同，另一種方法是開始新系統組件的並行開發。
或者，從舊項目中儘可能多地開始新的和偷竊。
取決於BIG的變化真的是。
假設 - 像這樣 - 幾乎不可能回答。我們可以假設有太多的事情可以拒絕，因爲它們不屬於你的假設。 「選擇另一個大型普遍的例子」允許我們定義任何我們想要的「大」和「普遍」，我們的定義都不可能與您的定義相匹配。重點和細節幫助。 – 2010-01-25 20:56:16
不幸的是，我關注的是敏捷過程以及它的使用方式，即使答案必須提供一些自己的上下文，總會有一般性答案。我現在沒有一個具體的例子，但是當我這麼做的時候，我很欣賞這種洞察力。 – 2010-01-25 21:05:52
它是軟件的增量創建。但有時它不是對原始軟件的增量更改，而是增量創建新體系結構，然後插入舊系統的所有功能。 – 2010-01-25 22:50:41