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

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

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

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

文章目錄

• 軟件工程
• 常見的開發(fā)模型
• • 瀑布模型
  • 敏捷開發(fā)
  • 小結(jié)

軟件工程

??軟件工程是一門用工程化方法解決軟件項(xiàng)目問題的學(xué)科，其本質(zhì)也是一門工程學(xué)科，這門課的知識(shí)在學(xué)完后，不僅可以應(yīng)用在軟件項(xiàng)目中，還可以應(yīng)用于日常生活中遇到的一些問題。

Everything is a project。

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

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

---

常見的開發(fā)模型

瀑布模型

??嚴(yán)格按照一定的流程開發(fā)，需求分析-設(shè)計(jì)-編碼-測(cè)試，部署這樣的流程開發(fā)，每個(gè)階段都有相應(yīng)的產(chǎn)出。但是當(dāng)客戶的需求變化了，就不得不重新來一次從頭到尾的分析，靈活性較差。

瀑布模型的優(yōu)缺點(diǎn)
??你會(huì)發(fā)現(xiàn)瀑布模型其實(shí)跟我們傳統(tǒng)的建筑建造方式非常類似。我們拿蓋房子的過程來看看瀑布模型。

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

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

??最重要的是，這種編碼前先設(shè)計(jì)、編碼后測(cè)試、整個(gè)過程重視文檔的方式，開發(fā)出來的產(chǎn)品，質(zhì)量相對(duì)是有保障的。

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

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

---

敏捷開發(fā)

你如何理解敏捷開發(fā)？

??敏捷開發(fā)更多的是一種思想，開發(fā)當(dāng)中注重“人”作用，更多的關(guān)心客戶合作，團(tuán)隊(duì)之間的交流之類的

??各種敏捷框架、方法論和工具，就像是“術(shù)”，告訴你敏捷開發(fā)的方式，而敏捷則是“道”，是一套價(jià)值觀和原則，指導(dǎo)你在軟件項(xiàng)目開發(fā)中做決策。

什么是敏捷開發(fā)詳解2

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

• 產(chǎn)品經(jīng)理和客戶進(jìn)行了初步的溝通，把用戶的需求寫成了一個(gè)個(gè)用戶故事（用簡(jiǎn)單的用戶故事代替繁重的需求文檔），例如：

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

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

??敏捷開發(fā)對(duì)團(tuán)隊(duì)成員的要求較高，可能某個(gè)小功能從需求分析，設(shè)計(jì)，編碼，測(cè)試都需要你獨(dú)立開發(fā)，如果客戶不愿意配合你，那么敏捷開發(fā)也很難運(yùn)行起來

??其他幾個(gè)模型因?yàn)橛玫牟皇翘貏e多，增量模型，螺旋模型，用的不是特別多，所以這里只簡(jiǎn)單地列出他們?cè)谀男﹫?chǎng)景常見，其他的會(huì)把部分資料發(fā)到群里大家有空的時(shí)候一起學(xué)學(xué)吧。

小結(jié)

??根據(jù)項(xiàng)目特點(diǎn)，選擇好合適的開發(fā)模型，可以讓你事半功倍，降低項(xiàng)目風(fēng)險(xiǎn)，提高項(xiàng)目開發(fā)效率，控制項(xiàng)目成本。比如說：

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

---

• 快速原型模型：不見兔子不撒鷹。期初不考慮質(zhì)量、架構(gòu)，用最快的速度見效，并向用戶確認(rèn)需求。經(jīng)過幾輪直觀、快速的反饋，把需求確定下來。接下來，既可以拋棄原型用瀑布精密重構(gòu)，也可以在模型基礎(chǔ)上完善。優(yōu)點(diǎn)是快速有效的確認(rèn)需求。不足難以有效應(yīng)對(duì)后續(xù)的需求變更。

• 增量模型：分而治之。將大系統(tǒng)橫向拆分成相對(duì)獨(dú)立的若干小模塊，每個(gè)模塊采用瀑布模式分批次交付。優(yōu)點(diǎn)是較快見到成果，且能夠及時(shí)了解項(xiàng)目進(jìn)展。不足是存在需求明確、系統(tǒng)可拆分、交付可分批等適用條件。

• 迭代模型：羅馬不是一天建成。把軟件項(xiàng)目縱向劃分成若干階段，從核心功能入手，逐漸深化、細(xì)化，直到滿足用戶的全部需求。每個(gè)階段都是一個(gè)瀑布，都要在前一階段成果基礎(chǔ)上加工、打磨。優(yōu)點(diǎn)是快速滿足基本需要，并體會(huì)軟件演進(jìn)的快感。不足是需求演化具有不確定性，會(huì)導(dǎo)致代碼冗余、系統(tǒng)重構(gòu)風(fēng)險(xiǎn)、項(xiàng)目周期不可控。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。