從瀑布型開發到迭代型開發的轉變

　　簡介： 本文來自 Rational Edge ：一個理想的迭代開發方法模型在很多方面與理想的瀑布開發模型有著根本上的不同。但是，從實際來說，沒有一個團隊嚴格的應用了每一種開發方法模型。本文解釋了為什么開發團隊決定逐步的從類似瀑布型的開發方法轉變成更加類似迭代開發的方法，同時也概述了能夠幫助這種轉變的步驟。

　　多數的軟件開發團隊仍然在開發項目中使用瀑布型 的開發過程。采用極端的瀑布型開發方法意味著你要以嚴格的順序來完成一系列的項目階段：需求分析、設計、實現/集成然后是測試。當項目中出現的問題解是困難的并且解決問題是昂貴時，你可能會推遲測試直到項目周期的末端;這些問題也能夠嚴重的威脅軟件發布的期限并且使主要的團隊成員在某些開發環節上是空閑的。

　　實際上，多數的開發團隊使用了改進了的 瀑布型開發方法，他們將項目分解成為兩個或者更多的部分，有時這些部分被稱為階段或者是時期。這種改良可以幫助簡化集成、使測試人員更早的進行測試工作和提供更早的項目狀態的觀測。這種方法也將代碼分解成了易于管理的片斷并最小化了以存根和驅動程序形式的、被測試需要的代碼集成。此外這種方法允許你原型化你認為有風險的或者有難度的部分，并且使用來自每一個階段的反饋修改你的設計。然而，使用瀑布型開發方法的執行與想象是相反的：很多設計團隊把在階段 1 之后的修改設計視為他們的最初設計或者需求過程的失敗。雖然一個改進了的瀑布型開發方法并不排除反饋的使用，但是它并沒有促進、支持和鼓勵反饋的使用。最后，想要最小化風險就不要典型的驅動一個瀑布型的開發項目。對于軟件開發過程來說，本文探索了”迭代“開發方法超越傳統的瀑布型開發方法的進步。

　　迭代開發的好處

　　相比較而言，迭代開發方法 — 以 IBM 的 Rational 統一過程 ®，或者 RUP ®為例— 包括了一系列的增量的步驟或者迭代。每一個迭代都包括一些或者很多的開發活動(需求、分析、設計、實現等等)，就像你在圖 1 中看到的那樣。每一個迭代也有一系列良好定義的目標并生成最終系統的部分工作實現。每個后續的迭代都建立在前一個迭代的基礎上以使系統得到發展和細化，直到最終產品被完成。

　　早期的迭代著重于需求、分析和設計;后期的迭代著重于實現和測試。

　　圖 1: RUP 的迭代開發。每一個迭代都包括需求、分析、設計、實現和測試活動。同時，每個迭代都建立在前一個迭代工作的基礎上，每一次迭代都會生成更加接近最終產品的可執行版本。

　　迭代開發方法已經證明了自己優于瀑布型的開發方法，理由如下：

　　它允許需求的變化。需求的變化和“進一步的蔓延” — 技術和客戶驅動的特性的累加 — 一直是項目中導致麻煩、延期交付、令客戶不滿意和使開發人員泄氣的主要原因。為了解決這些問題，使用迭代開發方法的團隊應該在項目開發的幾周里就關注生成和演示可執行的軟件，這樣就強制了需求的檢查并可以幫助減少需求從而反映系統的本質。

　　集成不是在項目的尾聲進行的“大動作”。將系統的集成留到項目的結尾幾乎總是會導致耗時的返工 — 有時這種返工會花費整個項目工作量的百分之四十的時間。為了避免這種返工，每一次迭代都以集成構建系統各部分結束;這樣不斷的積累將最小化日后的返工。

　　早期的迭代可以暴露風險。迭代的開發方法可以幫助團隊在早期的迭代中減少風險，因為在這些迭代中包括了對所有過程組件的測試。當早期的迭代覆蓋了項目的很多方面時 — 工具、購買的軟件和團隊成員的技能等等 — 團隊能夠很快的發現被預感的風險是否是真實的，并且能夠在問題相對容易并花費很少成本解決時揭示沒有被發現的新的風險。

　　對產品的管理能夠采取戰術性的變化。迭代開發能夠快速的生成可執行的架構(雖然功能有限)，這個架構能夠為了應對競爭對手的快速版本發布容易的調整產品使之成為”輕量級的“或者“改進的”版本。

　　它使重用更加容易。識別在迭代中進行的部分設計和實現的公用部分要比在計劃期間找出公用部分更加容易。在早期開發中的設計評審允許架構師們發現潛在的可重用的機會，并且利用這個機會為接下來的迭代開發成熟的公用代碼。

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-iterative/