也就是說，當你開發做決策的時候，遵守了敏捷開發的價值觀和原則，不管你是不是用 scrum 或者極限程式設計，那麼都可以算是敏捷開發。
瀑布模型的典型問題就是周期長、發布煩、變更難，敏捷開發就是快速迭代、持續整合、擁抱變化。
直到近些年，我完整的在日常專案中反覆實踐敏捷開發，才逐步領會到瀑布模型和敏捷開發的一些差別。這些年敏捷開發，已經逐步發展出一套 「scrum + 極限程式設計 + 看板」 的最佳實踐，scrum 主要用來管理專案過程，極限程式設計重點在工程實踐，而看板將工作流視覺化。我將基於 scrum 和極限程式設計的實踐，來對比一下敏捷開發模型和瀑布模型的差異。
敏捷開發是怎麼做需求分析的？
瀑布模型的乙個重要階段就是需求分析，要有嚴謹的需求分析，產生詳盡的需求分析文件。而敏捷開發的需求，主要是**於乙個個小的使用者故事，使用者故事通常是寫在卡片上的一句話，在 sprint 的開發中，再去確認需求的細節。比如乙個使用者登入**的需求，在使用者故事裡面就是一句話：作為使用者，我想登入**，這樣可以方便瀏覽。好處是減少了大量需求文件的撰寫，可以早些進入開發。但這個對開發人員在需求理解和溝通的能力上要求更高了。
3. 敏捷開發是怎麼做架構設計的？
瀑布模型在需求分析完了以後，就需要根據需求做架構設計。而在敏捷開發中，並不是基於完整的使用者需求開發，每個 sprint 只做一部分需求，所以是一種漸進式的架構設計，當前 sprint 只做適合當前需求的架構設計。這種漸進式的架構設計，迭代次數一多，就會出現架構滿足不了需求的現象，產生不少冗餘**，通常我們叫它技術債務，需要定期對系統架構進行重構。
5. 敏捷開發怎麼保證專案質量？
瀑布模型在編碼完成後，會有專門的階段進行測試，以保證質量。在敏捷開發的 sprint 中，並沒有專門的測試階段，這就依賴於開發功能的同時，要編寫單元測試和整合測試**，用自動化的方式輔助完成測試。相對來說，這種以自動化測試為主的方式，質量確實是要有些影響的。微軟的 windows 就是個很好的例子，在 windows 10 之前，windows 的開發模式是傳統的類瀑布模型，有很長一段測試的時間，質量有很好的保障，windows 10 開始，採用的是敏捷開發的模式，每月發布更新，穩定性要稍微差一些。
4. 敏捷開發是怎麼發布部署的？
瀑布模型通常在編碼結束後，開始部署測試環境，然後在測試階段定期部署測試環境。測試驗收通過後，發布部署到生產環境。在敏捷開發中，這種持續構建、持續發布的概念叫持續整合，因為整個過程都是全自動化的，每次完成乙個任務，提交**後都可以觸發一次構建部署操作，指令碼會拿最新的**做一次全新的構建，然後執行所有的單元測試和整合測試**，測試通過後部署到測試環境。持續整合是乙個非常好的實踐，極大的縮短和簡化了部署的流程，而且自動化測試的加入也很好的保證了部署產品的質量。前期搭建整個持續整合環境需要一定技術要求。
可以肯定，敏捷開發是一種非常好的軟體開發模式。但在應用上，也確實需要滿足一些條件才能用好，例如：
團隊要小，人數超過一定規模就要分拆；
團隊成員之間要緊密協作，客戶也要自始至終深度配合；
領導們的支援。
敏捷需要扁平化的組織結構，更少的控制，更多的發揮專案組成員的主動性；寫**時要有一定比例的自動化測試**，要花時間搭建好原始碼管理和持續整合環境。所以在選擇敏捷開發這個問題上，你先要參考上面這些條件。因為敏捷開發對專案成員綜合素質要求更高，做計畫要相對難一些。如果團隊大、客戶不配合、領導不支援，再好的敏捷方法也很難有效實踐起來。
《軟體工程之美》day5
瀑布模型算是現代軟體工程的起源，軟體工程的發展，很大部分都是構建於瀑布模型的基礎之上的。主要分為 6 個階段 問題的定義及規劃 這個階段是需求方和開發方共同確定軟體開發目標，同時還要做可行性研究，以確定專案可行。這個階段會產生需求文件和可行性研究報告。需求分析 對需求方提出的所有需求，進行詳細的分析...
軟體工程之敏捷過程
第五章 敏捷開發 敏捷的概念 敏捷軟體工程是哲學理念和一系列開發指南的綜合。這種哲學理念推崇 讓客戶滿意且盡早的增量發布 小而高度自主的專案團隊 非正式的方法 最小化軟體工程工作產品以及整體精簡開發。開發的指導方針強調超越分析和設計 儘管並不排斥這類活動 的發布，以及開發人員和客戶之間主動和持續的溝...
軟體工程 過程模型 敏捷開發
軟體的概念 軟體是在計算機系統支援下能夠完成特定功能和效能的程式 資料和相關文件 軟體 知識 程式 資料 文件 軟體危機 軟體危機是指落後的生方式無法滿足迅速增長的計算機需求，從而導致軟體開發和過程維護出現一系列嚴重問題的現象。軟體工程的概念 軟體工程定義的第一部分內容要求，軟體開發 維護 和執行的...