你們死在了敏捷的路上嗎？

「來源： ｜架構師修行之路 ID：jiagoushixiuxing」

技術編輯：小魔丨發自 思否編輯部

對於廣大程式設計師而言，“敏捷開發”並不是個陌生的詞彙。這是一種從 1990 年代開始逐漸引起廣泛關注的新型軟體開發方法，是一種應對快速變化的需求的軟體開發能力。相對於“非敏捷”，敏捷開發更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的程式碼編寫和團隊組織方法，也更注重軟體開發中人的作用。

2001 年，17 位軟體行業領軍人物共同發表了《敏捷宣言》，宣告了敏捷開發運動的正式開始。今年，距離《敏捷宣言》的釋出已經過了 20 年，那麼敏捷開發成功了嗎？資深軟體工程師、現 Simple Thread 聯合創始人 Al Tenhundfeld 發表了自己的看法。

全文編譯如下：

《敏捷宣言》誕生 20 年，有兩個事實似乎不言而喻：

“敏捷”作為一個標籤贏了，沒有人想被稱為“非敏捷”；

然而在實踐中，敏捷與其提出者的革命性理念相去甚遠。

我們是怎麼走到這一步的？—— 每個人都在做敏捷，然而幾乎沒有人是真正敏捷的。

《敏捷宣言》誕生史

2001 年 2 月，17 名軟體行業專家在猶他州瓦薩奇山雪鳥滑雪場的小屋會面。經過幾天的討論和辯論，他們合作撰寫了《敏捷軟體開發宣言》（《敏捷宣言》）。

首先要強調的是，這些專家都是從業者。他們不是專案經理、CTO 或工程 VP，而是開發者、程式設計師、科學家和工程師，他們仍在寫程式碼，並與利益相關者合作解決問題。這一點非常重要。

另一點是《敏捷宣言》並非憑空產生，這些專家中的許多人已經有了自己建立的方法論，並開始傳播。他們都具備編寫軟體的豐富經驗，並且都在尋求文件驅動的重量級軟體開發流程的替代方案。

該宣言宣佈了四種核心價值：

我們正在透過自己開發和幫助他人開發軟體，來發現軟體開發的更好方法。由此我們建立了如下價值觀：

個體和互動

高於流程和工具

可工作軟體

高於詳盡的文件

客戶合作

高於合同談判

響應變化

高於遵循計劃

也就是說，右欄中的專案固然有價值，但我們更重視左欄中的專案。

敏捷開發帶來的新希望

站在 2021 年回望，我們很容易認為這些現代軟體開發實踐準則是理所當然的，但在 2001 年，這些想法非常激進。

什麼叫“在收集所有需求和評估每一項功能之前就開始構建軟體”？這太瘋狂了！

被遺忘的重要一點是，敏捷在一開始就是公開、激進地反管理。例如，Ken Schwaber 直言，他的目標是除掉所有專案經理，從軟體行業中根除這個職業。

“我們發現，在複雜的創造性工作中，專案經理的角色適得其反。專案經理的思維體現為專案計劃，將專案中每個人的創造力和智力限制在計劃中，而不是調動每個人的智力來最好地解決問題。”

Ken Schwaber，《敏捷宣言》簽署人、Scrum 聯合創始人

Scrum Masters 幾乎沒有權威，在問題上沒有投票權。他們是僕人式的領導者，幫助保護和疏導團隊，但不管理團隊。

反擊

在某些方面，敏捷是一場草根勞工運動。它從基層的從業者開始，被推到管理層。那麼它是如何成功的呢？

部分原因在於

開發者的數量及其對業務的價值不斷增長，並獲得了影響力

。但在我看來

，最大的因素是傳統的瀑布方法根本不起作用

。隨著軟體變得越來越複雜，業務節奏加快，使用者越來越複雜，試圖預先計劃一切變得不再可能。擁抱迭代開發是合乎邏輯的，儘管這對於習慣於計劃一切的管理者來說有點可怕。

我記得在 2000 年代中期的會議上，你可以看出管理層並不是真的買賬，但他們也沒有辦法。

管他呢，要不就試試工程師一直在談論的這個瘋狂想法。反正還沒到最後期限，再糟還能有多糟？

但令他們驚訝的是，敏捷開發開始奏效。團隊會反覆研究一段時間，然後慢慢站穩腳跟，發現哪些模式對團隊有效，並獲得動力。經過幾次衝刺，你會看到優先考慮可工作軟體、協作、花時間檢查和適應等的真正力量。

在大約 5 年的時間裡，“敏捷”從一種你聽說過但可能不習慣於使用的方法發展成為每個人都在做的事情。2005 年我換工作的時候，對敏捷和 TDD 有一點了解，而這將我與其他人區分開來。到了 2010 年，人們普遍認為現代軟體團隊在做敏捷開發。

那麼，敏捷開發贏了嗎？事情並沒有那麼簡單。

像許多革命一樣，敏捷的歷史並沒有按照創始人的設想展開。

事實證明，優先考慮個人和互動是一個很難推銷的概念，宣傳流程和工具要容易得多；

可工作軟體比不切實際的計劃和大量文件更難製作；

與客戶合作需要信任和脆弱性，而這並不總是出現在業務環境中；

對變化的響應往往被管理者壓倒，他們希望掌控局面，且認為自己仍有理由為業務制定長期計劃。

事實證明，敏捷做得不好會讓人感覺混亂。

但這並不意味著《敏捷宣言》提出的四種核心價值是錯誤的。這隻能說明我們需要付出一些努力才能做好敏捷開發，需要一些勇氣去接受軟體本質上混亂的事實。你必須理解並相信，如果你不斷學習、適應、改進和運輸，你最終會到達一個更好的地方，一個比瀑布開發更坦誠、更現實、更有生產力的地方。

敏捷運動並非反方法論，事實上我們很多人都想恢復 “方法論” 這個詞的可信度。我們想要恢復平衡。我們接受建模，但不是為了在塵土飛揚的公司儲存庫中歸檔一些圖表。我們接受文件，但不接受數百頁從未維護過且很少使用的大部頭。我們制定計劃，同時也瞭解計劃在動盪環境中的侷限性。那些將 XP 或 SCRUM 或任何其他敏捷方法的支持者稱為 “駭客” 的人，對 “方法論” 和“駭客”的最初定義一無所知。Jim Highsmith，《歷史：敏捷宣言誕生記》

這些很重要。我們仍然需要計劃和文件記錄，並在敏捷開發中保持嚴謹，這關乎平衡。然而，如果你的組織在敏捷轉型中掙扎，淹沒在混亂中，當有人以認證、流程和工具的形式為你提供救生艇時，你會立刻飛躍。高管們對流程和工具的理解遠遠超過他們對自組織團隊的理解。

失敗的反叛

然而在這方面，我並未看到勇敢的反叛者回歸，至少在敏捷標籤下沒有。

工具供應商、流程顧問和專家做出了永遠無法兌現的承諾，這就是為何我們最終得到了 SAFe、Scaled Scrum 以及其他企業的敏捷方式。這些框架並非惡意建立，它們甚至可能在恰當的語境中具備一定價值，但我不會稱之為敏捷。試圖擴充套件一種專注於個人和互動的方法將不可避免地導致問題，並侵蝕該方法的原始價值。

2018 年，《敏捷宣言》簽署人、XP 聯合創始人 Ron Jeffries 發表文章《開發人員應該放棄敏捷》並表示：

“敏捷”思想如果應用不當，會導致對開發人員的干擾更大，完成工作的時間更少，壓力更大，並被要求 “進行得更快”。這對開發人員是不利的，最終對企業也是不利的，因為“敏捷” 做得不好往往會導致更多的缺陷，以及更慢的進度。通常，優秀的開發人員會離開這樣的組織，進而導致企業的效率不如實施 “敏捷” 之前。

2014 年，《敏捷宣言》簽署人、Pragmatic Programming 提出者之一 Dave Thomas 發表了著名的文章《敏捷已死，敏捷性萬歲》：

“敏捷”這個詞已經到了被顛覆的地步，敏捷社群看起來像是顧問和商家兜售服務和產品的舞臺…… 《宣言》流行起來後，“敏捷”這個詞就成為了營銷術語。所以我認為是時候淘汰“敏捷”這個詞了。

重新流行

對我來說，真正可悲的是看到年輕開發人員詆譭敏捷，並認為這是管理層獲取不切實際的承諾並迫使開發團隊瘋狂工作的手段。他們瞭解到的敏捷是強加的控制機制，而不是他們樂於擁抱的自我授權工具。但我希望圍繞敏捷開發的歷史和最初願景展開一些討論，幫助我們記住事情原本的發展走向。

好訊息是《敏捷宣言》所提出的原則不管在今天還是在 20 年前都一樣明智，即使像 Jeffries 和 Thomas 這樣的反叛者也仍然這樣認為。

Jeffries 在上面提到的文章中說，“然而，《敏捷軟體開發宣言》的價值觀和原則仍然提供了我所知道的最好的構建軟體的方法，基於我長期和各種各樣的經驗，無論大型組織使用什麼方法，我都會遵循這些價值觀和原則。”

我同意他的觀點。

現在談論敏捷既不時髦也不酷。敏捷很無聊，每個人都做敏捷…… 但現在是回顧過去 20 年的敏捷發展過程，並提問自己如下問題的最佳時機：

什麼是對的？出了什麼問題？下次我們想做哪些不一樣的事情？

我希望，我們能夠透過研究敏捷宣言提出的核心價值和原則，從過去中學習。用 Dave Thomas 的話來說就是，

即使我們選擇放棄“敏捷”，我們也可以保持敏捷性。

原文連結：

https：//www。simplethread。com/agile-at-20-the-failed-rebellion/