敏捷開發是一種從1990年開始逐漸引起人們廣泛關注的新型軟體開發方式，它是具有應對快速變化的需求的軟體開發能力。相對於非敏捷開發，它是一種以使用者需求為核心，持續迭代，循序漸進的開發方式。敏捷絕非某一種特定的開發方法，它只是一種應對快速變化的需求的一種軟體開發能力。所以敏捷開發並不在意需求是否變更，即便是在專案開發的後期，敏捷開發依然樂於接受需求的變更。這一點對於取得客戶的滿意度來說，無疑是非常具有競爭力的。

敏捷開發有幾個重要的特點:

1.不是是單純的快，而是靈活，要避免踏入欲速而不達的坑。要開展最小化驗證，推行小步快跑，最小化驗證並不是強調迭代節奏要快，很多人都誤解了，而是強調靈活，船小好調頭；儘可能當週清理技術債務，技術債務越多後面越難清理。

2.為了足夠靈活，就應該儘量減少人員的複用，所以只要是需要消耗時間的工作都應該放在迭代中，比如改bug、程式設計和評審、程式碼評審、效能最佳化、市場反饋問題改善等和技術強相關的工作；

3.讓專案儘量透明，敏捷開發可以理解為是將瀑布流開發拆分為若干個小的瀑布流開發，這樣做的目的是讓專案足夠靈活，即使有需求變動也能夠快速調整，在迭代中消化；如果不能做到專案透明，會導致技術債務堆積、存在潛在的問題、專案進度的延遲，如果不能保證產品的穩定和迭代進度，那脫離了目標的敏捷就沒什麼意義了；

4.客觀看待《敏捷宣言》，敏捷開發仍然需要規範和流程要相信規範和流程對人的約束，減少不必要的溝通和無意義的工作；敏捷宣言中的“個體和互動高於流程和工具”，好的流程和工具可以提高工作效率、減少溝通成本，並且可以實現敏捷開發並不一定對人要求高；敏捷宣言中“工作的軟體高於詳盡的文件”可能適合於整個敏捷團隊，但不適合於開發人員，關於程式設計、流程圖、資料結構、ReadMe等還是有必要有詳細的文件的，起碼能夠讓自己加深對需求的理解、方便他人接手工作

什麼是敏捷軟體開發？CORNERSTONE敏捷開發使用者在此分享下我個人對敏捷開發的一些理解。1、先來一張導圖2、概念

簡單的說，敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。

換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

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

3、優勢

敏捷開發屬於增量式開發，對於需求範圍不明確，需求變更較多的專案而言，可以很大程度上響應及擁抱變化。對於網際網路產品而言，市場風向轉變很快，需要一種及時快速的交付形式，而敏捷開發則能更好地適用於此。敏捷開發可最大程度體現80/20法則的價值，透過增量迭代，每次都優先交付那能產生80%價值效益的20%功能。能最大化單位成本收益。

4、誤區5、特點6、核心原則7、敏捷開發與瀑布模型開發

瀑布模型開發

敏捷開發

某博主po的一個很有趣的“敏捷和瀑布”對比例子，給大家作為閱讀參考：

7.1、敏捷開發

客人到餐館來點菜（新專案）不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）根據圖文選單，客人點了十個菜（根據原型和設計稿，基本確定了需求）後廚開始準備（專案啟動）配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用例項給客戶用）客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）客人吃完，很滿意（基本滿足了全部的要求）

7.2、瀑布模型開發

客人到餐館來點菜（新專案）不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）根據圖文選單，客人點了十個菜（根據原型和設計稿，基本確定了需求）後廚開始準備（專案啟動）根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）半個小時了，菜還沒上桌，客人餓極了（專案啟動後很長一段時間客戶什麼都看不到）再過了二十分鐘，十個菜都一起上來了（專案最終一次交付）客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）這時候大堂經理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）於是，後廚只給客戶加了鹽，加了辣客人吃完，不是很滿意，下次不來了（沒有滿足需求）

8、總結

但總的來說，在現在管理專案過程中，並沒有嚴格的按照完全的敏捷或者完全的瀑布模式，都是各自摻雜了其他的方式。在實際專案過程中，過於強調模式並沒有意義，重要的是能不能預防問題的發生，在問題發生之後能不能用最小的成本解決，模式更多起一個參考作用。