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