文章目錄

• • 1.什么是敏捷開發？
  • 2.敏捷開發宣言
  • 3.站立會議的意義
  • 4.敏捷開發想解決什么問題？
  • 5.如果用敏捷的方式蓋房子
  • 6.敏捷開發和瀑布模型的差異
  • • （1）敏捷開發是怎么做需求分析的？
    • （2）敏捷開發是怎么做架構設計的？
    • （3）敏捷開發怎么保證項目質量的？
    • （4）敏捷開發是怎么發布部署的？
    • （5）敏捷開發的 Sprint 和迭代模型的迭代有什么區別？
  • 7.該不該選擇敏捷開發？
  • 8.總結

---

1.什么是敏捷開發？

• 敏捷開發，基于迭代的開發模型，它也強調快速交付，每次交付系統的部分功能，來保證客戶滿意度。在敏捷開發中，系統交付的周期稱之為·沖刺（Sprint）。
• • 敏捷開發，在每個迭代后，都應該向客戶收集反饋，然后在后面的迭代中，酌情加入客戶反饋修改的內容。
• 嚴格來說，敏捷開發并不算是一種開發模型，更像是框架或指南。有各種開發模型來實現敏捷開發，比如說·極限編程（Extreme programming），看板（Kanban）和 Scrum。

有人是這樣理解敏捷開發模型的：

• 敏捷開發就是 Scrum、極限編程；
• 敏捷開發就是每天站立會議、每兩周一個 Sprint（字面意思是沖刺，可以理解為迭代）；
• 敏捷開發就是把需求變成故事，把故事寫在便簽上貼到白板，然后根據狀態移動到不同的列；
• 敏捷開發就是用看板軟件來管理項目。

然而，這些是敏捷開發的真正含義嗎？

2.敏捷開發宣言

• 2001 初，17 位代表上述各種輕量級軟件開發過程流派的領軍人物聚集在一起，討論替代瀑布模型這種重量級軟件開發過程的新方法。
• 但是沒能達成一致，所以退而求其次，把大家都認同的理念整理出來，也就是后來的敏捷宣言。這些人還一起成立了敏捷聯盟。
  
  我們再回頭來看前面大家對敏捷的定義，其實都是在從方法論、工具等方面解釋敏捷開發。
• 敏捷宣言指出：

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

3.站立會議的意義

• 敏捷開發中流行的站立會議，主要目的是為了保證團隊成員充分的溝通，遇到困難可以及時尋求幫助。但是如果每天的站立會議流于形式，并不能起到有效的目的，則應該減少頻度，甚至取消換成其他方式。

• 要不要在你的項目開發中使用站立會議，判斷的依據就在于這樣做是不是符合敏捷的價值觀和原則。

• 也就是說，當你開發做決策的時候，遵守了敏捷開發的價值觀和原則，不管你是不是用 Scrum 或者極限編程，那么都可以算是敏捷開發。

4.敏捷開發想解決什么問題？

• 瀑布模型的典型問題就是周期長、發布煩、變更難，
• 敏捷開發就是快速迭代、持續集成、擁抱變化·

5.如果用敏捷的方式蓋房子

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

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

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

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

用敏捷開發的方式，不再像瀑布模型那樣有嚴格的階段劃分，會在迭代中不斷完善；不再寫很多文檔，而是和客戶一起緊密合作；不再抵制需求變更，而是即時響應變更；不再等到測試階段才發布，而是隨時發布，客戶隨時可以看到東西。

當然，采用敏捷開發的模式也存在一些問題，例如全程需要客戶參與，由于測試相對少一些 ，問題也會相應多一些。

6.敏捷開發和瀑布模型的差異

• 這些年敏捷開發，已經逐步發展出一套 “Scrum + 極限編程 + 看板” 的最佳實踐，
• Scrum 主要用來管理·項目過程，
• 極限編程重點在工程實踐，
• 而看板將工作流可視化。

基于 ·Scrum 和極限編程的實踐，來對比一下敏捷開發模型和瀑布模型的差異

（1）敏捷開發是怎么做需求分析的？

瀑布模型的一個重要階段就是需求分析，要有嚴謹的需求分析，產生詳盡的需求分析文檔。而敏捷開發的需求，主要是來源于一個個小的用戶故事，用戶故事通常是寫在卡片上的一句話，在 Sprint 的開發中，再去確認需求的細節。

比如一個用戶登錄網站的需求，在用戶故事里面就是一句話：
作為用戶，我想登錄網站，這樣可以方便瀏覽。

好處是減少了大量需求文檔的撰寫，可以早些進入開發。但這個對開發人員在需求理解和溝通的能力上要求更高了。

（2）敏捷開發是怎么做架構設計的？

瀑布模型在需求分析完了以后，就需要根據需求做架構設計。而在敏捷開發中，并不是基于完整的用戶需求開發，每個 Sprint 只做一部分需求，所以是一種漸進式的架構設計，當前 Sprint 只做適合當前需求的架構設計。

這種漸進式的架構設計，迭代次數一多，就會出現架構滿足不了需求的現象，產生不少冗余代碼，通常我們叫它技術債務，需要定期對系統架構進行重構。

（3）敏捷開發怎么保證項目質量的？

瀑布模型在編碼完成后，會有專門的階段進行測試，以保證質量。在敏捷開發的 Sprint 中，并沒有專門的測試階段，這就依賴于開發功能的同時，要編寫單元測試和集成測試代碼，用自動化的方式輔助完成測試。

相對來說，這種以自動化測試為主的方式，質量確實是要有些影響的。

微軟的 Windows 就是個很好的例子，在 Windows 10 之前，Windows 的開發模式是傳統的類瀑布模型，有很長一段測試的時間，質量有很好的保障，Windows 10 開始，采用的是敏捷開發的模式，每月發布更新，穩定性要稍微差一些。

（4）敏捷開發是怎么發布部署的？

瀑布模型通常在編碼結束后，開始部署測試環境，然后在測試階段定期部署測試環境。測試驗收通過后，發布部署到生產環境。

在敏捷開發中，這種持續構建、持續發布的概念叫持續集成，因為整個過程都是全自動化的，每次完成一個任務，提交代碼后都可以觸發一次構建部署操作，腳本會拿最新的代碼做一次全新的構建，然后運行所有的單元測試和集成測試代碼，測試通過后部署到測試環境。

持續集成是一個非常好的實踐，極大的縮短和簡化了部署的流程，而且自動化測試的加入也很好的保證了部署產品的質量。前期搭建整個持續集成環境需要一定技術要求。

（5）敏捷開發的 Sprint 和迭代模型的迭代有什么區別？

我們假設有兩個團隊，都要實現一個簡單的用戶系統，

• 一個團隊用迭代模型，
• 一個團隊用敏捷開發（Scrum），
• 一個迭代 /Sprint 的時間周期都是 2 周（10 個工作日）。

迭代模型所在的團隊，產品經理會先花 2 天時間去分析需求，寫成需求分析文檔，架構師會花 3 天時間來做設計，程序員會花 3 天時間編碼，測試再花 2 天時間去測試，最后上線用戶系統。

再看敏捷開發的團隊，Product Owner（類似于產品經理）會把需求拆分成了幾個簡單的用戶故事：用戶登錄、用戶注冊、找回密碼、修改資料，然后放到當前 Sprint 的 Backlog（任務清單），Team（開發團隊）成員開始從 Backlog 選擇用戶故事。

• 程序員 A 選了“用戶登錄”這個用戶故事，他會去找 Product Owner 確認需求細節，之后動手實現這個用戶故事。

• 功能完成后，同時程序員 A 還寫了單元測試代碼和集成測試代碼，對登錄的功能寫了自動化測試。完成后，通過持續集成工具測試和部署到測試環境。部署完成后，用戶登錄功能就可以進行使用了。

• 這個過程，程序員 A 可能花了 4 天時間，做完“用戶登錄”這個用戶故事之后，他又開始繼續選取“找回密碼”的用戶故事來做，4 天時間也完成了。

• 其他程序員也和程序員 A 一樣，他們也會從 Backlog 選擇一些用戶故事來做。

• 當團隊中第 1 個用戶故事部署完之后，測試人員就開始幫助測試，發現的 Bug 都提交到了 Backlog，程序員們在完成用戶故事后，開始著手修復這些 Bug，正好在最后 2 天都修復完成。

從上面的例子，你可以看出，迭代模型本質上是一個小瀑布模型，所以在一個迭代里面，需要完整的經歷從需求分析，到設計、編碼、測試這幾個完整的階段。

• 所以像瀑布模型一樣，剛開始測試的時候是不穩定的，到測試后期才逐步穩定下來，一般迭代前期也會相對輕松一點，而后期測試階段可能會時間很緊張。

• 敏捷開發的 Sprint 中，沒有嚴格的階段劃分，每個 Sprint 周期里面會完成多個用戶故事。在用戶故事的開發時，會針對用戶故事有編碼、自動化測試編碼。當一個用戶故事開發完成，即可通過持續集成自動發布到測試環境。

• 相對來收，敏捷開發中，整個 Sprint 的節奏是比較恒定，產品也是相對穩定的，即使用戶故事沒有完成，也不影響版本的發布。

• 因此，敏捷開發更注重軟件開發中人的作用，需要團隊成員以及客戶之間的緊密協作。

7.該不該選擇敏捷開發？

這些年，軟件工程中一些好的實踐，像持續集成、測試驅動開發、結對編程、看板等都來自于敏捷開發。可以肯定，敏捷開發是一種非常好的軟件開發模式。

但在應用上，也確實需要一些滿足一些條件才能用好，例如：

• 團隊要小，人數超過一定規模就要分拆；
• 團隊成員之間要緊密協作，客戶也要自始至終深度配合；
• 領導們得支持。敏捷需要扁平化的組織結構，更少的控制，更多的發揮項目組成員的主動性；
• 寫代碼時要有一定比例的自動化測試代碼，要花時間搭建好源碼管理和持續集成環境。

所以在選擇敏捷開發這個問題上，你先要參考上面這些條件。

因為·敏捷開發對項目成員綜合素質要求更高，做計劃要相對難一些。如果團隊大、客戶不配合、領導不支持，再好的敏捷方法也很難有效實踐起來。

如果你要實踐敏捷開發，建議先找個小項目進行試點，能證明可行了，再進一步推廣。有條件的話，可以和一些顧問公司合作，請人做專門的培訓和指導。

如果不具備條件，應該考慮先把其中一些好的實踐用起來，比如說持續集成、每日站會、自動化測試等。

8.總結

瀑布模型面向的是過程，而敏捷開發面向的是人。敏捷開發要解決的，恰恰是瀑布模型中存在的一些問題。

最后，在要不要用敏捷開發這個問題上，不用過于糾結，看好敏捷開發，那就放心去用，覺得時機還不成熟、還不夠了解，就先試點或者只是先借鑒其好的實踐。

·軟件開發，最核心的是人，而不是用什么方法·，以前沒有敏捷開發只有瀑布模型的時候，也一樣誕生了大量偉大的軟件，像 Windows、Office。現在有敏捷開發，更多的是讓我們多了一些選擇。

附上一個鏈接補充：https://mp.weixin.qq.com/s/puMNz91hiQgio4wSCIrTgQ

參考：極客時間—軟件工程之美

總結

以上是生活随笔為你收集整理的105.敏捷开发模型的全部內容，希望文章能夠幫你解決所遇到的問題。

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