本文來自 Rational Edge ：一個理想的迭代開發(fā)方法模型在很多方面與理想的瀑布開發(fā)模型有著根本上的不同。但是，從實際來說，沒有一個團隊嚴格的應用了每一種開發(fā)方法模型。本文解釋了為什么開發(fā)團隊決定逐步的從類似瀑布型的開發(fā)方法轉變成更加類似迭代開發(fā)的方法，同時也概述了能夠幫助這種轉變的步驟。
實際上，多數(shù)的開發(fā)團隊使用了改進了的 瀑布型開發(fā)方法，他們將項目分解成為兩個或者更多的部分，有時這些部分被稱為階段或者是時期。這種改良可以幫助簡化集成、使測試人員更早的進行測試工作和提供更早的項目狀態(tài)的觀測。這種方法也將代碼分解成了易于管理的片斷并最小化了以存根和驅動程序形式的、被測試需要的代碼集成。此外這種方法允許你原型化你認為有風險的或者有難度的部分，并且使用來自每一個階段的反饋修改你的設計。然而，使用瀑布型開發(fā)方法的執(zhí)行與想象是相反的：很多設計團隊把在階段 1 之后的修改設計視為他們的最初設計或者需求過程的失敗。雖然一個改進了的瀑布型開發(fā)方法并不排除反饋的使用，但是它并沒有促進、支持和鼓勵反饋的使用。最后，想要最小化風險就不要典型的驅動一個瀑布型的開發(fā)項目。對于軟件開發(fā)過程來說，本文探索了”迭代“開發(fā)方法超越傳統(tǒng)的瀑布型開發(fā)方法的進步。 相比較而言，迭代開發(fā)方法 — 以 IBM 的 Rational 統(tǒng)一過程 ®，或者 RUP ®為例— 包括了一系列的增量的步驟或者迭代。每一個迭代都包括一些或者很多的開發(fā)活動（需求、分析、設計、實現(xiàn)等等），就像你在圖 1 中看到的那樣。每一個迭代也有一系列良好定義的目標并生成最終系統(tǒng)的部分工作實現(xiàn)。每個后續(xù)的迭代都建立在前一個迭代的基礎上以使系統(tǒng)得到發(fā)展和細化，直到最終產品被完成。 早期的迭代著重于需求、分析和設計；后期的迭代著重于實現(xiàn)和測試。
迭代開發(fā)方法已經證明了自己優(yōu)于瀑布型的開發(fā)方法，理由如下：
一些項目經理反抗采用迭代的開發(fā)方法，將迭代開發(fā)視為一種沒有盡頭的、不可控的形式。然而，在 RUP 中，這個項目是能夠被很好的控制的。迭代的次數(shù)、周期和目標被仔細的計劃；并且項目參與者的任務和角色被良好的定義。此外，進展的客觀量度應該能夠被獲取。雖然團隊要從一個迭代到下一個迭代中重做一些事情，但是這個工作也是可以被仔細的控制的。
多數(shù)的瀑布型的項目將開發(fā)工作劃分為階段或者時期；我們也可以將這個劃分視為向迭代方法轉換的第一步。但是為了實現(xiàn)向迭代開發(fā)方法的過渡，我們要使用下面四個步驟來應用不同的過程原則：
讓我們來更進一步的解釋每一個步驟。 作為向迭代開發(fā)轉換的第一步，在需求和設計階段考慮一個或者更多的功能原型。這些原型的目標是減少主要的技術風險和澄清項目涉眾對系統(tǒng)應該做什么的理解。 通過識別最重要的三個技術風險和最重要的三個有必要澄清的功能部分開始。技術風險也許與新技術、對整個方案影響很多的未決定的技術選擇或者你知道的很難滿足的技術需求有關。功能上的風險也許與項目涉眾為關鍵的功能性提供了模糊的需求或者幾個需求對項目系統(tǒng)都是核心的有關。 對于每一個重要的技術風險，擬訂你要原型化什么以減少風險。考慮一下下面的例子： 技術風險: 項目需要將一個已存在的應用移植到 IBM WebSphere Application Server 上運行。用戶已經開始抱怨應用的性能，并且你所擔心的是移植后也許性能會更加的慢。 原型: 構建一個架構的原型來找出移植你的應用的不同方法。要求一個專家級的 WebSphere 架構師來幫助你。評價結果并編寫架構的和設計的指導方針為開發(fā)團隊提供什么 應該做和什么 不應該做。這將增加你移植的應用的性能是足夠好的以避免在項目后期返工的可能性。 技術風險: 你正在為安排和估計軟件項目構建一個新的應用。你知道對于這個應用和購買的軟件的關鍵區(qū)分將是如何能夠很好的支持迭代計劃。然而，這也是在你的需求說明中最模糊的部分之一。 原型: 基于你關于如何支持迭代項目計劃的設想構建一個功能原型。通過向不同的項目涉中演示原型，你將可以鼓勵他們更加注意項目的計劃，并且他們能夠告訴你他們對你的哪些設想是贊同的、哪些是不贊同的。原型將幫助你澄清計劃的需求，也能夠為你提供關于用戶體驗和對于你的應用的外表和感覺的有用的信息。這個原型甚至能夠產生一些可重用的代碼。
步驟 2 ：劃分詳細設計、實現(xiàn)和測試階段到不同的迭代中。 很多項目團隊發(fā)現(xiàn)在他們知道項目是真正關于什么的之前劃分一個項目成為有意義的迭代是困難的。但是，當你已經進入了詳細設計階段時，你通常對需求是什么和系統(tǒng)的架構看起來象什么樣子有了很好的理解。這是我們試驗迭代開發(fā)的時候了！ 你能夠使用兩個主要的方法來確定你應該在什么樣的迭代中作些什么事情。讓我們從正反兩方面討論一下每一個方法。 方法 1 ：同時開發(fā)一個或者多個子系統(tǒng)。讓我們假設你有九個子系統(tǒng)，每一個都有數(shù)量日益增加的組件。你可以劃分詳細設計、實現(xiàn)和測試階段到三個迭代中，每個迭代瞄準實現(xiàn)九個子系統(tǒng)中的三個。如果在不同的子系統(tǒng)之間存在有限的依賴這將工作的相當?shù)暮?。例如，如果你的九個子系統(tǒng)的每一個都為用戶提供良好定義的一系列能力，你可以在第一個迭代中開發(fā)優(yōu)先級最高的子系統(tǒng)，其次重要的子系統(tǒng)在第二個迭代中實現(xiàn)，以此類推。這種方法有很大的優(yōu)點：如果你的進度落后了時間計劃，你仍然可以交付可運行的具有最重要能力的部分系統(tǒng)。 然而，如果你有一個分層的體系架構，在上層的子系統(tǒng)依賴于底層子系統(tǒng)的能力，這種方法將不能夠很好的工作。如果你必須要在一個時間內構建一個子系統(tǒng)，這樣的體系架構將迫使你首先構建底層的子系統(tǒng)，然后構建越來越上層的子系統(tǒng)。但是為了構建在底層子系統(tǒng)的正確的能力，你通常需要在上層的子系統(tǒng)上進行大量的詳細設計和實現(xiàn)的工作，因為他們決定了什么是你在底層子系統(tǒng)中需要的。這產生了 “catch-22”的現(xiàn)象；第二個方法解釋了如何解決這個問題。 方法 2 ：首先開發(fā)最重要的場景。如果你使用方法 1 ，你一次只能開發(fā)一個子系統(tǒng)。使用方法 2 ，你將重點放在了重要的場景上，或者使用系統(tǒng)的關鍵方法上，然后再添加更多的不是那么重要的場景。這與方法 1 有什么不同呢？讓我們來看一個例子。 假設你正在構建一個新的應用，這個應用將為用戶提供管理缺陷的能力。這是一個分層的應用，被構建在 WebSphere Application Server 上，使用 DB2 作為底層的數(shù)據(jù)庫。在首先的迭代中，你開發(fā)了一系列重要的場景，比如輸入一個簡單的缺陷。在第二次迭代中，你為這些場景添加了復雜性 — 例如，你也許使缺陷能夠被一個工作流來處理。在第三次迭代中，你通過為非典型的用戶提供完整的支持，比如保存部分的缺陷條目然后返回到這個條目中的能力等等。 使用這種方法，你在 所有的迭代中完成 所有的子系統(tǒng)的工作，但是在第一個迭代中你仍然關注最重要的場景，而將不是非常重要的或者最小難度的場景留到最后的迭代中實現(xiàn)。 如果你正工作在一個良好定義的體系架構的系統(tǒng)中時，方法 1 是更加適合的 — 比如，一個已存在系統(tǒng)的增進或者開發(fā)使用簡單體系架構的新應用。多數(shù)構建復雜應用的項目應該使用方法 2 ，但是他們應該以這樣的方式來計劃迭代，這種方法能夠削減后來迭代的范圍以彌補可能的時間推延。
你可以將這個步驟看作是更加正式和有組織的完成步驟 1 （ 盡早的構建功能原型）的方法。但是什么是“可執(zhí)行的架構”呢？ 可執(zhí)行的架構是系統(tǒng)的部分的實現(xiàn)，它被構建以演示架構的設計所支持的關鍵的功能。更重要的是，它能夠證明設計能夠滿足對于性能、生產能力、容量可靠性、可測量性和其他方面的需求。構建一個可執(zhí)行的架構允許你在稍后的階段中在一個堅實的基礎上構建所有的系統(tǒng)功能性的能力。這個可執(zhí)行的架構是一個 進化的原型，它的目的是當系統(tǒng)的架構成熟時，保持已經被證明的特性并保證他們最大可能的滿足系統(tǒng)的需求。換句話說，這些特性將是交付系統(tǒng)的一部分。與你在步驟 1中構建的 功能原型相比，這個進化的原型覆蓋了架構問題的所有方面。 生成一個進化的原型意味著你要設計、實現(xiàn)和測試一系統(tǒng)的個框架結構或者架構。在應用的角度上，系統(tǒng)的功能還沒有被完成，但是大多數(shù)的構建模塊之間的接口已經被實現(xiàn)了，你能夠（并應該）在某種程度上編譯并測試架構。指導初始的負載和性能測試。這個原型也會反映你的關鍵設計的決定，包括技術、主要組件和他們之間接口的選擇。 但是你將如何為這個進化的原型提出系統(tǒng)的架構呢？關鍵是將重點放在最重要的百分之二十到三十的用例上（系統(tǒng)為用戶提供的完全的服務）。這里是一些決定什么用例是最重要的方法。
上面所列出的第一個和最后一個標準是架構師最關心的；項目經理主要關注于前兩個。 對于每一個關鍵的用例，識別最重要的場景并用他們創(chuàng)建可執(zhí)行的系統(tǒng)架構。換句話說就是設計、實現(xiàn)和 測試這些場景。
如果你將要遵循上面所描述的步驟 2 和步驟 3 ，那么你將會非常的接近“理想”迭代開發(fā)的模型。那么，你接下來的步驟應該是融合步驟 2 和步驟 3 ，并添加支持風險驅動和迭代開發(fā)的管理生命周期。這就是在 RUP 中被描述的迭代開式的生命周期。 RUP 對迭代開發(fā)提供了一個結構化的方法，它將一個項目劃分成為四個階段：初始階段、細化階段、構建階段和轉換階段。每一個階段包含了一個或者更多的迭代，每個迭代都關注于產生必要的技術上的可交付物以實現(xiàn)階段的業(yè)務目標。團隊經歷的迭代次數(shù)與需要實現(xiàn)階段的目標的數(shù)量是一樣的，而不是更多。如果在團隊計劃的迭代次數(shù)內他們沒有成功的實現(xiàn)這些目標，他們必須為那個階段添加額外的迭代 — 并且推遲項目。為了避免這種事情發(fā)生，你一定要嚴格的將你的精力集中在每個階段你需要實現(xiàn)的業(yè)務目標上。例如，在初始階段將精力過于集中在需求上將會成生相反的效果。下面是典型的階段目標的簡要描述。
在本文中，我們已經描述了你如何能夠使用四個步驟逐步的從瀑布型的開發(fā)方法轉換到增量的迭代開發(fā)方法。每一個步驟都以最小的中斷為你的開發(fā)工作添加了切實的價值。一些團隊每次不止使用一個步驟；其他的團隊可能在一個步驟上運作了幾個項目，然后才執(zhí)行下一個步驟。然而，你應該選擇使用這種明智的實施方法，因為它能夠幫助你在開發(fā)組織中減少由于過程變化所帶來的風險。
1 對于實踐中 RUP 軟件開發(fā)周期的詳細描述，參見 The Rational Unified Process Made Easy的第 5-8 章，Per Kroll 和 Philippe Kruchten 著（Addison-Wesley， 2003）。 |
|
|
來自： 伊蓮 > 《迭代開發(fā)》
多數(shù)的軟件開發(fā)團隊仍然在開發(fā)項目中使用瀑布型 的開發(fā)過程。采用極端的瀑布型開發(fā)方法意味著你要以嚴格的順序來完成一系列的項目階段：需求分析、設計、實現(xiàn)/集成然后是測試。當項目中出現(xiàn)的問題解是困難的并且解決問題是昂貴時，你可能會推遲測試直到項目周期的末端；這些問題也能夠嚴重的威脅軟件發(fā)布的期限并且使主要的團隊成員在某些開發(fā)環(huán)節(jié)上是空閑的。 
