一.關於敏捷開發的概念
敏捷開發的思想自進入國內以來，已經經過多年的發展，概念也不斷完善，通常認爲這是一種以人爲核心、迭代、循序漸進的開發方法。
在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。也就是說把一個整體的大項目分成多個相互聯繫的但又可以獨立運行的小項目，並根據計劃分別完成，並保證軟件在此過程中一直處於可用狀態，這就是其迭代式開發的特色。
二.敏捷開發的優勢
敏捷開發確實是項目進入實質開發迭代階段，用戶很快可以看到一個基線架構版的產品。敏捷注重市場快速反應能力，也即具體應對能力，客戶前期滿意度高。
1、敏捷開發屬於增量式開發，對於需求範圍不明確，需求變更較多的項目而言，可以很大程度上響應及擁抱變化。
2、對於互聯網產品而言，市場風向轉變很快，需要一種及時快速的交付形式，而敏捷開發則能更好地適用於此。
3、敏捷開發可最大程度體現80/20法則的價值，通過增量迭代，每次都優先交付那能產生80%價值效益的20%功能，能最大化單位成本收益。
三、誤區
關於敏捷開發應當認爲是一種輕量級、高效的平臺，而不是純粹的越快越好。
四、特點
1. 個體和交互勝過過程和工具
2.可以工作的軟件勝過面面俱到的文檔（但並非不需要文檔）
3. 客戶合作勝過合同談判
4.響應變化勝過遵循計劃
五、核心原則
1.主張簡單
2.擁抱變化
3.第二個目標是可持續性
4.遞增的變化
5.令投資最大化
6.有目的的建模
7.多種模型
8.高質量的工作
9.快速反饋
10.軟件是你的主要目標
11.輕裝前進
六、敏捷開發與瀑布模型開發
瀑布模型開發
敏捷開發
曾經有大牛分享了一個很有趣的“敏捷和瀑布”的例子，這裏拿來一起分享。
1、敏捷開發
客人到餐館來點菜（新項目）不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的菜單（客戶往往提不出具體的需求）根據圖文菜單，客人點了10個菜（根據原型和設計稿，基本確定了需求）後廚開始準備（項目啓動）配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用實例給客戶用）客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）客人吃完，很滿意（基本滿足了全部的要求）。
2、瀑布模型開發
客人到餐館來點菜（新項目）不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的菜單（客戶往往提不出具體的需求）根據圖文菜單，客人點了十個菜（根據原型和設計稿，基本確定了需求）後廚開始準備（項目啓動）根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）半個小時了，菜還沒上桌，客人餓極了（項目啓動後很長一段時間客戶什麼都看不到）再過了二十分鐘，十個菜都一起上來了（項目最終一次交付）客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）這時候大堂經理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）於是，後廚只給客戶加了鹽，加了辣客人吃完，不是很滿意，下次不來了（沒有滿足需求）。
七、總結
就目前來看，在實際管理項目的過程中，大多數並沒有嚴格的按照敏捷或瀑布模式，都是各自摻雜了其他的方法，因爲在實際項目的過程中，過於強調模式意義不大，重要的是能不能預防問題的發生或者在問題出現之後能不能以最小的成本解決，而模式更多的是起到一個參考作用，“實際大於主義”。
Learun（力軟）近十年來一直專注于敏捷開發框架的研發，目前v7.0經典框架已經在各行各業得到應用，適用於OA、ERP、CRM、BI、BPM、HRM、SAAS、移動app、電商系統後臺等多種企業信息系統，歡迎體驗指正：www.learun.cn.