首先什麼是敏捷開發？

敏捷開發不僅僅是快速程式設計和迭代式需求變更。他有很多的實踐。

比如溝通損耗盡可能低的小團隊。

比如面向故事，測試驅動開發。

比如頭腦風暴。

比如多人程式設計提高質量。

比如自解釋的程式碼。

等等等等

在大學的時候，因為在某家還可以的公司實習，顯得很狂妄，答辯的時候，我對答辯老師說，雖然傳統上說敏捷並不適合大型專案，但是確實有些大型公司在使用並且成功了。

經過8年的工作，我想收回那句話。

敏捷並不適合所有團隊，所有專案。

敏捷思想的真實核心不是工程管理，而是慾望。

其實這些實踐中不難發現，都是在刺激程式設計人員創造力和成就感。這些方法都是基於"精英"程式設計師的做法，就是，那些以程式設計為樂趣，廢寢忘食的人，對於這些人，別說996，忙到2-3點，睡兩三個小時，繼續工作的都樂此不疲。

現實情況是，這樣的人，事實上很少，絕大部分程式設計師只是程式設計當成一個工作，老闆把專案當成謀利工具，把敏捷當成減少成本的方式。在這樣的團隊裡搞敏捷，味道已經不對了，資方摳，勞方精，是不可能真正完成上面的實踐的。

不是說敏捷不好，只是合適的方法，需要合適的平臺，很多地方把敏捷說的那麼高效，那是因為大神的隊友也都是大神，他們思維活躍，不受束縛，富有創造力，這也就不難理解為什麼敏捷裡會有增加成本的雙人程式設計的情況了。在大部分公司裡，用程式碼的規範替代了雙人程式設計的思維發散與瞭解。用績效來替代了迭代。用模組分工替代了頭腦風暴。用測試團隊替代了測試驅動。確實不太對味。

在國內，老闆有老闆的苦衷，員工有員工的想法，如果不是一群創業愛好者，儘可能還是走瀑布，走原型吧，沒有付出的老闆和沒有責任心的員工不適合這種高度自由的方式。

任何事情都要實踐

比如溝通損耗盡可能低的小團隊。

比如面向故事，測試驅動開發。

比如頭腦風暴。

比如多人程式設計提高質量。

比如自解釋的程式碼。

等等等等

在大學的時候，因為在某家還可以的公司實習，顯得很狂妄，答辯的時候，我對答辯老師說，雖然傳統上說敏捷並不適合大型專案，但是確實有些大型公司在使用並且成功了。

經過8年的工作，我想收回那句話。

敏捷並不適合所有團隊，所有專案。

敏捷思想的真實核心不是工程管理，而是慾望。

其實這些實踐中不難發現，都是在刺激程式設計人員創造力和成就感。這些方法都是基於"精英"程式設計師的做法，就是，那些以程式設計為樂趣，廢寢忘食的人，對於這些人，別說996，忙到2-3點，睡兩三個小時，繼續工作的都樂此不疲。

現實情況是，這樣的人，事實上很少，絕大部分程式設計師只是程式設計當成一個工作，老闆把專案當成謀利工具，把敏捷當成減少成本的方式。在這樣的團隊裡搞敏捷，味道已經不對了，資方摳，勞方精，是不可能真正完成上面的實踐的。

不是說敏捷不好，只是合適的方法，需要合適的平臺，很多地方把敏捷說的那麼高效，那是因為大神的隊友也都是大神，他們思維活躍，不受束縛，富有創造力，這也就不難理解為什麼敏捷裡會有增加成本的雙人程式設計的情況了。在大部分公司裡，用程式碼的規範替代了雙人程式設計的思維發散與瞭解。用績效來替代了迭代。用模組分工替代了頭腦風暴。用測試團隊替代了測試驅動。確實不太對味。

在國內，老闆有老闆的苦衷，員工有員工的想法，如果不是一群創業愛好者，儘可能還是走瀑布，走原型吧，沒有付出的老闆和沒有責任心的員工不適合這種高度自由的方式。

從已有的幾個回答來看，主要還是敏捷開發的經被念歪了，這樣子怎麼能不被帶偏？

我們十年前在的公司全面普及敏捷開發，公司裡也湧現了好多這方面的大佬，從帶隊者到教練到佈道者，有一些離開公司之後甚至加入或者自己創辦了普及敏捷開發的諮詢公司。當時的效果是很顯著的，研發線上對於需求的響應及開發質量都大大提高，這也是為什麼經過了前期區域性嘗試後上層決定全面的普及。

那麼為什麼有的公司就搞不好敏捷開發呢？我後來在另外一些公司和團隊呆過，可以說幾句我看到的問題：

首先，敏捷開發的精髓是敏捷的思維，而不是形式。最先提出的人只是根據他們的經驗與實踐給出自己的建議，在真正實施的時候要根據實際情況因地制宜。我們有很多開發者以及領導者其實並不具備敏捷開發的思維，結果採用了敏捷的開發模式之後就各種不習慣，又沒有相應的培訓和輔導，結果就成了為敏捷而敏捷，在很多人那裡流於形式。比如站會，為什麼每天開，每次要圍站在看板前，每次要所有人主動講，背後的意思是鼓勵團隊內充分溝通，在最短時間內及時暴露和解決問題，並且培養主人翁意識。到了一些團隊裡，就變成每天定時站起來，由頭目一個個問進度然後記錄下來，各自彙報一下結果和計劃，就結束了，幾乎所有人都是被動參與，結果也不透明，效果就大打折扣。

其次敏捷開發必須自上而下的普及，而不僅僅是研發自己關起門來搞。否則第一上面的領導如果抱著質疑的態度或者不支援，相關的人員不參與遵照敏捷流程，很容易從體制上破壞敏捷的流程，從而幹不下去。比如我見過一個團隊的負責人說要搞“所謂的”敏捷，一聽我就發現大事不好，果然後來都是他一個人在揮舞著指揮棒，底下人必須聽從其指揮，他說什麼優先順序高就是什麼優先順序高，他說功能怎麼定就必須怎麼定，這特麼是哪門子敏捷？果然後來堆砌出了一個四不像的產品。然後公司的CEO對研發一竅不通，更不要說什麼敏捷了，所以研發中暴露的問題看不出來，對產品做成什麼樣只能浮於表面的點評幾句，既不能給出建設性意見，也不能對研發流程是否需要改進作出判斷，這樣的敏捷搞起來有什麼意義？

最後，敏捷開發模式對人的素質要求很高，包括技術水平、思維開放度以及溝通能力。我們那時候能做好，是因為公司招聘的都是高素質人才，也經過情商測試的，然後在實踐過程中還反覆的培訓以及輔導，以確保大家從態度上理解上還有技能上能符合工作的模式。如果一個公司招的人達不到這樣的標準，去搞敏捷開發，那是屬於東施效顰，失敗的機會很高