敏捷開發思惟導圖，讓java再也不難懂

0、先來一張導圖

一、概念

簡單的說，敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。

換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。

敏捷最大的特點是迭代式開發。

二、優點

一、敏捷開發屬於增量式開發，對於需求範圍不明確，需求變動較多的項目而言，能夠很大程度上響應及擁抱變化。

二、對於互聯網產品而言，市場風向轉變很快，須要一種及時快速的交付形式，而敏捷開發則能更好地適用於此。

三、敏捷開發可最大程度體現80/20法則的價值，經過增量迭代，每次都優先交付那能產生80%價值效益的20%功能。能最大化單位成本收益。

三、誤區

四、特色

五、核心原則

六、捷開發與瀑布模型開發

某博主po的一個頗有趣的「敏捷和瀑布」對比例子，給你們做爲閱讀參考：

6.一、敏捷開發

• 客人到餐館來點菜（新項目）

• 不肯定客戶想吃什麼的時候，一般選好餐廳後會先看看餐廳的菜單（客戶每每提不出具體的需求）

• 根據圖文菜單，客人點了是個菜（根據原型和設計稿，基本肯定了需求）

• 後廚開始準備（項目啓動）

• 配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用實例給客戶用）

• 客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）

• 上菜過程當中，客人忽然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，能夠不斷測試和需求變動）

• 又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提早明確，反覆迭代，增長了工做量）

• 到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變動）

• 客人吃完，很滿意（基本知足了所有的要求）

6.二、瀑布模型開發

• 客人到餐館來點菜（新項目）

• 不肯定客戶想吃什麼的時候，一般選好餐廳後會先看看餐廳的菜單（客戶每每提不出具體的需求）

• 根據圖文菜單，客人點了十個菜（根據原型和設計稿，基本肯定了需求）

• 後廚開始準備（項目啓動）

• 根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）

• 半個小時了，菜還沒上桌，客人餓極了（項目啓動後很長一段時間客戶什麼都看不到）

• 再過了二十分鐘，十個菜都一塊兒上來了（項目最終一次交付）

• 客人說，有幾個菜挺好的，可是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）

• 這時候大堂經理來了，說，「味道淡了能夠加鹽，不辣能夠加辣，可是換菜不行，已經炒好的那兩盤菜也是要算成本的」（瀑布的壞處，需求變動比較麻煩）

• 因而，後廚只給客戶加了鹽，加了辣

• 客人吃完，不是很滿意，下次不來了（沒有知足需求）

七、總結

但總的來講，在如今管理項目過程當中，並無嚴格的按照徹底的敏捷或者徹底的瀑布模式，都是各自摻雜了其餘的方式。在實際項目過程當中，過於強調模式並無意義，重要的是能不能預防問題的發生，在問題發生以後能不能用最小的成本解決，模式更多起一個參考做用

最後借用民國時候的一句話：少研究一些主義，多關注一些實際問題

歡迎關注java思惟導圖。