常見開發模型-敏捷開發與瀑布開發模型詳解
引言
在學習軟體工程的時候接觸過一些軟體工程開發模型的相關概念，其中，印象比較深刻的就是瀑布模型和敏捷開發模型。這兩種模型在日常的軟體開發中都是非常常用的，但是它們也有比較大的區別，所以在實際的應用場景也不同。
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。
敏捷開發模型
敏捷軟體開發是基於敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱。自組織、跨職能團隊運用適合他們自身環境的實踐進行演進得出解決方案。
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。
敏捷開發的特點
敏捷開發的特點就是下面4句話：
「個體與互動」勝過「過程與工具」
「可以工作的軟體」勝過「面面俱到的文擋」
「客戶協作」勝過「合同談判」
「響應變化」勝過「遵循計劃」
在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。
敏捷開發藉助網際網路浪潮開始流行起來，相比瀑布模式，敏捷無疑更加貼近網際網路時代背景下快速發展變化的市場環境以及業務需求。
敏捷開發的三大角色
產品負責人（Product Owner）
主要負責和客戶溝通確定產品的功能和達到要求的標準，並指定軟體的釋出日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果，一般是由產品經理擔任。
流程管理員（Scrum Master）
問題清道夫！主要負責整個Scrum流程在專案中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。
開發團隊（Scrum Team）
開發主力！主要負責軟體產品在Scrum規定流程下進行開發工作。人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；不論過程只問結果！只要能達到目標，不論任何工作時間、方式。
敏捷開發的生命週期
軟體開發生命週期(SDLC)是設計，開發和測試高質量軟體的一種現象。
在敏捷的SDLC開發過程中，客戶能夠看到結果並瞭解他/她是否滿意。這是敏捷SDLC模型的優勢之一。
敏捷SDLC的每次迭代都包含跨不同階段的跨職能團隊：
- 需求收集和分析
- 設計要求
- 構造/迭代
- 部署
- 測試
- 反饋
敏捷開發主要包含三種模式：
迭代式開發生命週期
聽說過敏捷的同學一定都聽說過迭代這個東西。有的人說我們要迭代一個版本，有的人說我們要在這個迭代週期內完成什麼，不管它指的是具體的軟體版本，還是一段時間，這兩字的含義其實都是一樣的，那就是在整個專案開發過程中，切分出來的一個一個的小時間段。這一個時間段就是一次迭代。通過一次次的迭代，讓整個專案更加清晰。最出名的針對迭代的概念的圖示就是這個圖。
從這個圖中我們能看出什麼呢？迭代就是不斷豐富細節的過程。每一次的迭代，我們都應該讓這個專案更加的清晰明瞭，細節也一步步地完善。
增量式開發生命週期
說完迭代式開發過程，我們再來說說增量，迭代和增量是所有敏捷教程都會說的東西，因為這兩個東西很多人容易搞混。增量實際上是不斷的新增待開始專案的產品的模組功能。就像搭積木一樣地將不同的模板拼成一個完整的產品。同樣地，也有一張圖是專門針對增量這個概念的。
看出來增量和迭代的不同了嗎？迭代的時候，有輪廓，不斷完善細節。而增量，沒有整體輪廓，上來就是細節完整的一個部分，不斷地一部分一部分地完成，最終形成一個完整的產品。
補充：迭代和增量這兩種圖，同時對應 Web 應用中圖片的兩種展示形式，不知道大家有沒有印象，在網速不好的時候，有些網站開啟大圖是一塊一塊出來的，而有些網站開啟大圖是先模糊然後一步一步清晰的。有興趣的同學可以搜尋查詢一下 PhotoShop 中匯出 WEB 格式時選擇連續功能的作用。
混合式開發生命週期
將上面的迭代和增量合起來，也就是在一次迭代中同時包含著增量，這樣的形式就是混合式的生命週期 。這種情況下可以很好地運用這兩種開發形式的優點。其實，我們目前大部分公司中的迭代衝刺都是這種混合式的生命週期的開發形式。在每次迭代中，我們新增的新功能模組其實就是在整個專案的輪廓中不斷新增完善細節。
但是，需要注意的，不管是考試還是面試，你還是要能清晰地說明白迭代和增量的區別的。此外，在混合的時候，每次迭代也可以看做是一次傳統的開發過程，總之，混合就是各種混合，吸收各家優勢。
敏捷開發的優點
- 更快交付價值
- 更低的風險
- 擁抱變化
- 更好的質量
- 持續改進
- 更高的客戶滿意度
- 更高的團隊滿意度
敏捷開發的缺點
- 很難進行準確的資源規劃
- 很難準確的定義“輕量的“或必要的文件
- 很難把握整體產品的一致性
- 很難預測有限的終點
- 很難有效地進行度量
瀑布開發模型
瀑布模型（Waterfall Model）是最早出現的軟體開發模型，是傳統軟體開發方法的代表。在軟體工程中佔有重要的地位，它提供了軟體開發的基本框架。1970 年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到 80 年代早期，它一直是唯一被廣泛採用的軟體開發模型。
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文件，測試計劃和程式碼審閱等等。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，專案早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在專案進行過程中可能變化的情況下基本是不可行的。
有論文統計，它是造成70%軟體開發失敗的原因。
瀑布模型的生命週期
瀑布模型將軟體生命週期劃分為 制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護 等六個基本活動，並且規定了它們 自上而下、相互銜接的固定次序 ，如同瀑布流水，逐級下落。其嚴格強調文件，前一個階段的輸出就是下一個階段的輸入，文件是個階段銜接的唯一資訊。所以很多開發人員好象是在開發文件，而不是開發軟體，因為要到開發的後期，才可以看到軟體的“模樣”。
瀑布模型的優點
瀑布模型作為最典型的預見性方法，其優點主要在於：
- 階段清晰：從計劃到開發最後到上線執行，三個階段非常清晰。
- 時間順序：每個階段順序必須是從上到下，嚴格按照時間先後進行。
- 環環相扣：在每一個階段都必須有產出物然後才能進入到下一個階段進行。
- 黑盒模式：每個階段都有各自的角色和分工，各自只關心自己的任務。比如需求階段開發人員無需關注。
瀑布模型的缺點
而其缺點也突出：
- 需求隔離：由於各階段的人員只能接觸到自己工作範圍內的東西，所以對客戶需求的理解程度高低不等，開發人員更像是定義為流水線上的工人。
- 變更代價大：既然叫做瀑布，就意味著不應該走回頭路。否則如果出現返工，付出的代價會很大。需求變更，編碼人員會很強的牴觸情緒。
- 束縛創造性：由於強調文件管理，所以管理人員會比較喜歡，但是他束縛了開發人員的創造性。
- 週期漫長：整個開發持續的生命週期很長，需求和設計的時間會耗費特別多，有時候會佔用三分之一甚至更多時間，這樣整個週期就會變長，大都在半年到一年左右的時間，所以更適合需求相對穩定的大專案。