自二十多年前推出以來，敏捷產品開發實踐已大受歡迎。雖然這些實踐得到了廣泛的接受，但肯定有人在實踐中挑戰和質疑這些方法。
有太多太多的原因讓人們追捧「敏捷開發」，這些追捧既有目的性極強的也有無腦跟風的。我在好多論壇或者交流群也見過有人問關於自己的團隊適不適合「敏捷開發」的問題。所以今天，我來說說究竟什麼樣的團隊才適合「敏捷開發」。
1. 小團隊
這點應該毋庸置疑。從生活經驗上來看，小動物一般用敏捷來形容，比如兔子、貓（當然，大動物也有，如：這頭豬真胖，但它竟然還這麼敏捷）。
小團隊不會出現大團隊那種尾大不掉的情況，「敏捷開發」進度可能每天都會變化，小團隊有著更低的管理成本，產品經理可以很好的把控整個團隊節奏。當然，小團隊也是要五臟俱全的。
2. 需求聚焦
如前文所說，大家採用「敏捷開發」肯定是有目的的。不管什麼目的，肯定是為了快速響應、快速上線。這時，產品需求一定要聚焦、再聚焦。
有太多團隊都是開發到後期突然要改一些不影響大局的東西，比如介面不好看、Icon不精緻、互動不酷炫、需求Cover面窄。這些東西放在普通開發節奏的團隊中是沒有大問題的，但是在「敏捷開發」團隊中，只會拖慢整個團隊進度，本末倒置。
3. 工作內容無邊界
及時補位的思想是要深入到每個團隊成員心裡的。
「敏捷開發」的團隊或是初創團隊一般都是一個人當好幾個人用，每個人都是多面手（這也是好多朋友覺得小公司好的一點，即負責的內容多、成長快），原因就是他們的工作沒有邊界。
比如底層開發生病了，中間層大哥一定要頂上；比如QA人手不夠了，產品經理寫測試用例並參與測試也是常見的事。
4. 團隊無明顯短板
越小的團隊越容易暴露問題，木桶理論在小團隊中更容易體現。
「敏捷開發」過程很容易被團隊中的短板所影響，這事雖然其他成員也有及時補位的精神，但每個人精力畢竟有限，我們還是希望能夠每個人各盡其職。補的應該是未知的突發情況，而不是可預見的短板，這兩個本身就不是一回事。
5. 互相信任
團隊目標必須高度一致，並且相互信任，儘量少的辜負其他人。
產品絕對信任開發評估結果，開發絕對信任產品發起的需求等等。少質疑多溝通，才能快速實現目標。
好多大團隊都會有各種需求評審、用例評審，每天文山會海，而「敏捷開發」會盡可能簡化這個流程。但是我們要說的評審只是手段，目的還是要錘鍊產品需求。因此糾結於是否該簡化評審流程的朋友們，請嘗試理解“不要把手段當目的”這句話。弱化評審的前提一定是產品經理自己已經將需求想明白，即滿足團隊預期、滿足產品預期，再進行交付。
6.擁抱變化
之所以採用「敏捷開發」，真正的目的是快速響應、解決問題。當外界環境發生變化的時候，一定要及時接受並擁抱變化。
所謂的變化來自兩方面。一方面是外部變化，比如產品方向和預期不符、市場反饋不好等；一方面是內部變化，比如效果圖或者互動真的需要改動才能上線等。
面對這種未知的問題，團隊裡的相關人員需要及時調整心態，一起擁抱變化。
個人經歷
我所在的兩個團隊可以勉強算作是「敏捷開發」團隊。
第一個產品20個月釋出26個正式版，50多個Beta版，且保證每個Beta版有可以讓使用者明顯感知的新特性；第二個產品7個月釋出10個正式版，20多個Beta版。
第一個團隊滿足上述所有條件，「敏捷開發」地非常順暢；第二個團隊由於有短板存在，導致「敏捷開發」非常吃力，加上後期團隊成員心態變化，所以基本走上了各種評審的道路。
然而，我想說的是所謂的「敏捷開發」與非「敏捷開發」並沒有誰好誰差的本質區別，只是哪個更適合團隊。就像前面所說，不要把手段當作目的，主要還是看解決什麼問題。
敏捷開發的優點
應對變化
也許敏捷開發實踐為開發團隊和企業帶來的最大優勢可能是它強調響應變更，並專注於處理重要事項。敏捷方法並沒有迫使我們試圖在9個月，12個月或24個月的預測中預測未來。一個適當導向的敏捷團隊列出了他們可以處理的最重要的事情; 當他們完成列表中最重要的事情時，他們會轉移到下一個最重要的事情…等等，無限制地。這種焦點有很多好處：
- 客戶可以更快地獲得他們最重視的問題的解決方案
- 利益相關者可以以漸進的方式對事物進行優先排序，以反映特定時間的實際市場狀況
- 開發人員感到受到重視，因為他們正在處理真正重要的事情，並且會經常使用該產品的人（至少在理想情況下）得到深入的反饋。
接受不確定性
敏捷開發給組織帶來的第二大價值來源是，它的實踐接受了我們在第一次啟動時對項目一無所知的事實。這與更“傳統”的階段門和瀑布方法形成鮮明對比，在任何人接觸鍵盤以輸入他們的第一行代碼之前，預計需求將“完整”。
敏捷反而接受我們將繼續發現更多信息; 我們可能會發現某個特定的技術解決方案無法滿足客戶的需求，或者我們可能會發現在所述問題下面存在完全不同的問題，通過解決問題，我們不僅可以解決建議的問題，還可以解決其他客戶問題。將敏捷原則應用於我們的方法允許我們接受未知並優先發現和實驗，以在我們完全致力於解決方案之前消除不確定性。
更快的審核週期
為了使團隊既接受不確定性又對變化做出反應，隨著工作的完成，需要快速迭代和周期性的全面審查 - 以確保考慮新的發現並評估當前的努力。大多數敏捷實踐既可以進行時間間隔工作（Scrum），也可以控制“正在進行的工作”（看板）的數量，以確保在合理的時間內完成工作。然後，與客戶或客戶代理（例如內部服務團隊或利益相關方團隊）一起審查這些工作。
重點是確保從實際用戶（或盡可能接近用戶）的快速審查和反饋解決瀑布方法的最常見失敗 - 在6-9個月的封閉式開發之後交付沒有人真正想要或喜歡的產品週期。
釋放功能的靈活性更高
除了與客戶或客戶代理進行更快速的審核週期之外，專注於以時間框或工作量方式迭代工作交付工作軟件，使企業在將產品交付給最終用戶時提供更大的靈活性。
在更傳統的方法中，發佈在所有計劃工作完成時發生…或者更糟糕的是，在利益相關者設定的日期發布，無論實際工作在該日期如何完美。另一方面，敏捷方法提供了足夠的功能
減少前期工作
在敏捷開發方法出現之前，不僅產品需求試圖預測6-9個月內需要什麼，而且它們還試圖成為一個百科全書式的合同，概述和詳述產品設計和開發的幾乎每個方面。通常會看到產品需求文檔（“PRD”）和技術要求文檔（“規範”）超過50頁或更多，並概述了開發人員將用作確切交付清單的具體可交付成果 - 僅此而已。
敏捷反而將我們的重點放在定義和優先處理要解決的問題上; 與我們的開發人員合作設計，指定和修改工作需要完成; 並且只施加將產品或項目轉移到下一階段所需的努力量。減少在前期工作中的調查，文件編制和合同談判中產生高昂的前期成本。
敏捷開發的缺點
儘管敏捷可以提供的好處，但它並不適合所有人。因此，了解敏捷方法的缺點非常重要。考慮到這一點，以下是敏捷的五個主要缺點：
資源規劃不佳
因為敏捷是基於這樣的想法，即團隊不知道他們的最終結果（甚至是幾行的交付週期）從第一天開始就會如此，因此預測成本，時間和成本等方面的努力是一項挑戰。項目開始時所需的資源（隨著項目變得更大，更複雜，這一挑戰變得更加明顯）。
有限的文檔
在敏捷中，文檔在整個項目中發生，並且通常“及時”用於構建輸出，而不是在開始時。結果，它變得不那麼詳細，經常落到後面。
分散的輸出
增量交付可能有助於將產品更快地推向市場，但它也是敏捷方法的一大缺點。這是因為當團隊在不同周期中處理每個組件時，完整的輸出通常變得非常分散，而不是一個有凝聚力的單元。
沒有限制結束
敏捷在開始時需要最少的計劃這一事實使得很容易陷入困境，提供新的意外功能。此外，這意味著項目沒有有限的結束，因為從來沒有清楚地看到“最終產品”的樣子。
難以衡量
由於敏捷以遞增的方式遞送，因此跟踪進度需要您查看周期。而“隨時隨地”的性質意味著您無法在項目開始時設置許多KPI。長時間的比賽讓測量進度變得困難。
總結
- 「敏捷開發」需謹慎，一定要捫心自問團隊是否滿足上面說的幾點。
- 「敏捷開發」不是萬能的，解決問題才是王道，切勿盲目崇拜。
References
- What is Scrum Team?
- What is a Self-Organizing Team in Scrum?
- How Scrum Team Works? - A Brief Guide
- How to be a Good Product Owner in Scrum Project?
- What is Product Owner's Role in Scrum?
- Agile Development: How to Become a Qualified Scrum Master?
- What is Pig and Chicken in Scrum?
- Project Manager vs Scrum Master vs Project Owner
- What Are The Three Scrum Roles?
- What is a Scrum Master? The Role and Responsibilities
- What is Cross-Functional Team in Agile?
- As a Scrum Master, How Can You help Your Project Owner?