目錄
我們在開發項目的時候常常會用軟件工程方面的設計模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型
這裏將簡單說一下：快速原型模型、瀑布模型、增量模型這3個常用的
還有現在比較火的敏捷模型，敏捷開發，越來越多人使用了。
本章節主要是講 增量和迭代模型
在上一篇文章中，我重點介紹了瀑布模型。你現在知道了，瀑布模型簡單易行，對於軟件質量是有比較高保障的。但是瀑布模型對於前期需求不明確的項目，很難開展需求分析，後續如果有需求變更，瀑布模型便很難響應。
而且，每個軟件項目的情況各不相同，都有自己的特點。比如說：
- 有的項目風險很高，客戶可能隨時不給你錢了，得要做好準備，隨時止損；
- 有的項目客戶自己沒想清楚要想的是什麼，做出來後再提各種修改意見，必須得想辦法降低變更成本；
- 有的項目客戶希望能很快就能上線。
如果選用瀑布模型做這些項目，就會導致成本過高或者週期過長等問題出現。所以，並不是所有的項目都適合使用瀑布開發模型，你需要針對不同的情況做一些調整。
實際上，爲了應對瀑布模型的不足，已經衍生出了很多其他的開發模型。今天，我將爲你分享一些有代表性的瀑布模型的衍生模型，你可以瞭解到這些衍生模型的本質，在接手不同類型的項目時，可以靈活地進行選擇。
一、快速開發快速改
1.1快速原型模型
小明參加了一個項目的開發，項目經理跟他說，這個項目怎麼快就怎麼寫，不要在意代碼質量、架構、性能這些，當時他表示很不能理解，哪有這樣做項目的？
他還偷摸着花了很多時間想把代碼寫好，結果發現，這個快速做好的簡單版本，主要目的就是爲了給客戶演示，跟客戶確認需求，然後把客戶的反饋記錄下來，再去優化。這樣幾個小版本下來，基本上就把需求確定了，而他當時寫的好多代碼根本就用不上。
後來他才知道，這就是快速原型模型。
快速原型模型，就是爲了要解決客戶的需求不明確和需求多變的問題。
先迅速建造一個可以運行的軟件原型，然後收集用戶反饋，再反覆修改確認，使開發出的軟件能真正反映用戶需求，這種開發模型就叫快速原型模型，也叫原型模型。
這就好比客戶想要蓋房子，但是他沒想好要蓋成什麼樣子，於是施工方就先搭了一棟彩鋼房（就像工地裏面搭的臨時房子），讓客戶先用起來，然後再給反饋調整。
因爲彩鋼房搭建簡單快速，改起來也相對容易。等到客戶確定好需求，再在已經搭好的彩鋼房的基礎上完善，或者直接重新按照確定好的需求造房子。
不過，這樣做也有一個問題，用彩鋼房這種方式蓋房子雖然快，但是房子質量不會太好，住的不算舒服，想有點個性化的風格也難。
同樣的道理，也適用於軟件項目。彩鋼房就像是軟件原型，重點是反映軟件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但開發速度可以很快。
原型模型因爲能快速修改，所以能快速對用戶的反饋和變更作出響應，同時原型模型注重和客戶的溝通，所以最終開發出來的軟件能夠真正反映用戶的需求。
但這種快速原型開發往往是以犧牲質量爲代價的。
在原型開發過程中，沒有經過嚴謹的系統設計和規劃，可靠性和性能都難以保障。所以在實際的軟件項目中，針對原型模型的這種快速、低質量的特點，通常有兩種處理策略：拋棄策略和附加策略。
拋棄策略是將原型只應用於需求分析階段，在確認完需求後，原型會被拋棄，實際開發時，將重新開發所有功能。類似於用彩鋼房蓋房子，確認完客戶需求後，拆掉重新建。
附加策略則是將原型應用於整個開發過程，原型一直在完善，不斷增加新功能新需求，直到滿足客戶所有需求，最終將原型變成交付客戶的軟件。類似於用彩鋼房蓋房子，最後還要做一番精裝修，交付客戶。
採用哪種策略來應用原型模型，還是要看項目特點，包括所採用原型開發工具和技術的成熟度。舉例來說，如果客戶對可靠性、性能要求高，那麼就最好是拋棄策略，如果客戶對質量要求不高，有簡單功能就夠了，那麼可以試試附加策略。
快速原型模型即使到現在還一直有在用，用於低成本快速的確認需求。如果你將來遇到這種項目，就沒必要花太長時間在代碼質量上，趕緊做出來纔是王道。
另外，原型製作並不一定要像傳統代碼一樣進行設計編碼，有很多原型工具，像 Axure、墨刀等，簡單的拖拽就可以實現簡單的界面和交互，同樣可以達到確認需求的目的。現在原型設計已經成爲產品經理確認需求的一個非常重要手段。
二、大瀑布拆小瀑布
瀑布模型的很多問題，根源都是週期太長。週期長所以中間難以響應變更，週期長所以客戶很久才能看到結果，週期太長所以風險不好控制。如果能將週期變短，那麼很多問題就迎刃而解了。
基於這種思路，產生了很多開發模型，比較典型的主要是：增量模型 和 迭代模型。
2.1增量模型——按模塊分批次交付
增量模型是把待開發的軟件系統模塊化，然後在每個小模塊的開發過程中，應用一個小瀑布模型，對這個模塊進行需求分析、設計、編碼和測試。相對瀑布模型而言，增量模型週期更短，不需要一次性把整個軟件產品交付給客戶，而是分批次交付。
如果拿蓋房子來比喻的話，就是先蓋衛生間，然後蓋廚房，再是臥室。
蓋衛生間的時候，也要先分析需求，然後設計，再實施，最後驗收。有時候也可以多模塊並行，例如同時蓋衛生間和廚房，前提是模塊之間不能有依賴關係，比如，你不可能先蓋二樓再蓋一樓。
你會發現，增量模型將整個系統進行模塊化處理，所以你可以分批次交付軟件產品，使用戶及時瞭解軟件項目進展。如果一個模塊有問題，或者需要做需求變更，對整體影響也有限。在開發的時候，也可以靈活地按照模塊來分工，多個模塊並行開發提升效率
因爲增量模型的根基是模塊化，所以，如果系統不能模塊化，那麼將很難採用增量模型的模式來開發。另外，對模塊的劃分很抽象，這本身對於系統架構的水平是要求很高的。
基於這樣的特點，增量模型主要適用於：需求比較清楚，能模塊化的軟件系統，並且可以按模塊分批次交付。
2.2迭代模型——每次迭代都有一個可用的版本
迭代模型每次只設計和實現產品的一部分，然後逐步完成更多功能。每次設計和實現一個階段叫做一個迭代。
我們還是繼續拿蓋房子來舉例：如果用迭代模型的方式蓋房子，第一個迭代要先蓋一個茅草屋，快速滿足客戶對房子的核心需求；第二個迭代再蓋一個小木屋，比茅草房更大更舒適；第三個迭代再蓋成一個豪華別墅，滿足客戶所有需求。
你要注意，無論是造小木屋還是大別墅，整個過程都會像一個完整的項目一樣，包括需求分析、設計、實現與測試驗收。
在迭代模型中，整個項目被拆分成一系列小的迭代。通常一個迭代的時間都是固定的，不會太長，例如 2-4 周。每次迭代只實現一部分功能，做能在這個週期內完成的功能。
在一個迭代中都會包括需求分析、設計、實現和測試，類似於一個小瀑布模型。迭代結束時要完成一個可以運行的交付版本。
迭代模型和增量模型很容易混淆，因爲都是把大瀑布拆成小瀑布。這兩種模型的主要差別在於如何拆分項目功能上。
增量模型是按照功能模塊來拆分；而迭代模型則是按照時間來拆分，看單位時間內能完成多少功能。
還是用蓋房子來理解，增量模型則是先蓋廚房，再是臥室，這樣一個個模塊來完成。而迭代模型則是先蓋一個簡單的茅草房，有簡易的土竈和土牀，然後再升級成小木屋，有更好的竈和更好的臥室，這樣一步步迭代成最終的房子。
我原來參與過的瀑布模型開發的項目，因爲要很長時間才能看到最終結果，而且結果通常跟最初描述的結果相差較多，客戶看到後多少會有些心理落差。
而後來改用迭代模型後，因爲每次迭代完成後都有可以運行的版本，這樣客戶可以直觀感受軟件的進展，及時調整心理預期。尤其是當客戶見證了一個軟件從簡陋到完善的過程，往往滿意度是比較高的。
迭代模型最難的部分，在於規劃每次迭代的內容和要達到的目標。多了可能完不成，少了可能造成每次迭代工作量不飽和，這需要在實踐中去摸索，一個迭代一個迭代的去調整。
迭代模型由於在初始迭代時，只清楚當前迭代的需求，而不知道後續需求，設計可能會考慮不周全。這樣的話，迭代一多，系統會有不少冗餘，一段時間後就需要對系統進行重構。
另外每次迭代，用戶可能會增加新的需求和對現有需求進行更改，因此開發時間上可能會比預期要長。如果你做的是小項目的話，並不建議使用迭代模型來開發。
三、我該選擇什麼過程模型？
除了上面提到的這幾種模型，還有很多其他開發模型，要記住所有的開發模型很難。你搞透了瀑布模型，搞清楚了其階段劃分，結合一些應用場景，你就可以舉一反三，瞭解絕大部分衍生模型。
我在這裏給你列舉幾個常見的項目場景，我們可以一起來分析下，看看用什麼模型適合。
場景一：外包項目，需要階段驗收
假如你現在是一家外包公司，你可以採用瀑布模型開發，但是甲方需要對你項目的每個階段進行驗收測試，以確認你是不是達到要求。
針對從需求定義一直到編碼階段，每個階段都有對應的測試驗收。如果畫成圖，就是下面這個樣子的。
這個模型就是 V 模型，本質上它還是瀑布模型，只不過它是更重視對每個階段驗收測試的過程模型。
場景二：項目風險高，隨時可能會中斷
如果你現在要做一個風險很高的項目，客戶可能隨時不給你錢了。這種情況下，如果採用傳統瀑布模型，無疑風險很高，可能做完的時候才發現客戶給不了錢，損失就很大了！
這種情況，基於增量模型或者迭代模型進行開發，就可以有效降低風險。你需要注意的是，在每次交付的時候，要同時做一個風險評估，如果風險過大就不繼續後續開發了，及時止損。
(圖片來源：WikiPedia)
這種強調風險，以風險驅動的方式完善項目的開發模型就是螺旋模型。
場景三：山寨一款軟件產品，希望能快速上線發佈
其實軟件行業山寨的案例不少，山寨項目的特點是，項目需求是明確的，不會有什麼變化，這時候就可以選擇增量模型，劃分好模塊，先實現核心模塊，發佈可運行版本，再增量發佈其他模塊。多模塊可以同步開發。
場景四：客戶都沒想清楚想要什麼，但是個大單子
很多項目，客戶一開始都沒想清楚想要的是什麼，需要花很長時間去分析定義需求，但是單子很大，值得認真去做好。
那麼這樣的項目，你可以考慮拆分成四個階段：
1. 初始階段
主要是確定需求邊界和主要風險，幾乎沒有什麼開發工作。
2. 細化階段
這個階段主要是確定需求，可以採用快速原型模型開發，和客戶對需求反覆確認，需要輔助一定量的開發和測試工作。對代碼質量可以要求比較低，重點是確認需求。可能需要一個或多個版本迭代。
3. 構造階段
在需求確認清楚後，現在可以使用迭代模型來開發，逐步交付產品。這個階段的重點是開發和測試。如果迭代中，有新的需求加入或者需求變更，也可以在新的迭代中加入。
4. 交付階段
在開發和測試完成後，產品可以交付客戶，根據線上運行情況還需要修復一些 Bug。這個階段重點是測試和部署。也會有多個迭代。
整個過程看起來就像下圖這樣。
（圖片來源：《構建之法》）
上面這種開發方式來源自統一軟件開發過程（Rational Unified Process，RUP），適用於複雜和需求不明確的軟件系統。
場景五：我的產品已經上線，但是需要持續更新維護
很多產品在上線後，還在保持不停的更新維護，修復 Bug、增加新功能，每個月甚至每週更新。
在這種情況下，迭代模型是比較合適的。固定時間週期，在固定的週期內選擇適合的需求開發任務和 Bug 修復任務去完成，按時發佈。
另外還可以嘗試敏捷開發，也是基於迭代的開發模型，它也強調快速交付，每次交付系統的部分功能，來保證客戶滿意度。在敏捷開發中，系統交付的週期稱之爲衝刺（Sprint）。
嚴格來說，敏捷開發並不算是一種開發模型，更像是框架或指南。有各種開發模型來實現敏捷開發，比如說極限編程（Extreme programming），看板（Kanban）和 Scrum。有關敏捷開發，我將在下一篇中向你詳細講解。
總結
現在的軟件項目，各種類型都有，根據項目特點，選擇好合適的開發模型，可以讓你事半功倍，降低項目風險，提高項目開發效率，控制項目成本。比如說：
- 一個以確認需求爲主要目的的項目，就可以不用花太多時間在代碼質量上面，低成本、高效做出來纔是最重要的；
- 一個高風險的項目，則可以採用螺旋模型，出現問題及時止損；
- 一個很長時間加班加點，卻一直沒法上線，導致士氣低落的項目，可以改成增量模型，先上線一個小模塊，讓大家看到成績提升士氣，然後再迭代，逐步上線其他模塊。
同時，你也不必拘泥於這幾種開發模型，還可以借鑑其他模型做的好的地方，甚至創造自己的開發模型，比如說你覺得敏捷的“站立會議”適合你的項目，那也可以借鑑過來。