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