從瀑布型開(kāi)發(fā)到迭代型開(kāi)發(fā)的轉變

　　簡(jiǎn)介： 本文來(lái)自 Rational Edge ：一個(gè)理想的迭代開(kāi)發(fā)方法模型在很多方面與理想的瀑布開(kāi)發(fā)模型有著(zhù)根本上的不同。但是，從實(shí)際來(lái)說(shuō)，沒(méi)有一個(gè)團隊嚴格的應用了每一種開(kāi)發(fā)方法模型。本文解釋了為什么開(kāi)發(fā)團隊決定逐步的從類(lèi)似瀑布型的開(kāi)發(fā)方法轉變成更加類(lèi)似迭代開(kāi)發(fā)的方法，同時(shí)也概述了能夠幫助這種轉變的步驟。

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

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

　　迭代開(kāi)發(fā)的好處

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

　　早期的迭代著(zhù)重于需求、分析和設計;后期的迭代著(zhù)重于實(shí)現和測試。

　　圖 1: RUP 的迭代開(kāi)發(fā)。每一個(gè)迭代都包括需求、分析、設計、實(shí)現和測試活動(dòng)。同時(shí)，每個(gè)迭代都建立在前一個(gè)迭代工作的基礎上，每一次迭代都會(huì )生成更加接近最終產(chǎn)品的可執行版本。

　　迭代開(kāi)發(fā)方法已經(jīng)證明了自己優(yōu)于瀑布型的開(kāi)發(fā)方法，理由如下：

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

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

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

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

　　它使重用更加容易。識別在迭代中進(jìn)行的部分設計和實(shí)現的公用部分要比在計劃期間找出公用部分更加容易。在早期開(kāi)發(fā)中的設計評審允許架構師們發(fā)現潛在的可重用的機會(huì )，并且利用這個(gè)機會(huì )為接下來(lái)的迭代開(kāi)發(fā)成熟的公用代碼。

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