????????前一篇介紹了瀑布模型。你現(xiàn)在知道了，瀑布模型簡單易行，對于軟件質(zhì)量是有比較高保障的。但是瀑布模型對于前期需求不明確的項目，很難開展需求分析，后續(xù)如果有需求變更，瀑布模型便很難響應(yīng)。

????????而且，每個軟件項目的情況各不相同，都有自己的特點。比如說：

????????有的項目風(fēng)險很高，客戶可能隨時不給你錢了，得要做好準(zhǔn)備，隨時止損；

????????有的項目客戶自己沒想清楚要想的是什么，做出來后再提各種修改意見，必須得想辦法降低變更成本；

????????有的項目客戶希望能很快就能上線。如果選用瀑布模型做這些項目，就會導(dǎo)致成本過高或者周期過長等問題出現(xiàn)。

????????所以，并不是所有的項目都適合使用瀑布開發(fā)模型，你需要針對不同的情況做一些調(diào)整。

????????實際上，為了應(yīng)對瀑布模型的不足，已經(jīng)衍生出了很多其他的開發(fā)模型。今天，我將為你分享一些有代表性的瀑布模型的衍生模型，你可以了解到這些衍生模型的本質(zhì)，在接手不同類型的項目時，可以靈活地進行選擇。

快速原型模型

????????我剛畢業(yè)時參加了一個項目的開發(fā)，項目經(jīng)理跟我說，這個項目怎么快就怎么寫，不要在意代碼質(zhì)量、架構(gòu)、性能這些，當(dāng)時我表示很不能理解，哪有這樣做項目的？

????????我還偷摸著花了很多時間想把代碼寫好，結(jié)果發(fā)現(xiàn)，這個快速做好的簡單版本，主要目的就是為了給客戶演示，跟客戶確認(rèn)需求，然后把客戶的反饋記錄下來，再去優(yōu)化。這樣幾個小版本下來，基本上就把需求確定了，而我當(dāng)時寫的好多代碼根本就用不上。

????????后來我才知道，這就是快速原型模型。

????????快速原型模型，就是為了要解決客戶的需求不明確和需求多變的問題。

????????先迅速建造一個可以運行的軟件原型，然后收集用戶反饋，再反復(fù)修改確認(rèn)，使開發(fā)出的軟件能真正反映用戶需求，這種開發(fā)模型就叫快速原型模型，也叫原型模型。

????????這就好比客戶想要蓋房子，但是他沒想好要蓋成什么樣子，于是施工方就先搭了一棟彩鋼房（就像工地里面搭的臨時房子），讓客戶先用起來，然后再給反饋調(diào)整。

????????因為彩鋼房搭建簡單快速，改起來也相對容易。等到客戶確定好需求，再在已經(jīng)搭好的彩鋼房的基礎(chǔ)上完善，或者直接重新按照確定好的需求造房子。

????????不過，這樣做也有一個問題，用彩鋼房這種方式蓋房子雖然快，但是房子質(zhì)量不會太好，住的不算舒服，想有點個性化的風(fēng)格也難。

????????同樣的道理，也適用于軟件項目。彩鋼房就像是軟件原型，重點是反映軟件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但開發(fā)速度可以很快。

????????原型模型因為能快速修改，所以能快速對用戶的反饋和變更作出響應(yīng)，同時原型模型注重和客戶的溝通，所以最終開發(fā)出來的軟件能夠真正反映用戶的需求。

????????但這種快速原型開發(fā)往往是以犧牲質(zhì)量為代價的。

????????在原型開發(fā)過程中，沒有經(jīng)過嚴(yán)謹(jǐn)?shù)南到y(tǒng)設(shè)計和規(guī)劃，可靠性和性能都難以保障。所以在實際的軟件項目中，針對原型模型的這種快速、低質(zhì)量的特點，通常有兩種處理策略：

????????拋棄策略和附加策略。

????????拋棄策略是將原型只應(yīng)用于需求分析階段，在確認(rèn)完需求后，原型會被拋棄，實際開發(fā)時，將重新開發(fā)所有功能。類似于用彩鋼房蓋房子，確認(rèn)完客戶需求后，拆掉重新建。

????????附加策略則是將原型應(yīng)用于整個開發(fā)過程，原型一直在完善，不斷增加新功能新需求，直到滿足客戶所有需求，最終將原型變成交付客戶的軟件。類似于用彩鋼房蓋房子，最后還要做一番精裝修，交付客戶。

????????采用哪種策略來應(yīng)用原型模型，還是要看項目特點，包括所采用原型開發(fā)工具和技術(shù)的成熟度。舉例來說，如果客戶對可靠性、性能要求高，那么就最好是拋棄策略，如果客戶對質(zhì)量要求不高，有簡單功能就夠了，那么可以試試附加策略。

????????快速原型模型即使到現(xiàn)在還一直有在用，用于低成本快速的確認(rèn)需求。如果你將來遇到這種項目，就沒必要花太長時間在代碼質(zhì)量上，趕緊做出來才是王道。

????????另外，原型制作并不一定要像傳統(tǒng)代碼一樣進行設(shè)計編碼，有很多原型工具，像 Axure、墨刀等，簡單的拖拽就可以實現(xiàn)簡單的界面和交互，同樣可以達(dá)到確認(rèn)需求的目的。現(xiàn)在原型設(shè)計已經(jīng)成為產(chǎn)品經(jīng)理確認(rèn)需求的一個非常重要手段。

大瀑布拆小瀑布

瀑布模型的很多問題，根源都是周期太長。

????????周期長所以中間難以響應(yīng)變更，周期長所以客戶很久才能看到結(jié)果，周期太長所以風(fēng)險不好控制。如果能將周期變短，那么很多問題就迎刃而解了。

基于這種思路，產(chǎn)生了很多開發(fā)模型，比較典型的主要是：增量模型 和 迭代模型。

增量模型——按模塊分批次交付

增量模型是把待開發(fā)的軟件系統(tǒng)模塊化，然后在每個小模塊的開發(fā)過程中，應(yīng)用一個小瀑布模型，對這個模塊進行需求分析、設(shè)計、編碼和測試。相對瀑布模型而言，增量模型周期更短，不需要一次性把整個軟件產(chǎn)品交付給客戶，而是分批次交付。

如果拿蓋房子來比喻的話，就是先蓋衛(wèi)生間，然后蓋廚房，再是臥室。

蓋衛(wèi)生間的時候，也要先分析需求，然后設(shè)計，再實施，最后驗收。有時候也可以多模塊并行，例如同時蓋衛(wèi)生間和廚房，前提是模塊之間不能有依賴關(guān)系，比如，你不可能先蓋二樓再蓋一樓。

你會發(fā)現(xiàn)，增量模型將整個系統(tǒng)進行模塊化處理，所以你可以分批次交付軟件產(chǎn)品，使用戶及時了解軟件項目進展。如果一個模塊有問題，或者需要做需求變更，對整體影響也有限。在開發(fā)的時候，也可以靈活地按照模塊來分工，多個模塊并行開發(fā)提升效率。

因為增量模型的根基是模塊化，所以，如果系統(tǒng)不能模塊化，那么將很難采用增量模型的模式來開發(fā)。另外，對模塊的劃分很抽象，這本身對于系統(tǒng)架構(gòu)的水平是要求很高的。

基于這樣的特點，增量模型主要適用于：需求比較清楚，能模塊化的軟件系統(tǒng)，并且可以按模塊分批次交付。

迭代模型——每次迭代都有一個可用的版本

????????迭代模型每次只設(shè)計和實現(xiàn)產(chǎn)品的一部分，然后逐步完成更多功能。每次設(shè)計和實現(xiàn)一個階段叫做一個迭代。

????????我們還是繼續(xù)拿蓋房子來舉例：如果用迭代模型的方式蓋房子，第一個迭代要先蓋一個茅草屋，快速滿足客戶對房子的核心需求；第二個迭代再蓋一個小木屋，比茅草房更大更舒適；第三個迭代再蓋成一個豪華別墅，滿足客戶所有需求。

????????你要注意，無論是造小木屋還是大別墅，整個過程都會像一個完整的項目一樣，包括需求分析、設(shè)計、實現(xiàn)與測試驗收。

????????在迭代模型中，整個項目被拆分成一系列小的迭代。通常一個迭代的時間都是固定的，不會太長，例如 2～4 周。每次迭代只實現(xiàn)一部分功能，做能在這個周期內(nèi)完成的功能。

????????在一個迭代中都會包括需求分析、設(shè)計、實現(xiàn)和測試，類似于一個小瀑布模型。迭代結(jié)束時要完成一個可以運行的交付版本。

????????迭代模型和增量模型很容易混淆，因為都是把大瀑布拆成小瀑布。這兩種模型的主要差別在于如何拆分項目功能上。

????????增量模型是按照功能模塊來拆分；而迭代模型則是按照時間來拆分，看單位時間內(nèi)能完成多少功能。

????????還是用蓋房子來理解，增量模型則是先蓋廚房，再是臥室，這樣一個個模塊來完成。而迭代模型則是先蓋一個簡單的茅草房，有簡易的土灶和土床，然后再升級成小木屋，有更好的灶和更好的臥室，這樣一步步迭代成最終的房子。

????????我原來參與過的瀑布模型開發(fā)的項目，因為要很長時間才能看到最終結(jié)果，而且結(jié)果通常跟最初描述的結(jié)果相差較多，客戶看到后多少會有些心理落差。

????????而后來改用迭代模型后，因為每次迭代完成后都有可以運行的版本，這樣客戶可以直觀感受軟件的進展，及時調(diào)整心理預(yù)期。尤其是當(dāng)客戶見證了一個軟件從簡陋到完善的過程，往往滿意度是比較高的。

????????迭代模型最難的部分，在于規(guī)劃每次迭代的內(nèi)容和要達(dá)到的目標(biāo)。多了可能完不成，少了可能造成每次迭代工作量不飽和，這需要在實踐中去摸索，一個迭代一個迭代的去調(diào)整。

????????迭代模型由于在初始迭代時，只清楚當(dāng)前迭代的需求，而不知道后續(xù)需求，設(shè)計可能會考慮不周全。這樣的話，迭代一多，系統(tǒng)會有不少冗余，一段時間后就需要對系統(tǒng)進行重構(gòu)。

????????另外每次迭代，用戶可能會增加新的需求和對現(xiàn)有需求進行更改，因此開發(fā)時間上可能會比預(yù)期要長。如果你做的是小項目的話，并不建議使用迭代模型來開發(fā)。

我該選擇什么過程模型？

????????除了上面提到的這幾種模型，還有很多其他開發(fā)模型，要記住所有的開發(fā)模型很難。你搞透了瀑布模型，搞清楚了其階段劃分，結(jié)合一些應(yīng)用場景，你就可以舉一反三，了解絕大部分衍生模型。

????????我在這里給你列舉幾個常見的項目場景，我們可以一起來分析下，看看用什么模型適合。

????????場景一：外包項目，需要階段驗收

????????假如你現(xiàn)在是一家外包公司，你可以采用瀑布模型開發(fā)，但是甲方需要對你項目的每個階段進行驗收測試，以確認(rèn)你是不是達(dá)到要求。

????????針對從需求定義一直到編碼階段，每個階段都有對應(yīng)的測試驗收。如果畫成圖，就是下面這個樣子的。

????????這個模型就是 V 模型，本質(zhì)上它還是瀑布模型，只不過它是更重視對每個階段驗收測試的過程模型。

場景二：項目風(fēng)險高，隨時可能會中斷

????????如果你現(xiàn)在要做一個風(fēng)險很高的項目，客戶可能隨時不給你錢了。這種情況下，如果采用傳統(tǒng)瀑布模型，無疑風(fēng)險很高，可能做完的時候才發(fā)現(xiàn)客戶給不了錢，損失就很大了！這種情況，基于增量模型或者迭代模型進行開發(fā)，就可以有效降低風(fēng)險。你需要注意的是，在每次交付的時候，要同時做一個風(fēng)險評估，如果風(fēng)險過大就不繼續(xù)后續(xù)開發(fā)了，及時止損。

????????????????????????????????????????????????????????????????圖片來源：WikiPedia

????????這種強調(diào)風(fēng)險，以風(fēng)險驅(qū)動的方式完善項目的開發(fā)模型就是螺旋模型。

場景三：山寨一款軟件產(chǎn)品，希望能快速上線發(fā)布

????????其實軟件行業(yè)山寨的案例不少，山寨項目的特點是，項目需求是明確的，不會有什么變化，這時候就可以選擇增量模型，劃分好模塊，先實現(xiàn)核心模塊，發(fā)布可運行版本，再增量發(fā)布其他模塊。多模塊可以同步開發(fā)。

場景四：客戶都沒想清楚想要什么，但是個大單子

????????很多項目，客戶一開始都沒想清楚想要的是什么，需要花很長時間去分析定義需求，但是單子很大，值得認(rèn)真去做好。

那么這樣的項目，你可以考慮拆分成四個階段：

初始階段

主要是確定需求邊界和主要風(fēng)險，幾乎沒有什么開發(fā)工作。

細(xì)化階段

????????這個階段主要是確定需求，可以采用快速原型模型開發(fā)，和客戶對需求反復(fù)確認(rèn)，需要輔助一定量的開發(fā)和測試工作。對代碼質(zhì)量可以要求比較低，重點是確認(rèn)需求。可能需要一個或多個版本迭代。

構(gòu)造階段

????????在需求確認(rèn)清楚后，現(xiàn)在可以使用迭代模型來開發(fā)，逐步交付產(chǎn)品。這個階段的重點是開發(fā)和測試。如果迭代中，有新的需求加入或者需求變更，也可以在新的迭代中加入。

交付階段

????????在開發(fā)和測試完成后，產(chǎn)品可以交付客戶，根據(jù)線上運行情況還需要修復(fù)一些 Bug。這個階段重點是測試和部署。也會有多個迭代。

????????整個過程看起來就像下圖這樣:

????????????????????????????????????????????????????????????????????????圖片來源：《構(gòu)建之法》

????????上面這種開發(fā)方式來源自統(tǒng)一軟件開發(fā)過程（Rational Unified Process，RUP），適用于復(fù)雜和需求不明確的軟件系統(tǒng)。

場景五：我的產(chǎn)品已經(jīng)上線，但是需要持續(xù)更新維護

????????很多產(chǎn)品在上線后，還在保持不停的更新維護，修復(fù) Bug、增加新功能，每個月甚至每周更新。

????????在這種情況下，迭代模型是比較合適的。固定時間周期，在固定的周期內(nèi)選擇適合的需求開發(fā)任務(wù)和 Bug 修復(fù)任務(wù)去完成，按時發(fā)布。

????????另外還可以嘗試敏捷開發(fā)，也是基于迭代的開發(fā)模型，它也強調(diào)快速交付，每次交付系統(tǒng)的部分功能，來保證客戶滿意度。在敏捷開發(fā)中，系統(tǒng)交付的周期稱之為沖刺（Sprint）。

????????嚴(yán)格來說，敏捷開發(fā)并不算是一種開發(fā)模型，更像是框架或指南。有各種開發(fā)模型來實現(xiàn)敏捷開發(fā)，比如說極限編程（Extreme programming），看板（Kanban）和 Scrum。有關(guān)敏捷開發(fā)，接下來我們會重點講解。

總結(jié)

????????現(xiàn)在的軟件項目，各種類型都有，根據(jù)項目特點，選擇好合適的開發(fā)模型，可以讓你事半功倍，降低項目風(fēng)險，提高項目開發(fā)效率，控制項目成本。比如說：

一個以確認(rèn)需求為主要目的的項目，就可以不用花太多時間在代碼質(zhì)量上面，低成本、高效做出來才是最重要的；

一個高風(fēng)險的項目，則可以采用螺旋模型，出現(xiàn)問題及時止損；

一個很長時間加班加點，卻一直沒法上線，導(dǎo)致士氣低落的項目，可以改成增量模型，先上線一個小模塊，讓大家看到成績提升士氣，然后再迭代，逐步上線其他模塊。

????????同時，你也不必拘泥于這幾種開發(fā)模型，還可以借鑒其他模型做的好的地方，甚至創(chuàng)造自己的開發(fā)模型，比如說你覺得敏捷的“站立會議”適合你的項目，那也可以借鑒過來。

總結(jié)

以上是生活随笔為你收集整理的瀑布模型之外，还有哪些开发模型？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。