0、先來一張導圖
1、概念
簡單的說，敏捷開發是一種以人爲核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。
換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。
敏捷最大的特色是迭代式開發。
2、優勢
1、敏捷開發屬於增量式開發，對於需求範圍不明確，需求變更較多的項目而言，可以很大程度上響應及擁抱變化。
2、對於互聯網產品而言，市場風向轉變很快，需要一種及時快速的交付形式，而敏捷開發則能更好地適用於此。
3、敏捷開發可最大程度體現80/20法則的價值，通過增量迭代，每次都優先交付那能產生80%價值效益的20%功能。能最大化單位成本收益。
3、誤區
4、特點
5、核心原則
6、捷開發與瀑布模型開發
某博主po的一個很有趣的“敏捷和瀑布”對比例子，給大家作爲閱讀參考：
6.1、敏捷開發
-
客人到餐館來點菜（新項目）
-
不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的菜單（客戶往往提不出具體的需求）
-
根據圖文菜單，客人點了是個菜（根據原型和設計稿，基本確定了需求）
-
後廚開始準備（項目啓動）
-
配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用實例給客戶用）
-
客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）
-
上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）
-
又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）
-
到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）
-
客人吃完，很滿意（基本滿足了全部的要求）
6.2、瀑布模型開發
-
客人到餐館來點菜（新項目）
-
不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的菜單（客戶往往提不出具體的需求）
-
根據圖文菜單，客人點了十個菜（根據原型和設計稿，基本確定了需求）
-
後廚開始準備（項目啓動）
-
根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）
-
半個小時了，菜還沒上桌，客人餓極了（項目啓動後很長一段時間客戶什麼都看不到）
-
再過了二十分鐘，十個菜都一起上來了（項目最終一次交付）
-
客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）
-
這時候大堂經理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）
-
於是，後廚只給客戶加了鹽，加了辣
-
客人吃完，不是很滿意，下次不來了（沒有滿足需求）
7、總結
但總的來說，在現在管理項目過程中，並沒有嚴格的按照完全的敏捷或者完全的瀑布模式，都是各自摻雜了其他的方式。在實際項目過程中，過於強調模式並沒有意義，重要的是能不能預防問題的發生，在問題發生之後能不能用最小的成本解決，模式更多起一個參考作用
最後借用民國時候的一句話：少研究一些主義，多關注一些實際問題
歡迎關注java思維導圖。
