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