如今互聯網行業，每天有無數的公司倒下，同樣也有無數的公司站起來。

越來越多的人將「敏捷開發」搬上臺面大談特談，或是為了搶占市場先機、或是為了不斷修正需求方向、或是表現出相當的創業精神進而“騙取”資本熱錢。

有太多太多的原因讓人們追捧「敏捷開發」，這些追捧既有目的性極強的也有無腦跟風的。我在好多論壇或者交流群也見過有人問關于自己的團隊適不適合「敏捷開發」的問題。

所以今天，我來說說究竟什么樣的團隊才適合「敏捷開發」。

1. 小團隊

這點應該毋庸置疑。

從生活經驗上來看，小動物一般用敏捷來形容，比如兔子、貓（當然，大動物也有，如：這頭豬真胖，但它竟然還這么敏捷）。

小團隊不會出現大團隊那種尾大不掉的情況，「敏捷開發」進度可能每天都會變化，小團隊有著更低的管理成本，產品經理可以很好的把控整個團隊節奏。

當然，小團隊也是要五臟俱全的。

2. 需求聚焦

如前文所說，大家采用「敏捷開發」肯定是有目的的。不管什么目的，肯定是為了快速響應、快速上線。這時，產品需求一定要聚焦、再聚焦。

有太多團隊都是開發到后期突然要改一些不影響大局的東西，比如界面不好看、Icon不精致、交互不酷炫、需求Cover面窄。這些東西放在普通開發節奏的團隊中是沒有大問題的，但是在「敏捷開發」團隊中，只會拖慢整個團隊進度，本末倒置。

3. 工作內容無邊界

及時補位的思想是要深入到每個團隊成員心里的。

「敏捷開發」的團隊或是初創團隊一般都是一個人當好幾個人用，每個人都是多面手（這也是好多朋友覺得小公司好的一點，即負責的內容多、成長快），原因就是他們的工作沒有邊界。

比如底層開發生病了，中間層大哥一定要頂上；比如QA人手不夠了，產品經理寫測試用例并參與測試也是常見的事。

4. 團隊無明顯短板

越小的團隊越容易暴露問題，木桶理論在小團隊中更容易體現。

「敏捷開發」過程很容易被團隊中的短板所影響，這事雖然其他成員也有及時補位的精神，但每個人精力畢竟有限，我們還是希望能夠每個人各盡其職。補的應該是未知的突發情況，而不是可預見的短板，這兩個本身就不是一回事。

5. 互相信任

團隊目標必須高度一致，并且相互信任，盡量少的辜負其他人。

產品絕對信任開發評估結果，開發絕對信任產品發起的需求等等。少質疑多溝通，才能快速實現目標。

好多大團隊都會有各種需求評審、用例評審，每天文山會海，而「敏捷開發」會盡可能簡化這個流程。但是我們要說的評審只是手段，目的還是要錘煉產品需求。因此糾結于是否該簡化評審流程的朋友們，請嘗試理解“不要把手段當目的”這句話。弱化評審的前提一定是產品經理自己已經將需求想明白，即滿足團隊預期、滿足產品預期，再進行交付。

6.擁抱變化

之所以采用「敏捷開發」，真正的目的是快速響應、解決問題。當外界環境發生變化的時候，一定要及時接受并擁抱變化。

所謂的變化來自兩方面。一方面是外部變化，比如產品方向和預期不符、市場反饋不好等；一方面是內部變化，比如效果圖或者交互真的需要改動才能上線等。

面對這種未知的問題，團隊里的相關人員需要及時調整心態，一起擁抱變化。

個人經歷

我所在的兩個團隊可以勉強算作是「敏捷開發」團隊。

第一個產品20個月發布26個正式版，50多個Beta版，且保證每個Beta版有可以讓用戶明顯感知的新特性；第二個產品7個月發布10個正式版，20多個Beta版。

第一個團隊滿足上述所有條件，「敏捷開發」地非常順暢；第二個團隊由于有短板存在，導致「敏捷開發」非常吃力，加上后期團隊成員心態變化，所以基本走上了各種評審的道路。

然而，我想說的是所謂的「敏捷開發」與非「敏捷開發」并沒有誰好誰差的本質區別，只是哪個更適合團隊。就像前面所說，不要把手段當作目的，主要還是看解決什么問題。

總結

• 「敏捷開發」需謹慎，一定要捫心自問團隊是否滿足上面說的幾點。
• 「敏捷開發」不是萬能的，解決問題才是王道，切勿盲目崇拜。

PS. 「敏捷開發」過后，產品經理一定要整理文檔，否則快是快了，什么都沒留住。切記切記！！！

總結

以上是生活随笔為你收集整理的「敏捷开发」适合什么样的团队？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。