此博客用于記錄2020年9月26日每日分享，
軟件工程中的集中常見模式，瀑布模型，敏捷開發等

日期：2020年9月26日
主題：

討論討論怎么使用軟件工程的思想來解決問題

軟件工程中的集中常見模式，瀑布模型，敏捷開發等

文章目錄

• 軟件工程
• 常見的開發模型
• • 瀑布模型
  • 敏捷開發
  • 小結

軟件工程

??軟件工程是一門用工程化方法解決軟件項目問題的學科，其本質也是一門工程學科，這門課的知識在學完后，不僅可以應用在軟件項目中，還可以應用于日常生活中遇到的一些問題。

Everything is a project。

??有目的、有計劃、有步驟地解決問題的方法就是工程方法。

• 想法：想法階段通常是想要解決問題。最開始問題通常是模糊的，所以需要清晰地定義好問題，研究其可行性，檢查是否有可行的解決方案。
• 概念：概念階段就是用圖紙、草圖、模型等方式，提出一些概念性的解決方案。這些方案可能有多個，最終會確定一個解決方案。
  計劃：計劃階段是關于如何實施的計劃，通常會包含人員、任務、任務持續時間、任務的依賴關系，以及完成項目所需要的預算。
• 設計：設計階段就是要針對產品需求，將解決方案進一步細化，設計整體架構和劃分功能模塊，作為分工合作和開發實施的一個依據和參考。
• 開發：開發階段就是根據設計方案，將解決方案構建實施。開發階段通常是一個迭代的過程，這個階段通常會有構建、測試、調試和重新設計的迭代。
• 發布：將最終結果包括文檔發布。

---

常見的開發模型

瀑布模型

??嚴格按照一定的流程開發，需求分析-設計-編碼-測試，部署這樣的流程開發，每個階段都有相應的產出。但是當客戶的需求變化了，就不得不重新來一次從頭到尾的分析，靈活性較差。

瀑布模型的優缺點
??你會發現瀑布模型其實跟我們傳統的建筑建造方式非常類似。我們拿蓋房子的過程來看看瀑布模型。

客戶想要蓋一棟房子（初步的想法）。

• 客戶一開始可能沒想清楚想要什么樣子的房子。（客戶對需求還不清楚）
• 施工方開始找客戶確認：用途是什么，要個幾層的房子，什么建筑風格，希望什么時間完工，預算多少。（問題定義）
• 施工方根據客戶提的需求，對比工期和預算，評估是不是值得做。（可行性研究）
• 施工方評估后覺得可行，于是和客戶簽訂合同，約定價錢和工期。（立項，制定項目計劃）
• 施工方開始跟客戶溝通確認需求，例如每層戶型如何，將來的裝修風格等。（需求分析）
• 確認完需求后，施工方開始出建筑施工圖，還畫了漂亮的建筑效果圖。（系統設計和 UI 設計）
• 施工方按照設計圖開始施工。（程序編碼）
• 這期間如果客戶去參觀施工情況，客戶只能看到毛胚，只有最后施工完成才能看到最終樣子。（在中間客戶看不到結果，只有最后能看到結果）
• 原定二層是兩個臥室，在房子施工過程中，突然客戶說兩個臥室不夠，要改成三個臥室。這意味著施工方要對施工圖重新設計，很多已經建好的房間要拆掉重建。（瀑布模型是很難響應需求變更的，而且越到后期代價越大）
• 工程質量檢查人員對施工結果進行質量檢測，如果不滿足質量要求，需要修改。（測試）
• 最后驗收通過后，客戶入住。（上線）
  所以你看，用瀑布模型開發軟件，就像建筑工程里，蓋房子一樣簡單和自然。每個階段都有側重的事情，就像需求階段專注于搞清楚需求，編碼階段專注于實現。

??最重要的是，這種編碼前先設計、編碼后測試、整個過程重視文檔的方式，開發出來的產品，質量相對是有保障的。

??但用瀑布模式開發，也存在一些問題。

??最大的問題就是不能及時響應需求變更，越到后期變更代價越大。另外，通常要到最后階段才能看到結果是什么樣子。

---

敏捷開發

你如何理解敏捷開發？

??敏捷開發更多的是一種思想，開發當中注重“人”作用，更多的關心客戶合作，團隊之間的交流之類的

??各種敏捷框架、方法論和工具，就像是“術”，告訴你敏捷開發的方式，而敏捷則是“道”，是一套價值觀和原則，指導你在軟件項目開發中做決策。

什么是敏捷開發詳解2

如果用敏捷的方式蓋房子？
客戶想要蓋一棟房子（初步的想法）。

• 產品經理和客戶進行了初步的溝通，把用戶的需求寫成了一個個用戶故事（用簡單的用戶故事代替繁重的需求文檔），例如：

作為一個上班族，我想要一個臥室，以便于休息；
作為一個家庭主婦，我想要一個廚房，以便于做飯。

• 施工人員根據用戶故事和客戶進一步溝通（客戶合作高于合同談判），然后對用戶故事進行設計和實現；
• 每個用戶故事開發時，還要給一個測試機器人編寫測試腳本，讓機器人可以自動測試（大量采用自動化測試），并且做好的用戶故事可以隨時被測試驗收（隨時發布，持續集成）；
• 每個 Sprint 四個星期時間（時間盒子，迭代時間固定）；
• 第一個 Sprint 搭了個草棚，一張床就是臥室，廁所就挖了一個坑，廚房還來不及搭建（每個 Sprint 會選擇高優先級的用戶故事），屋頂還在漏水（每個 Sprint 會定期發布，客戶可以隨時看到可用版本，即使還不完整）；
• 第二個 Sprint 有了簡易廚房，同時修復了屋頂漏水的毛病（每個 Sprint 不僅完成用戶故事，還會修復 Bug）；
• 第三個 Sprint 升級成了小木屋，但是忘記加上窗戶（敏捷推崇自動化測試，但可能會測試不完備）；
• 第四個 Sprint 升級成了磚瓦房，窗戶也開好了，客戶可以入住。但是這時候客戶發現一家三口的話，完全不夠用，需要擴建到 3 個臥室。于是決定下個迭代改成 3 個臥室（響應變化高于遵循計劃）；
• 第五個 Sprint，升級成了 3 個臥室，升級過程中把廚房下水道弄壞了（迭代過程中可能會導致質量不穩定）；
• 第六個 Sprint，修復了下水道的問題，房子也裝修好了（迭代中不斷完善）；
  客戶驗收使用（上線）。

??敏捷開發對團隊成員的要求較高，可能某個小功能從需求分析，設計，編碼，測試都需要你獨立開發，如果客戶不愿意配合你，那么敏捷開發也很難運行起來

??其他幾個模型因為用的不是特別多，增量模型，螺旋模型，用的不是特別多，所以這里只簡單地列出他們在哪些場景常見，其他的會把部分資料發到群里大家有空的時候一起學學吧。

小結

??根據項目特點，選擇好合適的開發模型，可以讓你事半功倍，降低項目風險，提高項目開發效率，控制項目成本。比如說：

• 一個以確認需求為主要目的的項目，就可以不用花太多時間在代碼質量上面，低成本、高效做出來才是最重要的；
• 一個高風險的項目，則可以采用螺旋模型，出現問題及時止損；
• 一個很長時間加班加點，卻一直沒法上線，導致士氣低落的項目，可以改成增量模型，先上線一個小模塊，讓大家看到成績提升士氣，然后再迭代，逐步上線其他模塊。

---

• 快速原型模型：不見兔子不撒鷹。期初不考慮質量、架構，用最快的速度見效，并向用戶確認需求。經過幾輪直觀、快速的反饋，把需求確定下來。接下來，既可以拋棄原型用瀑布精密重構，也可以在模型基礎上完善。優點是快速有效的確認需求。不足難以有效應對后續的需求變更。

• 增量模型：分而治之。將大系統橫向拆分成相對獨立的若干小模塊，每個模塊采用瀑布模式分批次交付。優點是較快見到成果，且能夠及時了解項目進展。不足是存在需求明確、系統可拆分、交付可分批等適用條件。

• 迭代模型：羅馬不是一天建成。把軟件項目縱向劃分成若干階段，從核心功能入手，逐漸深化、細化，直到滿足用戶的全部需求。每個階段都是一個瀑布，都要在前一階段成果基礎上加工、打磨。優點是快速滿足基本需要，并體會軟件演進的快感。不足是需求演化具有不確定性，會導致代碼冗余、系統重構風險、項目周期不可控。

總結

以上是生活随笔為你收集整理的2020年9月26日-02-软件工程-工程化思维+瀑布模型+敏捷开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。