作者 | John McBride
譯者 | 劉雅夢
策劃 | 凌敏
當 《敏捷宣言》於 2001 年首次出現時，整個行業剛剛從網際網路泡沫的災難性破滅中走出來。大量的資本湧入科技市場，每家公司都在「採用」網際網路，但當不可避免的經濟衰退到來時，許多軟體工程師失去了工作。
由於 1998 年和 1999 年的低利率，90 年代末現金充裕，催生了一種新型的初創公司：網際網路初創公司。許多企業家（通常沒有能力真正執行自己的想法）被這個全新且蓬勃發展的市場可能性所蒙蔽，成功地將自己的企業推銷給風險投資公司。雖然有一些非常成功的獨角獸從這個泡沫中走了出來（比如谷歌的網際網路搜尋引擎、易趣的在線拍賣網站和亞馬遜的網際網路書店），但許多其他獨角獸都失敗了，不可避免地倒閉了，並重創了市場。
撇開糟糕的技術市場不談，2001 年的軟體世界是一個非常混亂、競爭激烈且「重流程」的地方。許多工程師都受制於可怕的瀑布式（Waterfall）軟體開發方法：這是一種使用難以更改的嚴格需求來創建軟體的系統。而且固定的軟體產品交付期限幾乎沒有為任何疊代或集成測試留下空間。
在其他工程領域，瀑布式的效果不錯：如果你正在建造一座橋樑，我當然希望你在開始建造之前就有一份要求、測量、材料和結構計算的清單。
但在軟體領域，情況變化的很快，集成經常被中斷，客戶需求會毫無徵兆地發生改變，因此通常需要一種更短、更簡單的開發方法。你可能花了幾個月的時間用瀑布式開發了一些軟體，然後發現另一個部門的另一個團隊提供的一些關鍵 API 集成與你所構建的軟體完全不兼容（需要更長的瀑布周期）。或者，如果不是完全取消的話，你的項目可能會被業務降低優先級，（如果我們幾個月前就能收到用戶的反饋，這樣我們就知道該做什麼了……）。
上世紀 90 年代末和本世紀初，試圖「採用網際網路」的公司發現自己陷入到了冗長的工程流程和開發周期的泥潭中。這至少在一定程度上導致了網際網路泡沫的經濟崩潰：大量經濟部門停滯不前，未能履行其對網際網路業務價值和穩定性的誇大評估。我想知道，如果企業在早期技術革命期間採用更簡單的敏捷方法，世界將會是什麼樣子：失敗的企業會不會更少？如果是今天，我們的技術水平還會進一步提高嗎？
值得慶幸的是，敏捷提出了一種不同的方法。
讓我們想像一下，假設你團隊的任務是構建並交付一輛軟體汽車。在瀑布式開發中，你可能首先要建造車架，然後建造車輪，最後建造發動機，依此類推。很多事情都可能出錯：如果最終產品不能滿足客戶的需求怎麼辦？如果你與道路軟體套件的集成在交付時發生中斷怎麼辦？或者你發現發動機部件實際上從未按預期工作，最終導致整個產品被損壞。汽車的計劃和要求通常是由「業務部門」負責的，並在開發之初就交給了開發團隊，但他們幾乎沒有進行更改的靈活性，也沒有能力從真正的用戶那裡獲取早期反饋。
相反，使用敏捷來構建這輛軟體汽車，你將始終不斷地交付可工作且經過測試的軟體，並與了解客戶需求的人員密切合作。你可以先交付一個滑板類型的東西。這建造起來足夠簡單；它有四個輪子，開門即用。然後，你可以把框架做得更大。你可以為小型推車式車輛添加一個發動機。為一輛汽車增加足夠的座位。配置方向盤。添加收音機。最終，該項目將會完成，並且在此過程中，開發團隊能夠從真實用戶那裡獲得反饋，並不斷與現有系統集成，邊開發邊測試（團隊在早期就能發現與道路系統的集成失敗！）。
敏捷軟體開發提出的原則對 2023 年的工程師來說似乎是顯而易見的，但在當時，這些想法有趣、微妙且強大：始終交付可工作的軟體，測試代碼，持續集成，進行面對面的對話，優先考慮與團隊中人的關係，快速適應不斷變化的需求，與業務人員密切合作，讓團隊自組織以獲得最佳結果。
就像任何好的「宣言」一樣，所有這些都被包含在一個簡單而優雅的文檔中：《敏捷宣言》。這並不是來自業內權威人士的；它是由從事實際工作的軟體工程師編寫並簽署的。它的誕生聽起來就像是小說中的情節：2001 年的冬天，17 名軟體開發人員聚集在猶他州的雪鳥城（Snowbird），滑雪、吃飯、喝酒，並討論軟體行業（但不幸的是，他們並沒有進行什麼史詩般的探索）。像 Kent Beck（後來建立了極限編程）、Andrew Hunt 和 David Thomas（《程式設計師修煉之道——The Pragmatic Programmer 的合著者）以及 Jeff Sutherland（scrum 項目管理方法的先驅）這樣的人。他們都出席了。輸出了一個單一、簡單的文檔，概述了一個理想、精益且高效的軟體組織工程過程。
敏捷開發最終將成為其他軟體開發系統的基石，如 Scrum、DevOps、極限（Extreme）編程和平台工程。這些後續的開發系統在很大程度上強調了敏捷中的不同原則；如持續交付、持續集成自動化套件、各個貢獻者之間的關係，以及輕鬆地為個人貢獻者和開發團隊部署和交付優化的開發環境。但貫穿所有這些方法的方法論是敏捷。敏捷仍然是支柱。敏捷賦予了這些方法生命。
儘管敏捷看起來是關於過程和如何完成工作的，但《敏捷宣言》首先也是最重要的是對一個正在分崩離析、從內到外自相殘殺並耗盡人才的行業的回應。
《敏捷宣言》的核心是：
一套基於相互信任和尊重的價值觀，促進以人為本、協作為基礎的組織模式，並建立我們希望為其工作的組織社區類型。
一套基於相互信任和尊重的價值觀，促進以人為本、協作為基礎的組織模式，並建立我們希望為其工作的組織社區類型。
接受敏捷工程流程也意味著接受了圍繞並包含敏捷的文化理想。經常測試、發布工作代碼、持續集成等工程流程僅服務於支持自組織團隊蓬勃發展的工程組織類型，在這裡，人們熱愛他們所做的工作，並且信任其工程師同事。
如今，大多數軟體組織都會說他們已經採用了敏捷（或者至少採用了某種敏捷的派生形式）。然而，我認為該行業在採用敏捷的真正核心方面並沒有達到目標。
我們發現自己的處境與 2001 年的網絡泡沫破滅非常相似；利率不斷上升，大批軟體人才以最糟糕的方式被解僱，優先事項從協作和心理安全的工程組織轉移到更高效地交付產品上。
似乎整個行業都在抵制敏捷的理念。
我最擔心的是，《敏捷宣言》並未改變任何事情，因為越來越多的部門都變成了我不想為之工作的地方。
我首先要承認：敏捷需要時間、精力和奉獻精神。但這並不總是那麼容易。回顧、規劃會議、用戶研究（等等）都需要時間和工程資源。時間並沒有花在編碼或直接處理產品上。但是，如果說過去 20 多年的科技繁榮市場向我們展示了什麼，那就是敏捷在行業中被廣泛採用了，這就是敏捷的作用。快樂的工程師熱愛他們的工作，提供了令人驚嘆的解決方案，從長遠來看，他們打造更具可持續性的組織，這些組織可以持續交付客戶喜愛的穩定和創新的產品。
如果到目前為止，你還在讀這篇文章，會發現自己在說「嗯，網絡泡沫有點像今天的科技市場」，那是因為它確實如此。從經濟、文化和工程流等程角度來看。當經濟不景氣時，工程組織似乎都會變得更糟。
埃隆·馬斯克（Elon Musk） 收購推特（Twitter） 就是一個主要且引人注目的例子：大多數工程師都被解僱了，出現了多次長時間的停機，有傳言稱內部基礎設施系統嚴重受損，以及出現了一種新的「極端硬核」文化，所有這些都是為了尋找盈利能力和交付軟體需求的運動。
但埃隆·馬斯克不應該受到指責。推特的問題早在收購之前就已經存在了：
在 2019 年加入推特不久，Dantley Davis 將他的員工聚集在公司舊金山總部的一個會議室里……他要求員工們在會議室里四處走動，相互讚揚和批評。他說，嚴厲的批評將有助於推特的改進。倒刺很快就飛了起來。據在場的三名人士說，在兩個小時的會議中，有幾名與會者都哭了。
在 2019 年加入推特不久，Dantley Davis 將他的員工聚集在公司舊金山總部的一個會議室里……他要求員工們在會議室里四處走動，相互讚揚和批評。他說，嚴厲的批評將有助於推特的改進。倒刺很快就飛了起來。據在場的三名人士說，在兩個小時的會議中，有幾名與會者都哭了。
這聽起來肯定不像是「我們希望在其中工作的組織社區類型」。
這一點意義重大，因為科技市場是一隻自食其力、總是自相殘殺的野獸：無論大公司做什麼，尤其是像谷歌、Meta 和亞馬遜這樣公司，科技市場的其他公司都會緊隨其後。工程文化、薪酬、面試等方面的這些趨勢總會滲透到行業的其他領域。所以，在你不自知的情況下，埃隆·馬斯克對推特的收購可能就已經影響到了你。
2023 年的裁員和縮編可能還沒有結束。許多經濟學家認為，我們正走向衰退（如果還沒有衰退的話），這可能會加速許多公司的文化和工程組織變革。就像 2001 年網際網路泡沫破滅時一樣，今天的軟體和科技行業必須要面對經濟的衝擊。
但我對未來的希望是，工程組織和領導層認識到這一正在重複的歷史，改變方向，並繼續專注於為他們工作的精益和敏捷流程。否則，我們可能會看到更多像推特這樣的公司，它們的商業模式失敗了，基礎設施崩潰了，穩定性令人遺憾，也許最糟糕的是，它們是一個沒有人願意加入的工程組織。
原文連結：
https://onengineering.substack.com/p/how-the-agile-manifesto-changed-nothing
聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。
點擊底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！
今日好文推薦
第一批因AIGC裁掉自家員工的老闆該後悔了？
C# 和 Type 之父親自帶隊開源 TypeChat，又一 AI 技術瓶頸被攻破？
終於找到 ChatGPT 「智商」下降的原因了！OpenAI 側面回應，GPT 可能真被你們玩壞了？
微信取消秋招；谷歌軟體工程師基本年薪超 500 萬；通報批評員工到點下班？比亞迪回應 | Q資訊