軟件工程之美4講——瀑布模型之外，還有哪些開發模型？
快速原型模型
快速原型模型，就是爲了要解決客戶的需求不明確和需求多變的問題。先迅速建造一個可以運行的軟件原型，然後收集用戶反饋，再反覆修改確認，使開發出的軟件能真正反映用戶需求，這種開發模型就叫快速原型模型，也叫原型模型。
軟件原型，重點是反映軟件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但開發速度可以很快。原型模型因爲能快速修改，所以能快速對用戶的反饋和變更作出響應，同時原型模型注重和客戶的溝通，所以最終開發出來的軟件能夠真正反映用戶的需求。
但這種快速原型開發往往是以犧牲質量爲代價的。在原型開發過程中，沒有經過嚴謹的系統設計和規劃，可靠性和性能都難以保障。
針對原型模型的這種快速、低質量的特點，通常有兩種處理策略：
- 拋棄策略
- 附加策略
拋棄策略是將原型只應用於需求分析階段，在確認完需求後，原型會被拋棄，實際開發時，將重新開發所有功能。
附加策略則是將原型應用於整個開發過程，原型一直在完善，不斷增加新功能新需求，直到滿足客戶所有需求，最終將原型變成交付客戶的軟件。採用哪種策略來應用原型模型，還是要看項目特點，包括所採用原型開發工具和技術的成熟度。
原型製作並不一定要像傳統代碼一樣進行設計編碼，有很多原型工具，像 Axure、墨刀等，簡單的拖拽就可以實現簡單的界面和交互，同樣可以達到確認需求的目的。現在原型設計已經成爲產品經理確認需求的一個非常重要手段。
大瀑布拆小瀑布
瀑布模型的很多問題，根源都是週期太長。
週期長所以中間難以響應變更，週期長所以客戶很久才能看到結果，週期太長所以風險不好控制。如果能將週期變短，那麼很多問題就迎刃而解了。
增量模型 和 迭代模型
增量模型——按模塊分批次交付增量模型是把待開發的軟件系統模塊化，然後在每個小模塊的開發過程中，應用一個小瀑布模型，對這個模塊進行需求分析、設計、編碼和測試。
相對瀑布模型而言，增量模型週期更短，不需要一次性把整個軟件產品交付給客戶，而是分批次交付。你會發現，增量模型將整個系統進行模塊化處理，所以你可以分批次交付軟件產品，使用戶及時瞭解軟件項目進展。如果一個模塊有問題，或者需要做需求變更，對整體影響也有限。在開發的時候，也可以靈活地按照模塊來分工，多個模塊並行開發提升效率。因爲增量模型的根基是模塊化，所以，如果系統不能模塊化，那麼將很難採用增量模型的模式來開發。另外，對模塊的劃分很抽象，這本身對於系統架構的水平是要求很高的。基於這樣的特點，增量模型主要適用於：需求比較清楚，能模塊化的軟件系統，並且可以按模塊分批次交付。
迭代模型——每次迭代都有一個可用的版本迭代模型每次只設計和實現產品的一部分，然後逐步完成更多功能。每次設計和實現一個階段叫做一個迭代。
在迭代模型中，整個項目被拆分成一系列小的迭代。通常一個迭代的時間都是固定的，不會太長，例如 2～4 周。每次迭代只實現一部分功能，做能在這個週期內完成的功能。在一個迭代中都會包括需求分析、設計、實現和測試，類似於一個小瀑布模型。迭代結束時要完成一個可以運行的交付版本。迭代模型和增量模型很容易混淆，因爲都是把大瀑布拆成小瀑布。這兩種模型的主要差別在於如何拆分項目功能上。增量模型是按照功能模塊來拆分；而迭代模型則是按照時間來拆分，看單位時間內能完成多少功能。還是用蓋房子來理解，增量模型則是先蓋廚房，再是臥室，這樣一個個模塊來完成。而迭代模型則是先蓋一個簡單的茅草房，有簡易的土竈和土牀，然後再升級成小木屋，有更好的竈和更好的臥室，這樣一步步迭代成最終的房子。我原來參與過的瀑布模型開發的項目，因爲要很長時間才能看到最終結果，而且結果通常跟最初描述的結果相差較多，客戶看到後多少會有些心理落差。迭代模型最難的部分，在於規劃每次迭代的內容和要達到的目標。多了可能完不成，少了可能造成每次迭代工作量不飽和，這需要在實踐中去摸索，一個迭代一個迭代的去調整。迭代模型由於在初始迭代時，只清楚當前迭代的需求，而不知道後續需求，設計可能會考慮不周全。這樣的話，迭代一多，系統會有不少冗餘，一段時間後就需要對系統進行重構。另外每次迭代，用戶可能會增加新的需求和對現有需求進行更改，因此開發時間上可能會比預期要長。如果你做的是小項目的話，並不建議使用迭代模型來開發。
我該選擇什麼過程模型？
場景一：外包項目，需要階段驗收假如你現在是一家外包公司，你可以採用瀑布模型開發，但是甲方需要對你項目的每個階段進行驗收測試，以確認你是不是達到要求。針對從需求定義一直到編碼階段，每個階段都有對應的測試驗收。如果畫成圖，就是下面這個樣子的。這個模型就是 V 模型，本質上它還是瀑布模型，只不過它是更重視對每個階段驗收測試的過程模型。
場景二：項目風險高，隨時可能會中斷如果你現在要做一個風險很高的項目，客戶可能隨時不給你錢了。這種情況下，如果採用傳統瀑布模型，無疑風險很高，可能做完的時候才發現客戶給不了錢，損失就很大了！這種情況，基於增量模型或者迭代模型進行開發，就可以有效降低風險。你需要注意的是，在每次交付的時候，要同時做一個風險評估，如果風險過大就不繼續後續開發了，及時止損。這種強調風險，以風險驅動的方式完善項目的開發模型就是螺旋模型。
場景三：山寨一款軟件產品，希望能快速上線發佈其實軟件行業山寨的案例不少，山寨項目的特點是，項目需求是明確的，不會有什麼變化，這時候就可以選擇增量模型，劃分好模塊，先實現核心模塊，發佈可運行版本，再增量發佈其他模塊。多模塊可以同步開發。
場景四：客戶都沒想清楚想要什麼，但是個大單子很多項目，客戶一開始都沒想清楚想要的是什麼，需要花很長時間去分析定義需求，但是單子很大，值得認真去做好。那麼這樣的項目，你可以考慮拆分成四個階段：
- 初始階段主要是確定需求邊界和主要風險，幾乎沒有什麼開發工作。
- 細化階段這個階段主要是確定需求，可以採用快速原型模型開發，和客戶對需求反覆確認，需要輔助一定量的開發和測試工作。對代碼質量可以要求比較低，重點是確認需求。可能需要一個或多個版本迭代。
- 構造階段在需求確認清楚後，現在可以使用迭代模型來開發，逐步交付產品。這個階段的重點是開發和測試。如果迭代中，有新的需求加入或者需求變更，也可以在新的迭代中加入。
- 交付階段在開發和測試完成後，產品可以交付客戶，根據線上運行情況還需要修復一些 Bug。這個階段重點是測試和部署。也會有多個迭代。整個過程看起來就像下圖這樣。上面這種開發方式來源自統一軟件開發過程（Rational Unified Process，RUP），適用於複雜和需求不明確的軟件系統。
場景五：我的產品已經上線，但是需要持續更新維護很多產品在上線後，還在保持不停的更新維護，修復 Bug、增加新功能，每個月甚至每週更新。在這種情況下，迭代模型是比較合適的。固定時間週期，在固定的週期內選擇適合的需求開發任務和 Bug 修復任務去完成，按時發佈。另外還可以嘗試敏捷開發，也是基於迭代的開發模型，它也強調快速交付，每次交付系統的部分功能，來保證客戶滿意度。在敏捷開發中，系統交付的週期稱之爲衝刺（Sprint）。嚴格來說，敏捷開發並不算是一種開發模型，更像是框架或指南。