引言
在學習軟體工程的時候接觸過一些軟體工程開發模型的相關概念，其中，印象比較深刻的就是瀑布模型和敏捷開發模型，這兩種模型在日常的軟體開發中都是非常常用的，但是它們也有比較大的區別，所以在實際的應用場景也不同，
瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測驗的步驟順序進行，敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟體開發，
敏捷開發模型
敏捷軟體開發是基于敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱，自組織、跨職能團隊運用適合他們自身環境的實踐進行演進得出解決方案，
敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟體開發，
敏捷開發的特點
敏捷開發的特點就是下面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%軟體開發失敗的原因，
瀑布模型的生命周期
瀑布模型將軟體生命周期劃分為 制定計劃、需求分析、軟體設計、程式撰寫、軟體測驗和運行維護 等六個基本活動，并且規定了它們 自上而下、相互銜接的固定次序 ，如同瀑布流水，逐級下落，其嚴格強調檔案，前一個階段的輸出就是下一個階段的輸入，檔案是個階段銜接的唯一資訊，所以很多開發人員好象是在開發檔案，而不是開發軟體，因為要到開發的后期，才可以看到軟體的“模樣”，
瀑布模型的優點
瀑布模型作為最典型的預見性方法，其優點主要在于：
- 階段清晰：從計劃到開發最后到上線運行，三個階段非常清晰，
- 時間順序：每個階段順序必須是從上到下，嚴格按照時間先后進行，
- 環環相扣：在每一個階段都必須有產出物然后才能進入到下一個階段進行，
- 黑盒模式：每個階段都有各自的角色和分工，各自只關心自己的任務，比如需求階段開發人員無需關注，
瀑布模型的缺點
而其缺點也突出：
- 需求隔離：由于各階段的人員只能接觸到自己作業范圍內的東西，所以對客戶需求的理解程度高低不等，開發人員更像是定義為流水線上的工人，
- 變更代價大：既然叫做瀑布，就意味著不應該走回頭路，否則如果出現返工，付出的代價會很大，需求變更，編碼人員會很強的抵觸情緒，
- 束縛創造性：由于強調檔案管理，所以管理人員會比較喜歡，但是他束縛了開發人員的創造性，
- 周期漫長：整個開發持續的生命周期很長，需求和設計的時間會耗費特別多，有時候會占用三分之一甚至更多時間，這樣整個周期就會變長，大都在半年到一年左右的時間，所以更適合需求相對穩定的大專案，
參考
- 瀑布式開發與敏捷開發的區別是什么
- 八分鐘敏捷開發（scrum）掃盲
- 【敏捷1.3】敏捷中的專案開發生命周期
- 專案管理 之一 軟體開發生命周期（軟體開發程序、瀑布模型、敏捷開發等）
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/472386.html
標籤：其他