(三)實踐迭代
在了解了分階段開發軟件的基本思路之后，緊接著就需要考慮實施的問題。分階段開發最難的，并不是在過程的控制上，而是在軟件設計能力上。
應用迭代的問題
有一則故事說的是一個人肚子疼，去看醫生，醫生給他開了眼藥，理由是眼神不好，吃錯了東西，所以才會肚子疼。軟件開發中出現的問題往往不是單純的問題，頭疼醫頭，腳疼醫腳的做法未必適合于軟件開發。
應用迭代并不是一件簡單的事情，懂得了迭代和增量的概念，并不等于你能夠用好它們。為什么這么說呢？很多的軟件組織嘗試著運用迭代開發，但是結果卻不盡人意，于是將問題怪罪在迭代的方法不切實際上。軟件工程中有句著名的話?quot;沒有銀彈"。迭代和增量也不是什么銀彈。要想做好迭代，缺乏優秀的軟件設計思想和高明的軟件設計師的支持是不行的。在XP中，非常強調各項實踐的互為補充。在我看來，迭代能夠順利實行的思路需要重構、測試優先、持續集成等的直接支持。而這些實踐，體現了軟件設計和軟件過程中的關系。
迭代實踐出現問題往往是在項目的中期。這個時候，軟件的主體已經形成，代碼的增長速度也處于一個快速增長的情況。這種狀態下的軟件開發對變化的需求是最沒有抵抗力的，尤其是那些設計本身存在問題的軟件。軟件開發到這個階段，代碼往往比較混亂，缺乏一條主線或是基礎的架構。這時候，需求的變化，或是新增的需求導致的成本直線上升，項目進度立刻變得難以預期，開發人員的士氣受到影響。
迭代之外的解決方法
在這個時候，軟件組織要做的，并不是在迭代這個問題上深究下去，而是應當從軟件設計入手，找到一種能夠適應變化的軟件設計思路或方法。例如，你是否應該考慮在面向對象領域做一些研究呢？面向對象的思路很注重將變化的內容和不變的內容相區分，以便支持未來的變化和應對不確定性。然后你再來考慮相應的成本。
做好迭代有幾個值得注意的地方：
代碼設計優化
軟件開發的能力并不體現為代碼量的多少，而是體現為代碼實現的功能，代碼的可擴展性、可理解性上。所以對代碼進行不斷的改進，對設計進行不斷的改進（具體的次數根據需要而定），使軟件的結構比較穩定，并能夠支持變化。這是迭代的一個前提。否則，每一次的迭代都花費大量的精力來對原先的設計進行修改，對代碼進行優化，這樣的迭代效率是不高的，也可以視為一種浪費。堅持不斷改進軟件質量的做法其實是將軟件的集中維護、改進的成本分攤到整個過程中，這種思路，和全面質量管理的思路是非常類似的。XP中的重構實踐有一個修飾詞，稱為無情。這充分表現了XP的異類，但是應該承認，只有設計和代碼的質量上去了，才能夠為后續的迭代過程打下一個基礎，更何況，XP所處的往往是一個不確定的、變化多端的環境。正是因為這種環境對軟件開發有著很大的影響，因此代碼質量也被高度的重視。不同的行業，不同的項目，需要根據自己的特征進行調整，但是，只有保證代碼的優美性，才能夠順利地達成迭代的目標。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
