目錄
我們在開發項目的時候常常會用軟件工程方面的設計模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型
這裏將簡單說一下：快速原型模型、瀑布模型、增量模型這3個常用的
還有現在比較火的敏捷模型，敏捷開發，越來越多人使用了。
本章節主要是講 敏捷模型
前言
關於敏捷開發的實際應用，現在無外乎有以下幾種常見的情形：
- 很多團隊想敏捷開發，但不知道該怎麼上手；
- 有的團隊已經應用了一些敏捷開發的實踐，然而效果不理想，不知道是敏捷開發的問題，還是自己實踐方式不得當；
- 有的團隊聽說了敏捷開發，但是並不知道它是什麼。
爲什麼會這樣呢？今天我們就圍繞敏捷開發來談一談，看看敏捷開發是什麼，能幫助我們解決哪些問題，要不要實施敏捷開發，以及怎麼能應用好敏捷開發。
一、什麼是敏捷開發？
那什麼是敏捷開發呢？有人認爲：
- 敏捷開發就是 Scrum、極限編程；
- 敏捷開發就是每天站立會議、每兩週一個 Sprint（字面意思是衝刺，可以理解爲迭代）；
- 敏捷開發就是把需求變成故事，把故事寫在便籤上貼到白板，然後根據狀態移動到不同的列；
- 敏捷開發就是用看板軟件來管理項目。
然而，這些是敏捷開發的真正含義嗎？
要理解敏捷開發，我們先要了解其誕生背景。在 2001 年那會，瀑布模型還是主流，我們知道，瀑布模型是一種“重型”的開發模式，整個流程走完通常週期很長，少則數月，多則數年。長週期導致風險增加、難以響應變化。
於是由瀑布模型衍生出很多模型，試圖去改善瀑布模型存在的問題，我已經在上一篇文章中給你介紹了一些。不過除了介紹的那些以外，在當時還有一些不怎麼有名，而現在卻如雷貫耳的輕量級開發方法，例如極限編程（Extreme Programming，XP）、Scrum 等。
2001 初，17 位代表上述各種輕量級軟件開發過程流派的領軍人物聚集在一起，討論替代瀑布模型這種重量級軟件開發過程的新方法。
但是沒能達成一致，所以退而求其次，把大家都認同的理念整理出來，也就是後來的敏捷宣言。這些人還一起成立了敏捷聯盟。
（圖片來源：敏捷開發宣言）
我們再回頭來看前面大家對敏捷的定義，其實都是在從方法論、工具等方面解釋敏捷開發。而敏捷宣言指出：
敏捷不是一種方法論，也不是一種軟件開發的具體方法，更不是一個框架或過程，而是一套價值觀和原則。
現實中關於敏捷的討論，更多的是在討論各種方法論和工具。不可否認，這些方法論和工具，能幫助團隊“敏捷”起來，但它們和敏捷開發之間的關係，更像是“術”和“道”的關係。
各種敏捷框架、方法論和工具，就像是“術”，告訴你敏捷開發的方式，而敏捷則是“道”，是一套價值觀和原則，指導你在軟件項目開發中做決策。
這麼說還是比較抽象，我給你舉個例子。
敏捷開發中流行的站立會議，主要目的是爲了保證團隊成員充分的溝通，遇到困難可以及時尋求幫助。但是如果每天的站立會議流於形式，並不能起到有效的目的，則應該減少頻度，甚至取消換成其他方式。
要不要在你的項目開發中使用站立會議，判斷的依據就在於這樣做是不是符合敏捷的價值觀和原則。
也就是說，當你開發做決策的時候，遵守了敏捷開發的價值觀和原則，不管你是不是用 Scrum 或者極限編程，那麼都可以算是敏捷開發。
二、敏捷開發想解決什麼問題？
如果你讀仔細讀了敏捷宣言，你會發現，宣言中右邊的內容其實都是瀑布模型核心的內容：流程和工具、詳盡的文檔、合同談判、遵循計劃。
雖然敏捷開發並未對瀑布模型的價值進行否定，但也表明了瀑布模型做的還不夠好，同時提出了一套自己的價值觀。
比如說，我們開始做一個新項目，需要從客戶那裏收集整理需求，如果按照傳統的軟件開發模式，我們需要在開發前獲得所有需求，然後和客戶簽訂合同，在發佈前都不會輕易修改需求。
但是如果我們採用敏捷開發模式來開發項目，那這樣做顯然違背敏捷的價值觀：“客戶合作高於合同談判”。
所以如果是敏捷開發，在每個迭代後，都應該向客戶收集反饋，然後在後面的迭代中，酌情加入客戶反饋修改的內容。
結合敏捷開發提出的背景，你其實不難發現，敏捷開發就是想解決瀑布模型這樣的重型軟件開發方法存在的問題，用一種輕量的、敏捷的方法來改善甚至是替代它。
這些年敏捷開發也是一直這麼做的。瀑布模型的典型問題就是週期長、發佈煩、變更難，敏捷開發就是快速迭代、持續集成、擁抱變化。
三、如果用敏捷的方式蓋房子
在講瀑布模型的時候，我拿蓋房子舉了個例子，如果改成用敏捷開發的模式蓋房子，則會是這樣子的：
- 客戶想要蓋一棟房子（初步的想法）。
- 產品經理和客戶進行了初步的溝通，把用戶的需求寫成了一個個用戶故事（用簡單的用戶故事代替繁重的需求文檔），例如：
作爲一個上班族，我想要一個臥室，以便於休息；
作爲一個家庭主婦，我想要一個廚房，以便於做飯。
- 施工人員根據用戶故事和客戶進一步溝通（客戶合作高於合同談判），然後對用戶故事進行設計和實現；
- 每個用戶故事開發時，還要給一個測試機器人編寫測試腳本，讓機器人可以自動測試（大量採用自動化測試），並且做好的用戶故事可以隨時被測試驗收（隨時發佈，持續集成）；
- 每個 Sprint 四個星期時間（時間盒子，迭代時間固定）；
- 第一個 Sprint 搭了個草棚，一張牀就是臥室，廁所就挖了一個坑，廚房還來不及搭建（每個 Sprint 會選擇高優先級的用戶故事），屋頂還在漏水（每個 Sprint 會定期發佈，客戶可以隨時看到可用版本，即使還不完整）；
- 第二個 Sprint 有了簡易廚房，同時修復了屋頂漏水的毛病（每個 Sprint 不僅完成用戶故事，還會修復 Bug）；
- 第三個 Sprint 升級成了小木屋，但是忘記加上窗戶（敏捷推崇自動化測試，但可能會測試不完備）；
- 第四個 Sprint 升級成了磚瓦房，窗戶也開好了，客戶可以入住。但是這時候客戶發現一家三口的話，完全不夠用，需要擴建到 3 個臥室。於是決定下個迭代改成 3 個臥室（響應變化高於遵循計劃）；
- 第五個 Sprint，升級成了 3 個臥室，升級過程中把廚房下水道弄壞了（迭代過程中可能會導致質量不穩定）；
- 第六個 Sprint，修復了下水道的問題，房子也裝修好了（迭代中不斷完善）；
- 客戶驗收使用（上線）。
用敏捷開發的方式，不再像瀑布模型那樣有嚴格的階段劃分，會在迭代中不斷完善；不再寫很多文檔，而是和客戶一起緊密合作；不再抵制需求變更，而是即時響應變更；不再等到測試階段才發佈，而是隨時發佈，客戶隨時可以看到東西。
當然，採用敏捷開發的模式也存在一些問題，例如全程需要客戶參與，由於測試相對少一些 ，問題也會相應多一些。
四、敏捷開發和瀑布模型的差異
小明讀大學時學的就是瀑布模型，畢業後很多年的項目開發都是以瀑布模型爲主的，所以我在剛開始去看敏捷開發，總會以瀑布模型的方式類比敏捷開發，實踐的時候也難以擺脫瀑布模型的影響。
直到近些年，我完整的在日常項目中反覆實踐敏捷開發，才逐步領會到瀑布模型和敏捷開發的一些差別。
這些年敏捷開發，已經逐步發展出一套 “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 的節奏是比較恆定，產品也是相對穩定的，即使用戶故事沒有完成，也不影響版本的發佈。
因此，敏捷開發更注重軟件開發中人的作用，需要團隊成員以及客戶之間的緊密協作。
五、該不該選擇敏捷開發？
該不該選擇敏捷開發，是很多團隊糾結的問題。畢竟關於敏捷，有很多在中國落地失敗的例子，是不是這種方法在國內水土不服？
其實，敏捷開發無論國內還是國外，大廠還是小廠，都已經有無數成功案例。這些年，軟件工程中一些好的實踐，像持續集成、測試驅動開發、結對編程、看板等都來自於敏捷開發。可以肯定，敏捷開發是一種非常好的軟件開發模式。
但在應用上，也確實需要一些滿足一些條件才能用好，例如：
- 團隊要小，人數超過一定規模就要分拆；
- 團隊成員之間要緊密協作，客戶也要自始至終深度配合；
- 領導們得支持。敏捷需要扁平化的組織結構，更少的控制，更多的發揮項目組成員的主動性；
- 寫代碼時要有一定比例的自動化測試代碼，要花時間搭建好源碼管理和持續集成環境。
所以在選擇敏捷開發這個問題上，你先要參考上面這些條件。
因爲敏捷開發對項目成員綜合素質要求更高，做計劃要相對難一些。如果團隊大、客戶不配合、領導不支持，再好的敏捷方法也很難有效實踐起來。
如果你要實踐敏捷開發，建議先找個小項目進行試點，能證明可行了，再進一步推廣。有條件的話，可以和一些顧問公司合作，請人做專門的培訓和指導。
如果不具備條件，應該考慮先把其中一些好的實踐用起來，比如說持續集成、每日站會、自動化測試等。
總結
我們今天一起學習了什麼是敏捷開發，也就是敏捷開發是一套價值觀和原則。也對比了瀑布模型和敏捷開發，其中的差異還是很大的。
瀑布模型面向的是過程，而敏捷開發面向的是人。敏捷開發要解決的，恰恰是瀑布模型中存在的一些問題。
最後，在要不要用敏捷開發這個問題上，不用過於糾結，看好敏捷開發，那就放心去用，覺得時機還不成熟、還不夠了解，就先試點或者只是先借鑑其好的實踐。
軟件開發，最核心的是人，而不是用什麼方法，以前沒有敏捷開發只有瀑布模型的時候，也一樣誕生了大量偉大的軟件，像 Windows、Office。現在有敏捷開發，更多的是讓我們多了一些選擇。