本文來自 Rational Edge ：一個理想的迭代開發(fā)方法模型在很多方面與理想的瀑布開發(fā)模型有著根本上的不同。但是，從實際來說，沒有一個團隊嚴格的應用了每一種開發(fā)方法模型。本文解釋了為什么開發(fā)團隊決定逐步的從類似瀑布型的開發(fā)方法轉(zhuǎn)變成更加類似迭代開發(fā)的方法，同時也概述了能夠幫助這種轉(zhuǎn)變的步驟。
多數(shù)的軟件開發(fā)團隊仍然在開發(fā)項目中使用瀑布型 的開發(fā)過程。采用極端的瀑布型開發(fā)方法意味著你要以嚴格的順序來完成一系列的項目階段：需求分析、設計、實現(xiàn)/集成然后是測試。當項目中出現(xiàn)的問題解是困難的并且解決問題是昂貴時，你可能會推遲測試直到項目周期的末端；這些問題也能夠嚴重的威脅軟件發(fā)布的期限并且使主要的團隊成員在某些開發(fā)環(huán)節(jié)上是空閑的。
實際上，多數(shù)的開發(fā)團隊使用了改進了的 瀑布型開發(fā)方法，他們將項目分解成為兩個或者更多的部分，有時這些部分被稱為階段或者是時期。這種改良可以幫助簡化集成、使測試人員更早的進行測試工作和提供更早的項目狀態(tài)的觀測。這種方法也將代碼分解成了易于管理的片斷并最小化了以存根和驅(qū)動程序形式的、被測試需要的代碼集成。此外這種方法允許你原型化你認為有風險的或者有難度的部分，并且使用來自每一個階段的反饋修改你的設計。然而，使用瀑布型開發(fā)方法的執(zhí)行與想象是相反的：很多設計團隊把在階段 1 之后的修改設計視為他們的最初設計或者需求過程的失敗。雖然一個改進了的瀑布型開發(fā)方法并不排除反饋的使用，但是它并沒有促進、支持和鼓勵反饋的使用。最后，想要最小化風險就不要典型的驅(qū)動一個瀑布型的開發(fā)項目。對于軟件開發(fā)過程來說，本文探索了”迭代“開發(fā)方法超越傳統(tǒng)的瀑布型開發(fā)方法的進步。
迭代開發(fā)的好處
相比較而言，迭代開發(fā)方法 — 以 IBM 的 Rational 統(tǒng)一過程 ®，或者 RUP ®為例— 包括了一系列的增量的步驟或者迭代。每一個迭代都包括一些或者很多的開發(fā)活動（需求、分析、設計、實現(xiàn)等等），就像你在圖 1 中看到的那樣。每一個迭代也有一系列良好定義的目標并生成最終系統(tǒng)的部分工作實現(xiàn)。每個后續(xù)的迭代都建立在前一個迭代的基礎上以使系統(tǒng)得到發(fā)展和細化，直到最終產(chǎn)品被完成。
早期的迭代著重于需求、分析和設計；后期的迭代著重于實現(xiàn)和測試。
圖 1: RUP 的迭代開發(fā)。每一個迭代都包括需求、分析、設計、實現(xiàn)和測試活動。同時，每個迭代都建立在前一個迭代工作的基礎上，每一次迭代都會生成更加接近最終產(chǎn)品的可執(zhí)行版本。
迭代開發(fā)方法已經(jīng)證明了自己優(yōu)于瀑布型的開發(fā)方法，理由如下：
它允許需求的變化
需求的變化和“進一步的蔓延” — 技術(shù)和客戶驅(qū)動的特性的累加 — 一直是項目中導致麻煩、延期交付、令客戶不滿意和使開發(fā)人員泄氣的主要原因。為了解決這些問題，使用迭代開發(fā)方法的團隊應該在項目開發(fā)的幾周里就關(guān)注生成和演示可執(zhí)行的軟件，這樣就強制了需求的檢查并可以幫助減少需求從而反映系統(tǒng)的本質(zhì)。
集成不是在項目的尾聲進行的“大動作”
將系統(tǒng)的集成留到項目的結(jié)尾幾乎總是會導致耗時的返工 — 有時這種返工會花費整個項目工作量的百分之四十的時間。為了避免這種返工，每一次迭代都以集成構(gòu)建系統(tǒng)各部分結(jié)束；這樣不斷的積累將最小化日后的返工。
早期的迭代可以暴露風險
迭代的開發(fā)方法可以幫助團隊在早期的迭代中減少風險，因為在這些迭代中包括了對所有過程組件的測試。當早期的迭代覆蓋了項目的很多方面時 — 工具、購買的軟件和團隊成員的技能等等 — 團隊能夠很快的發(fā)現(xiàn)被預感的風險是否是真實的，并且能夠在問題相對容易并花費很少成本解決時揭示沒有被發(fā)現(xiàn)的新的風險。
對產(chǎn)品的管理能夠采取戰(zhàn)術(shù)性的變化
迭代開發(fā)能夠快速的生成可執(zhí)行的架構(gòu)（雖然功能有限），這個架構(gòu)能夠為了應對競爭對手的快速版本發(fā)布容易的調(diào)整產(chǎn)品使之成為”輕量級的“或者“改進的”版本。
多數(shù)的軟件開發(fā)團隊仍然在開發(fā)項目中使用瀑布型 的開發(fā)過程。采用極端的瀑布型開發(fā)方法意味著你要以嚴格的順序來完成一系列的項目階段：需求分析、設計、實現(xiàn)/集成然后是測試。當項目中出現(xiàn)的問題解是困難的并且解決問題是昂貴時，你可能會推遲測試直到項目周期的末端；這些問題也能夠嚴重的威脅軟件發(fā)布的期限并且使主要的團隊成員在某些開發(fā)環(huán)節(jié)上是空閑的。
實際上，多數(shù)的開發(fā)團隊使用了改進了的 瀑布型開發(fā)方法，他們將項目分解成為兩個或者更多的部分，有時這些部分被稱為階段或者是時期。這種改良可以幫助簡化集成、使測試人員更早的進行測試工作和提供更早的項目狀態(tài)的觀測。這種方法也將代碼分解成了易于管理的片斷并最小化了以存根和驅(qū)動程序形式的、被測試需要的代碼集成。此外這種方法允許你原型化你認為有風險的或者有難度的部分，并且使用來自每一個階段的反饋修改你的設計。然而，使用瀑布型開發(fā)方法的執(zhí)行與想象是相反的：很多設計團隊把在階段 1 之后的修改設計視為他們的最初設計或者需求過程的失敗。雖然一個改進了的瀑布型開發(fā)方法并不排除反饋的使用，但是它并沒有促進、支持和鼓勵反饋的使用。最后，想要最小化風險就不要典型的驅(qū)動一個瀑布型的開發(fā)項目。對于軟件開發(fā)過程來說，本文探索了”迭代“開發(fā)方法超越傳統(tǒng)的瀑布型開發(fā)方法的進步。
迭代開發(fā)的好處
相比較而言，迭代開發(fā)方法 — 以 IBM 的 Rational 統(tǒng)一過程 ®，或者 RUP ®為例— 包括了一系列的增量的步驟或者迭代。每一個迭代都包括一些或者很多的開發(fā)活動（需求、分析、設計、實現(xiàn)等等），就像你在圖 1 中看到的那樣。每一個迭代也有一系列良好定義的目標并生成最終系統(tǒng)的部分工作實現(xiàn)。每個后續(xù)的迭代都建立在前一個迭代的基礎上以使系統(tǒng)得到發(fā)展和細化，直到最終產(chǎn)品被完成。
早期的迭代著重于需求、分析和設計；后期的迭代著重于實現(xiàn)和測試。
圖 1: RUP 的迭代開發(fā)。每一個迭代都包括需求、分析、設計、實現(xiàn)和測試活動。同時，每個迭代都建立在前一個迭代工作的基礎上，每一次迭代都會生成更加接近最終產(chǎn)品的可執(zhí)行版本。
迭代開發(fā)方法已經(jīng)證明了自己優(yōu)于瀑布型的開發(fā)方法，理由如下：
它允許需求的變化
需求的變化和“進一步的蔓延” — 技術(shù)和客戶驅(qū)動的特性的累加 — 一直是項目中導致麻煩、延期交付、令客戶不滿意和使開發(fā)人員泄氣的主要原因。為了解決這些問題，使用迭代開發(fā)方法的團隊應該在項目開發(fā)的幾周里就關(guān)注生成和演示可執(zhí)行的軟件，這樣就強制了需求的檢查并可以幫助減少需求從而反映系統(tǒng)的本質(zhì)。
集成不是在項目的尾聲進行的“大動作”
將系統(tǒng)的集成留到項目的結(jié)尾幾乎總是會導致耗時的返工 — 有時這種返工會花費整個項目工作量的百分之四十的時間。為了避免這種返工，每一次迭代都以集成構(gòu)建系統(tǒng)各部分結(jié)束；這樣不斷的積累將最小化日后的返工。
早期的迭代可以暴露風險
迭代的開發(fā)方法可以幫助團隊在早期的迭代中減少風險，因為在這些迭代中包括了對所有過程組件的測試。當早期的迭代覆蓋了項目的很多方面時 — 工具、購買的軟件和團隊成員的技能等等 — 團隊能夠很快的發(fā)現(xiàn)被預感的風險是否是真實的，并且能夠在問題相對容易并花費很少成本解決時揭示沒有被發(fā)現(xiàn)的新的風險。
對產(chǎn)品的管理能夠采取戰(zhàn)術(shù)性的變化
迭代開發(fā)能夠快速的生成可執(zhí)行的架構(gòu)（雖然功能有限），這個架構(gòu)能夠為了應對競爭對手的快速版本發(fā)布容易的調(diào)整產(chǎn)品使之成為”輕量級的“或者“改進的”版本。