對從事專案管理的人員來說，敏捷已經成為一場席捲全國的風潮。但敏捷並不是什麼新事物，它已經有20多年的歷史。是不是所有的團隊都可以採用敏捷管理？敏捷是不是一個可以解決所有專案困境的萬能靈藥？
肯定不是。但敏捷確實是一種非常好的專案管理方法。敏捷團隊也確實擁有一些獨特的優勢。
在敏捷開發出現之前，瀑布模型是採用得最多的開發方式，但是隨著軟體需求的不斷增加和軟體規模的不斷擴大，瀑布模型逐漸地呈現出了種種弊端，主要有三個方面：
1、研發週期過長，導致研發跟不上業務發展的節奏；
2、研發不能很好地響應需求變化，導致客戶滿意度低；
3、不能很好地管控風險。
為了解決瀑布模型的弊端，敏捷呼之欲出。
一、什麼是敏捷管理？
先從字面上理解，敏捷一詞包含了兩層含義：
一是“靈活”——檢查調整，遊刃有餘；
二是“快速”——天下武功，唯快不破。
既滿足產品開發過程中需求的動態變化，又能透過短迭代管理監控專案的實時效果。究其本質而言，敏捷管理方法很簡單：就是“檢查與調整”迴圈。
舉個例子：
客人到餐館來點菜（新專案）
不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的選單（客戶往往提不出具體的需求）
根據圖文選單，客人點了十個菜（根據原型和設計稿，基本確定了需求）
後廚開始準備（專案啟動）
配菜、炒菜，先上了兩盤，讓客人嚐了嚐味道（先提供可用例項給客戶用）
客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）
上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）
又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）
到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）
客人吃完，很滿意（基本滿足了全部的要求）
二、適合用敏捷的情況
現在讓我們回到開頭的問題，什麼情況下適合用敏捷？
首先什麼情況下敏捷不是最佳選擇？比如需求基本是確定的。當專案具備可靠的歷史記錄作為開發基準時，最好採用瀑布式開發方法。
適用敏捷的情況可能比較多，我們列舉幾個主要的情況，歡迎大家補充：
1、產品需求不確定時
這種情況下，敏捷可以使專案更快啟動，並讓產品負責人參與到開發過程中。用敏捷的方式，我們就不用在不確定客戶是否會滿意的情況下花時間記錄產品需求，負責人可以在開發新產品功能時，把客戶反饋作為開發過程的一部分，以最快的速度將功能呈現，以最小的代價進行試錯。
2、敏捷是最佳選擇時
因為軟體開發過程本身就允許整個系統中的部分功能先進行開發、測試和交付。這就意味著某些特定功能的交付時間會早於其他功能。敏捷則允許開發團隊單獨測試和部署這些功能，從而確保開發效率。
3、管理層支援時
在傳統的開發團隊中，專案經理需要提供明確的方向。而在敏捷開發中，敏捷教練則會鼓勵開發團隊提出最適合產品開發和產品負責人的方案。管理層必須賦予團隊必要的自由，要提供能讓團隊快速成長的指導和方向，而不是控制團隊的每一步行動。
敏捷可以為企業帶來文化和期望層面的轉變，因為它鼓勵團隊賦權，讓團隊負責做出決策並承擔相應的風險。敏捷為專案經理提供了更多的選擇，幫助其解決專案進度中的各類問題，讓他們有可能更好地管理專案。
4、團隊成員擁有從失敗中學習的意願時
快速試錯，更快速地從失敗中學習。傳統的開發方式試圖在專案啟動前描述所有的需求，這麼做會浪費大量時間，尤其是在開發新產品時。所以一旦有了想法就應該立刻進行開發，即使當前的產品並非產品負責人想要的。這樣做的目的是要透過不斷的反饋來調整產品方向並繼續開發。
