爲什麼敏捷開發激起了國內開發者這麼強烈的情緒表達，一個 知乎話題 被瀏覽高達 58 萬餘次？爲什麼那麼多人對國內企業的敏捷開發水平提出質疑？谷歌前工程總監認爲敏捷開發的一些思路不適用於谷歌的革命性項目，所以，這事兒在國內也玩不轉嗎？

事件回溯

此前，InfoQ 曾發表了谷歌前工程總監 David Jeske 在 Quora 上對敏捷開發的一些言論，他認爲： 敏捷開發的一些思路並不適合谷歌的革命性工程項目，比如短迭代、低文檔等 ，並在文章中給出了他的理由和改進想法，這篇文章迅速引起了國內開發者的激烈討論，知乎上相關話題 《爲何谷歌之類大廠程序員認爲敏捷開發是瞎扯淡？》 被瀏覽了 58 萬餘次，百餘位用戶發表了自己的看法，部分有代表性的高贊回答對“中國的敏捷開發水平和文化不甚友好”，比如：

程墨 Morgan 提到：“既然產品設計者都講不清楚具體需求，而且需求還總變，那就用敏捷方法哄你開心好了，這就是“敏捷”一下子流行起來的原因…以我個人的體會，可以搞敏捷，但是很容易陷入“僞敏捷”的陷阱…”

熊節表示：“他們（谷歌）說，他們（谷歌）發現敏捷有很多問題，我覺得，說的很有道理。一個方法用了十年，肯定會發現很多問題，肯定是要不斷演進完善的…但是國內企業的配置管理水平、自動化測試水平和代碼質量，根本啥方法都沒有好嗎…很多人有一種莫名其妙的腦回路，谷歌說敏捷是瞎扯淡所以我也說敏捷是瞎扯淡。Linus 從來不寫單元測試所以我也從來不寫單元測試。這個，人啊，貴在有自知之明。”

知乎網友七月在線：因爲客戶和 PM 都沒法一次性完美描述出他們的整體真實需求，經常是每次提出部分有代表性的需求。既然如此，那我們何不每次就做好一部分？就比如下圖，先做個前半身就去上線，後半身等下個階段在做……

所以，爲什麼大部分的聲音不看好敏捷開發的實踐？這一方法論在企業推進落地的過程中是不是出現了一些阻礙？如何正確理解這一方法？如何解決這些阻礙？敏捷開發適用於什麼類型的項目和場景？本文，InfoQ 採訪並諮詢了多位敏捷開發行業的技術專家，一起探討敏捷開發在國內的落地情況。

敏捷開發怎麼了？

縱觀所有評論，大部分不看好敏捷開發的開發者提出了幾點原因：一是項目缺乏整體設計，客戶和產品經理的需求不固定且變更頻率較高；二是會議流於形式，沒有討論出結果反而浪費了很多時間；三是盲目追求速度，一再壓縮開發和測試的時間；四是企業的基礎工作還未做好，比如沒有成熟的自動化測試手段，盲目搞敏捷開發，往往會變成“僞敏捷”。

如上種種讓很多敏捷開發流於形式，這本身也來源於實施者對敏捷開發的誤解。Dell EMC 敏捷與精益創業諮詢師袁店明在接受 InfoQ 採訪時表示：不論國內還是國外，都有很多開發者對敏捷開發存在誤解，就好像每個人心中都有一個哈姆雷特一樣，不同的開發者對敏捷開發也有着自己的理解，以谷歌的前工程總監 David Jeske 爲例，他對此的理解更側重於短迭代和低文檔，基於此做出的判斷難免不全面。

袁店明補充道，敏捷開發的 4 條核心價值觀和背後的 12 條原則是從無數實踐和方法中抽象出來的理論，因爲單一的開發方法都有其優點和缺點。

2001 初，17 位代表各種輕量級軟件開發過程流派的領軍人物聚集在一起，討論當時正在實踐的各種方法哪種方法是最好的。然而，這些人並沒有達成一致，由於都是面向對象的高手，所以就討論並抽象出所有這些方法背後的原則和價值觀，這就是後來的敏捷宣言。

考慮到這樣的誕生過程， 當開發者將敏捷開發的理論運用到實踐中時，一定是在遵循原則的情況下結合自身情況適當調整 ，比如迭代週期並不是必須一週，而可以在一到四周之間浮動；低文檔並不代表不需要文檔，只是“可工作的軟件勝於面面俱到的文檔”等。

簡單來說， 敏捷開發只是一個指導思想和原則，並沒有給出具體的實踐步驟。 在實際的工作中， 如果企業只是一再對外強調敏捷開發，這沒有意義 ，更多的是說清楚爲了達到組織目標的過程中遇到了什麼問題，在敏捷原則和核心價值觀的指引下，哪些實踐和方法可以幫助達到組織的目標，或者解決這些問題從而達到組織目標。然而，如果本身對敏捷開發就存在誤解，這很容易導致錯誤的實踐方式。

“僞敏捷”是如何造成的？

在過往實踐中，國內其實有很多企業在敏捷開發上做出了很好的示範，比如華爲（ 《華爲大規模敏捷開發實踐：如何從 0 到 1 落地 DevOps？》 ）、諾基亞（包括前阿爾卡特朗訊）等通信企業，甚至一些傳統的大型企業。但是，正如熊節所言，國內大部分企業在這方面踩過很多坑。袁店明表示，如果一家企業連基礎設施都沒有建好，怎麼做到迭代式開發呢？

與瀑布式開發相比，迭代式開發的週期更短，原來可能是一年一個瀑布，一年才做一次完整的迴歸測試，雖然整個過程的代碼也是不斷提交的，但如果換成是迭代式開發，即便一個月一次迭代，一年也需要進行 12 次迭代，迴歸測試的量就是原來的 12 倍， 如果還是單純依靠開發者本能，不採用自動化測試的方法，遇到問題很難定位，這時的迭代式開發往往只是概念引入，技術上沒有跟進。

此外，很多開發者對敏捷開發的“短迭代和低文檔”有誤解，袁店明在採訪中表示，短迭代並不意味着每個週期結束必須將產品交付給用戶。當然，如果有能力交付用戶體驗肯定很好，如果沒有，開發團隊交出一個潛在可用的產品即可，至少需要通過評審才能判斷需求是否合理，邏輯是否正確，從而判斷是否需要進行調整。這也是迭代式開發的優勢之一，可以提前判斷產品設計的合理性。

至於文檔， 敏捷開發雖然倡導可運行的軟件勝過面面俱到的文檔，但並不等於沒有文檔。 袁店明在採訪中表示，文檔的作用可以分爲兩類：一類是記錄和傳承；另一類是溝通。記錄主要用於保留架構設計和所有產品需求，這部分內容不僅重要，還需要儘可能做到透明化，實時反映需求的變化，需求的描述也應該更加具體和詳細；至於溝通，小範圍溝通的場景下，面對面溝通顯然比文檔更加高效。

那麼，敏捷開發怎麼做？

技術的誕生一定是爲了解決問題，不論公司是採用瀑布式開發、迭代式開發還是兩者兼而有之，只要能夠解決實際問題，都是可行的解決方案，尤其是在沒有完全理解敏捷開發的概念時，袁店明不建議盲目上手實踐。

可能很多人會有疑問： 敏捷開發是不是有具體的適用場景？ 在 David Jeske 的回答中，他就曾指出這一方法不適合谷歌的革命性工程項目。袁店明則認爲，不同規模的項目確實需要分開看待，但並不是說就一定不適合，針對大型組織，現在已經有了很多大型開發框架，比如：

• LeSS：大規模 Scrum，以 Scrum 爲基礎。LeSS 分兩個模式，LeSS 模式宣稱適合 8 人團隊、最多 8 個團隊共 64 個人的情況，LeSS HUGE 模式則號稱可適應數千人規模的產品研發；在敏捷方法方面，LeSS 以 Scrum 爲核心，工程實踐維度，有實踐指導材料；

• SAFe：大規模敏捷框架，完整的 SAFe 框架可以分爲四個層級，團隊級適合 5~9 人團隊、項目羣級適合 5~12 個團隊（約 50~125 人）、大型解決方案級適合數百人規模、組合級適合 500~1000 人規模；敏捷方法論方面，介紹了 Scrum、XP、Kanban 方法，主張團隊自主選擇，工程實踐方面有所提及，但沒有特別詳細的介紹；

企業要結合自身的 組織架構、人員水平和業務現狀 進行選擇。以組織架構爲例，創業階段企業的業務單一、所以組織結構通常是扁平化的，成長階段企業會快速構建起層級組織結構以適應不斷增長的企業規模，成熟階段的企業往往採取矩陣式組織結構以支撐企業多元化的業務。

如果企業在實施敏捷開發後，依舊維持需求和產品團隊、開發團隊、測試團隊，各個團隊各自爲政，老死不相往來的方式， 敏捷開發肯定要失敗 。在敏捷開發中，往往一個 Team 就是一個特性團隊，一個可以交付產品的特性團隊，一個端到端的團隊。如果是一個很大的產品，則可以按照子系統劃分團隊。由多種技能人員組成的特性團隊是非常重要的，對小公司來說， 建立特性團隊相對容易， 但對大公司來說，這簡直就是一場革命，肯定要觸動不少人的利益，有既得利益者的阻撓， 這是非常難的。

所以，很多公司雖然瞭解敏捷開發的好處，在小範圍內做了試點並收穫了正向反饋， 但現階段還不適合， 最後往往不了了之。

結束語

無論國內還是國外，大公司還是小企業，敏捷開發都已經有了無數的成功案例。這些年，軟件工程中一些好的實踐，比如持續集成、測試驅動開發、結對編程、看板等都來自於敏捷開發。可以肯定的是，敏捷開發是一種非常好的軟件開發模式，但當一件事情從開始就理解錯了，那以後的路只會越走越偏。企業決定實踐敏捷開發前，請先檢查組織內部是否已經做好準備，相關人員是否對此有正確的理解，全靠開發者本能的狂奔，肯定不會走太遠。

谷歌程序員覺得敏捷開發沒搞頭，你怎麼看？| 話題