作者 | Miriam Posner

譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

記得第一次接觸敏捷是我在圖書館工作期間。我的工作是從無到有建立一個新的數字化獎學金中心，有時我需要與圖書館的軟件開發團隊合作，構建支持項目的工具。當時開發團隊有六名成員，我發現他們的工作方式與非技術人員截然不同。開會時，他們討論的不是產品功能，而是“用戶故事”（描述功能的小段文字），而且他們還會分配“故事點”來衡量完成相關任務所需的工作量。每天早上，他們會舉行“站立會議”，實際上就是站著開會，據說站著是為了加快會議的速度。他們的辦公空間內，白板必不可少，開發人員會移動白板上的便利貼以表示工作的完成狀態。他們按照“沖刺”劃分工作周期，一般一個“沖刺”為期兩周，他們需要在這兩周內專心完成特定任務。

在與圖書館的工作人員開會時，開發團隊的負責人會使用軟件報告進度，其中包括表示每個項目狀態的儀表板。經理還可以向我們展示團隊的“速度”圖表，即開發人員完成任務的速度，以及歷史數據比較和預測。

后來，我了解到這就是敏捷，一種管理軟件開發的方法，這種方法在各大技術公司非常受歡迎，而且在非技術辦公場所也越來越流行。老實說，敏捷給我留下了深刻的印象。其實，在日常工作中，我經常感覺很迷糊，不確定自己的工作有沒有進展，或者有沒有做真正有價值的工作。相比之下，開發人員似乎非常清楚自己在做什么。即便他們遇到困難也沒關系，只要解決困難就可以了。他們的需求會不斷變化，而兩周為單位的工作周期，可以讓他們迅速在各個功能之間切換，甚至可以采用新框架，而無需從頭開始。

這就是敏捷的美妙之處：非常靈活，速度非常快，它要求開發人員將每項任務分解為盡可能小的單元。重點是快速發布，不斷回顧，并根據需要改變方向。

我對敏捷非常感興趣。敏捷是從哪里來的？敏捷的目標又是什么？

于是，我開始探索敏捷的歷史。我發現長期以來，經理想要的軟件開發過程與開發人員實際編寫軟件的過程之間一直存在矛盾。各大組織一次又一次地引入新的管理風格，就是希望控制軟件開發面臨的最大問題：超出時間與預算限制。后來，各個公司發現敏捷解決方案不僅可以讓開發人員愉快地完成任務，而且還能保證開發速度。不過，最近一些跡象表明敏捷的力量正在衰退。人們正在醞釀新的方式，而且很有希望取代敏捷。

軟件工程師

軟件開發的危機在“軟件”這個詞發明之前就存在了。1954年，行業、政府和學術界的領袖們在美國底特律韋恩州立大學召開了一次會議，與會的專家表示，我們缺乏接受過一定培訓的程序員。直到四年后，“軟件”這個詞才首次出現在統計學家 John W. Tukey 的一篇文章中，用于表示應用程序編程。到了20世紀60年代中期，美國有至少 10 萬人從事程序員的工作，但據估計至少還有5萬的缺口。

在編程行業剛剛起步的幾十年里，大多數專家認為，編寫計算機可讀的代碼并不是很難。畢竟系統分析師（高級架構專家）已經完成了設計程序和硬件的艱苦工作。而程序員的工作不過是將設計轉化為可供計算機運行的代碼。然而，事實證明這個翻譯過程是一項難度很高的腦力工作。

這項工作需要強大的腦力支持，而且更大的疑問是軟件開發究竟是什么樣的工作，時至今日這個問題依然困擾著管理人員。在計算機誕生初期，在某些人看來，編程是（或者說應該是）純粹的邏輯問題。畢竟，機器只能按照指令工作。因此，我們需要告訴計算機正確的運行方式，而程序員的工作就是找到這種方式。

然而，實際的編程經驗表明，編程既是藝術又是科學。2019 年，Clive Thompson 在《程序員》一書中指出，最先進的編程工作都是由一群大學實驗室的技術怪人完成的，他們認為自己既是工匠又是邏輯學家。軟件本身是看不見摸不著的（你只能看到存儲軟件的介質），因此與其他工程領域相比，軟件開發的工作更加抽象且神秘。其他領域都有一定的物理定律可循，但軟件似乎建立在流沙之上，因為硬件的參數和能力在不斷變化。

然而，電子數據處理領域（辦公自動化，如考勤卡和工資單）得到了迅速發展，因此這些任務使用的機器也迅速地成了技術的最前沿。但我們需要運維團隊來設計程序、準備打孔卡并將數據輸入系統。老牌經理們看不慣年輕的專業團隊日益壯大，也看不慣軟件項目的成本和復雜性經常不可控。計算機科學家 Frederick Brooks 曾將軟件項目比作狼人：這些項目剛開始的時候就像小狗一樣天真無邪，但最后往往會演變成“不遵守時間計劃、預算超支且有缺陷產品的怪物”。20世紀60年代后期，軟件開發面臨三大危機：迫切需要更多的程序員；必須提高可預測性；開發人員必須配合管理層的工作。

本著這種專業化的精神，行業領導者鼓勵程序員接受“軟件工程師”的概念，這個概念是在 1968 年北約軟件工程會議提出的。許多組織領導都指出，軟件開發的規模龐大、組織難度高，而且很難管理。那么，為什么不借鑒一些其他工程領域的方法呢？將編程工作發展成為一門科學，并建立一套有秩序、有影響力且可靠的方法。組織者希望，降低軟件開發行業的管理難度，軟件工程師可以學習其他學科工程師的模式，更好地融入企業文化。歷史學家 Nathan Ensmenger 寫道，“為了提高制造軟件的效率，編程的黑魔法必須讓位于科學的軟件工程方法。

瀑布式軟件開發

軟件工程似乎的確有效。各個大學都采用了這個術語，鼓勵學生在學習編程時，練習完善的工程方法，例如使用數學證明等。計算機科學家 Tony Hoare 聲稱，這些技術將“改變晦澀難懂且容易出錯的計算機編程工藝，以滿足工程專業的最高標準。”

另一方面，經理們也花費了大量心思來組織軟件開發人員，并建立了多種不同的組織方法。其中一種方法是 IBM 推出的主程序員組（Chief programmer team，CPT）框架，該框架由一名主程序員負責監督一組核心專家成員的工作。還有一種流行的做法是，由多級管理者負責管理程序員，管理者們制定決策并將工作分配給麾下的程序員。

隨著這些新技術的出現，程序員的管理也冒出了很多新方法，其中之一就是“瀑布式軟件開發”。從理論上來說，瀑布式開發非常合理：有人為軟件產品設定目標，并將生產分解為一系列步驟，必須確保當前步驟的所有工作都已完成并通過測試，才能繼續下一個任務。換句話說，開發人員只需要按部就班地執行管理層定下的計劃即可。

然而，充滿諷刺意味的是，首次提及“瀑布”一詞的文章指出這種方法不切實際，但這個名稱和思想卻依然流行起來了。瀑布式開發與采用這種方法的公司的層級結構非常契合，正如 Nathan Ensmenger 寫道：“軟件工程運動的本質是控制：控制復雜性、控制預算和日程計劃，而最重要的恰恰是控制勞動力。”而這正是瀑布式開發最擅長的領域。

但不久之后，軟件開發再次陷入危機。部分問題是計算機科學家的供不應求。在20世紀80年代，各個大學沒有足夠的師資力量來培養大量立志成為軟件工程師的學生。美國計算機協會表示，“這種情況十分嚴重，甚至威脅到了計算機科學部門持續培養信息處理行業以及科技日新月異的社會所需的技術人才的能力。”

缺乏開發人員并不是軟件行業面臨的唯一難題。軟件開發本身似乎也深陷泥沼。瀑布式管理承諾的嚴格控制管理化成了海市蜃樓。再多的文檔、再多的流程、再多的程序也拯救不了軟件開發的不可預測性。軟件項目規模巨大、成本高昂，而且經常會失控，由于需求的不斷變化，項目團隊之間在細節問題上爭吵不休，所有的計劃都無法按時完成。管理人員使出渾身解數，想讓軟件開發變得更可靠、更可預測，但結果卻愈演愈糟。正如計算機科學家 Jeff Offutt 所說，“20世紀60年代，程序員建造的都是‘小木屋’，而到了80年代，程序員團隊建造的都是辦公樓”，而到了90年代，他們建造的都是摩天大樓。然而，技術專家團隊似乎無法協調他們的工作。根據技術行業顧問 Peter Varhol 的估計，20世紀90年代初期，從構思到產品問世，每個應用程序所需的開發時間平均為三年。高科技本應讓各大企業更智能、更快、賺取更多利潤，然而很多公司的項目都未能順利完成。

“工程師”的頭銜、層級管理結構、周詳的計劃和文檔，所有這些都是為了給新興的軟件開發領域帶來秩序和控制，但最后的結果卻適得其反。瀑布并沒有為軟件開發人員掃清障礙，相反大量的文書工作和無休止的會議加重了他們的負擔。

工程師對各種苛刻的管理怨聲載道。他們只想構建軟件，結果卻不得不疲于應付大量文書工作。Douglas Coupland 的小說《Microserfs》（微農）以及Mike Judge的電影《上班一條蟲》（Office Space）中描繪的絕望的開發人員就是那個時代的寫照。

敏捷宣言

2001 年 2 月，17個中年人聚集在美國猶他州瓦薩奇山區雪鳥滑雪勝地的洛奇酒店里，為軟件開發制定了一套全新的流程，這就是后來的敏捷宣言。這不是他們的第一次見面。長期以來，他們以各種形式聚集在一起討論軟件開發，最終在 2001 年的這次會議上，他們起草了敏捷宣言。這是一套價值觀，在接下來的幾年里，這些價值觀滲入了程序員管理的方方面面，無論是初出茅廬的初創公司還是聞名世界的科技巨頭都相繼采用了這套管理方案。敏捷宣言本身簡潔明了：

我們一直在實踐中探尋更好的軟件開發方法，

身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個體和互動 高于 流程和工具

• 工作的軟件 高于 詳盡的文檔

• 客戶合作 高于 合同談判

• 響應變化 高于 遵循計劃

也就是說，盡管右項有其價值，我們更重視左項的價值。

該宣言還補充了十二項附加原則，描述了工程師所面臨的難題。瀑布式開發假定軟件應用程序的需求是穩定的，但由于速度緩慢，而且管理僵化，因此最后的結果往往偏離管理層當初制定的計劃。敏捷拋棄了這些高級路線圖，轉而強調即時做出決策。如此一來，軟件開發人員就可以隨著需求或技術的變化而改變自己的工作方式以及內容。他們可以專注于構建軟件，而不必被文書工作和各種文檔搞得暈頭轉向。此外，他們還可以擺脫無休止的會議。

這份文件十分有意思。在專業開發人員稀缺的前提下，技術專家們本應訴求更直接的物質利益，比如工會、對知識產權的擁有權等，但他們要求的卻是更好的工作環境，能夠讓他們更出色、更高效地完成工作。正如作家 Michael Eby 指出的那樣，這種反抗管理的精神與之前對工作場所不滿的表現方式截然不同：技術人員要求的不是物質提升，而是建立一種基于文化、原則、假設、等級制度和道德的“新精神”。敏捷宣言抨擊了官僚主義、天真以及徒勞無功的努力。開發人員并沒有要求更高的報酬，他們只是希望自己能被區別對待。

組織的無政府主義者

對于軟件開發性質的看法變化并非發生在 2001 年，而是在敏捷宣言出現之后的十年左右。開發人員和管理人員都逐漸認識到，軟件開發不可能完全按照分析師給出的流程圖和工作表推進。正如歷史學家 Stuart Shapiro 指出的那樣，軟件開發的復雜性比較特殊，該領域的問題是“模糊、多變和多方面的，因此很難找到一種通用的方法。他們需要結合多種方法，并調整各自的解決方案。”這與循規蹈矩的填表和打卡完全不同。此外，隨著20世紀90年代程序員數量的急劇增加，各大公司招聘了一些非計算機科學專業畢業的人才。這些年輕的程序員并沒有經歷過人們在七八十年代嘗試將軟件開發變成一門科學的努力。敏捷宣言并不是一劑良藥，它更像是一支插曲，只不過是展現了軟件開發人員多年來對流行的企業管理模式的不滿而已。

然而，雖然敏捷有一群忠實的擁護者，但它的使命（即消除自上而下的計劃與層級管理）也存在一定的風險。這意味著，管理層要或多或少地將控制權拱手讓給開發人員。大多數大公司都不愿意這樣做，至少在 2010 年之前是這樣。不過，根據敏捷咨詢公司 Planview 的統計數據，從2012年～2015年，超過50%的開發團隊都認為自己是“敏捷式開發”。

毫無疑問，敏捷開發的流行在一定程度上受到了互聯網高速發展的影響，互聯網極大地改變了軟件的發布方式。以前，軟件更新的頻率一般為一年一次，甚至更長。而且必須借助CD和軟盤等物理介質分發，這極大地限制了新版本的發布速度。但是，如今我們可以借助高速互聯網，根據公司的需要頻繁地發布補丁和新功能，甚至可以高達一日多次。而敏捷正是在這種環境下孕育而生的。

Facebbok 曾有一個座右銘“快速行動，打破常規”，很好地體現了新時代的精神。這是一個考驗膽量的時代，無論是軟件開發還是公司CEO都要大膽創新。風險投資公司的目標是尋找“獨角獸”，他們在2010年前后向科技行業投入的資金創下了新高，因為他們希望盡快看到結果。與眾多創業公司展開角逐需要迅速改變，不斷發布新版本，并以驚人的速度發展。風險發生了變化，如今堅持使用瀑布式開發會非常危險，而敏捷式開發則可以大幅提升速度。

同樣，軟件開發人員也發生了變化。在20世紀70年代和80年代，專家們將注重系統和邏輯思維的科學家視為理想的軟件工作者。但多年來，這一理想未能扎根。我們透過敏捷宣言就能看出，他們的目標是致力于最高標準，快速而自信地工作，而經理們“相信他們能夠順利完成工作”。但是他們拒絕因循守舊。他們不怕快速變化的需求，相反，他們認為這是“駕馭客戶需求變更的有利競爭優勢”。

解放思想、打破墨守成規的思想與敏捷宣言的理念完全吻合。敏捷宣言的作者們看起來就是典型的工程師，穿著襯衫，腰里別著手機套，但敏捷宣言的起草者之一 Jim Highsmith 表示，“無政府主義者本來就不會成為更大的組織”。尤其是在早期，人們曾經就敏捷方法給傳統管理范式帶來的挑戰展開過許多討論。敏捷的支持者為這種與眾不同感到自豪。Jim Highsmith 曾在 2001 年寫道，這個框架“嚇壞了傳統主義者。”軟件開發人員和顧問 Al Tenhundfeld 也曾表示，“敏捷是公開的、激進的、反管理的。例如，Ken Schwaber [敏捷宣言的作者] 直言不諱地表達了希望擺脫所有項目經理的目標。”

反管理，但不是反企業。人們很容易將敏捷開發人員視為20世紀60年代后期圍著打孔機轉悠的科技“怪人”的復興。然而，這兩種人截然不同。早期的科技“怪人”希望編程這項新技術能夠投入使用。而敏捷式開發的程序員會全身心地投入項目。他們討厭管理層的干預，因為管理層阻礙了他們實現最大的愿望，即以最高水平的專業表現迅速完成工作。就像 Aaron Sorkin 的《社交網絡》中的開發人員一樣，他們希望所有人都待在自己的工作區域，戴上耳機，消除一切干擾，專心致志地投入工作。

管理層的復仇

在圖書館工作期間，我一直在關注開發人員，我非常欣賞他們的團隊合作和務實精神。然而，隨著時間的推移，我也注意到了這些團隊的一些問題。盡管他們有速度圖表和嚴格的功能記錄，但開發人員的進展似乎并沒有預期的那么快。他們都在努力工作，這很明顯，但他們面臨一個致命的缺陷：沒有人清楚項目最終應該是什么樣子，或者說服務的目標是什么。雖然團隊成員可以開發功能，但他們不清楚為什么要開發這些功能。也許這個問題只是我們這個項目的問題，但是影響很大。同時，我也開始懷疑敏捷方法是否有一定的局限性。

事實上，任何接觸過軟件開發的人都可能聽說過關于敏捷的傳言。盡管敏捷宣言給出了許多承諾，但人們逐漸意識到，敏捷式開發也不能完全解放開發人員。軟件開發再次陷入了危機，但這一次，是敏捷危機。從普通開發人員到一些最初的宣言作者，每個人都對敏捷實踐產生了擔憂。很多人都談到了“敏捷工業綜合體”，即由敏捷顧問、演講者和教練構成的網絡，他們收取大量費用來幫助組織調整敏捷流程。幾乎每個人都在抱怨敏捷轉向了錯誤的方向：在過去的二十年里，敏捷偏離了最初的宣言，如今開發人員受到的限制、承擔的工作量與壓力更大了。

部分問題在于敏捷的靈活性。自由開發者 Jan Wischweh 稱這是“沒有真正的蘇格蘭人”的問題。凡是人們不喜歡的敏捷實踐就不是敏捷。敏捷宣言的結構就決定了這個不可避免的問題：因為宣言沒有規定任何具體的活動，所以我們只能衡量現行方法的精神，這一切都取決于具體的實踐者。因為敏捷只是一種“思維模式”，而不是一種方法論，因此組織的特征必然會影響到敏捷的實踐。另外，人們也無法批評敏捷，因為你無法將敏捷化為一組特定的方法。一位產品經理告訴我：“如果敏捷不適合你，人們會認為這是因為你的實踐方法不正確，而不是因為框架本身有問題。”

盡管敏捷的定義非常靈活，但許多開發人員已經對敏捷的想法失去了信心。Wischweh 本人在向一位律師介紹站立會議時，遇到了一個從未想過的問題。一位稱職的專業人士每天都需要證明自己確實在工作，而且還要精確到非常小的單位，這對她來說太荒謬了。Wischweh 開始思考敏捷實際上是在鼓勵開發人員將自己視為機器中的齒輪。雖然他們沒有像瀑布模型那樣被埋在管理層的管控之下，但業務的優先級仍然由管理層決定。“作為開發人員和 IT 專業人士，我們喜歡將自己視為知識工作者，我們不需要解釋自己的工作，也不能被商品化。但我認為敏捷在朝著完全相反的方向努力。”

宣言的作者之一 Al Tenhundfeld 指出，他們都是在職的開發人員，而最早接受敏捷宣言的是自我管理的編程團隊。然而，現在有很多專業人士幫助團隊實施敏捷，而敏捷會議也是由經理主導，而不是開發人員。如今的敏捷變成了自上而下的管理形式。而敏捷項目經理，通常作為“產品負責人”嵌入到團隊中，他們被夾在兩股勢力中間：一方面需要為開發人員考慮，另一方面需要交付成果給管理層。

盡管團隊受到多個方向的牽制，但仍然需要以越來越快的速度推進項目。畢竟，根據敏捷的定義，“沖刺”（sprint）本身就意味著快速。事實上，許多與我交談過的科技工作者都表示前景堪憂。技術作家 Sarah Moir 表示，“你必須定義在這個時間段內合理地完成哪些工作，然后跑到終點；然后再重復，然后再到終點，如此反復。如果付出百分百的努力，很快就會讓人覺得筋疲力盡。”

此外，還有日常站立會議、輕量級的任務以及頻繁的檢查，對開發人員來說，這些都是為了監控自己的工作。特別是將工作分解成一些小塊，開發人員就背負起了一種責任感：他們必須完成每一項任務。而且開發人員也會感受到壓力：他們必須證明自己的價值。畢竟，他們是員工，拿了公司支付的薪水。

“故事點”，用來衡量特定開發任務所涉及的工作量的抽象概念，也失去了實質性的作用。最初，開發團隊引入故事點，是為了方便開發人員控制工作量和工作內容。然而，在實踐中，故事點變成了評估開發人員績效的一種方式。西雅圖的軟件工程師 Yvonne Lam 表示，“一旦將某些東西放入數字工具中，人們就會監控這個數字，并希望它上漲，對不對？”

然而，問題不僅在于監控，還有將這些故事點轉化為時間計劃的方式。John Burns 是一家平臺公司的工程師，他說之前的一個公司只是簡單地將故事點乘以一個共同系數，就粗略地估算出了項目所需的時間。盡管人們普遍認為故事點只是一種非正式的內部衡量標準，但管理人員還是將它們作為計劃的工具。

下一次危機

這些抱怨的背后是對敏捷所承諾的自由的更深層次的懷疑。敏捷非常重視開發人員的創造力和獨特的工作方式。但是，采用敏捷式開發，員工能夠發揮出的創造力有明顯的限制，特別是因為問題常常被分解成如此小塊。Michael Eby 寫道，“很明顯，敏捷消滅了層級管理控制的許多弊端，但只是為了以更微妙的方式管控細節。”Yvonne Lam 指出，敏捷的自治在實施中具有很大變數，“雖然敏捷說你有自主權決定自己的工作方式，但有時你想要的是有權利說不。”在軟件開發項目的過程中，我們需要做很多選擇，比如語言、框架、結構等，但我們忽略了一點：通常重大決策都沒有開發人員的參與。

在過去的幾年里，這些問題變得更加重要和緊迫。我們看到科技人員改變公司業務戰略的許多例子，Google 開發人員抗議公司與國防部締結人工智能合同，游戲開發人員抗議性騷擾。這些要求超出了敏捷的職權范圍，因為它們的目的不是為員工創造更好的工作條件，而是徹底改變工作的性質。

還有一個方面值得考慮，敏捷對塑造辦公文化的影響。不可回避的事實是，敏捷宣言的作者是一群非常特殊的人，雖然他們的經歷不同，但他們的關注點基本相同。而且這個小組最后也承認當初他們的團隊多樣性不足，并宣稱要在敏捷聯盟（一個與敏捷宣言相關的非營利組織）中加入更多的聲音。

但是，根據一系列敏捷相關方法的調查，如果你在工作中面臨歧視或騷擾，那么就要有所警覺了。例如，許多人都證實了“結對編程”非常有效，但這種做法的前提是兩位團隊成員的關系很融洽。同樣，敏捷的“回顧”聽起來很不錯，但往往會陷入互相指責的漩渦中，一切都取決于團隊的領導。GitHub 前社區安全經理 Coraline Ada Ehmke 講述了開發人員利用代碼審查的過程騷擾同事的情況。雖然我們知道，消除官僚主義、等級制度和文檔記錄非常好，但有時我們卻需要規則的保護。

對于一些失敗的科技項目，敏捷是不是充當著“助紂為虐”的角色？當看到前 Facebook 經理Frances Haugen 于 2021 年 10 月在國會作證時，我想到了這一點。如果一家公司設定的目標是提高用戶參與度，那么敏捷必然會鼓勵開發人員朝著這個目標努力，那么是不是說即便經理認為可以讓用戶發表偏激的內容，開發人員也不能據理以爭？是站在道德一方，還是堅持敏捷宗旨全力以赴迅速完成工作？開發人員陷入了兩難境地。

考慮到當代軟件可能涉及機器學習、大型數據集或人工智能等技術，這個問題變得尤為緊迫，事實證明這些技術具有潛在的破壞性。數字理論家 Ian Bogost 認為，這種快速行動和打破常規的做法恰恰說明軟件開發人員根本不是“工程師”，他指出，工程是一組具有道德和社會責任的規范。敏捷承諾沒有這樣的責任心，它的目標只有一個：構建產品。

敏捷擅長劃分功能，將它們整齊地打包成沖刺和可交付成果。這確實是整個軟件工程的發展趨勢，模塊化或“信息隱藏”是人類管理系統的重要方式，因為系統過于復雜，任何人都無法掌控。但是敏捷將功能轉變為白板上的“用戶故事”，這就有可能創造出 Yvonne Lam 所說的“否認鏈”：整條流水作業線上沒有任何人能對團隊創建的產品承擔全部責任。

敏捷宣言描繪了一個迷人的畫面，看似軟件開發擁有了民主自由。但問題在于，實際的實施注重的只是最終結果，而不是開發人員的福祉。在工作優先級一致的情況下，敏捷宣言確實可以加強開發人員的自主權，但實際上我們會面臨各種沖突，比如項目經理就經常面臨兩難局面：一方面是對客戶的承諾，而另一方面是開發人員手頭需要優先完成的工作。

一家學術機構的軟件工程師 Mark Matienzo 表示，“人們希望通過流程來管理無法控制的模糊性，尤其是在一些無能為力的地方，比如一些來自高層管理人員或行政部門的突發奇想。你無法影響高層的戰略方向，但敏捷卻讓開發人員覺得自己有一定的自主權。”他直言不諱地說，“敏捷欺騙了開發人員，讓他們覺得自己擁有工作的自主權，但從勞動者的角度來看，他們根本沒有什么權利。”

軟件開發永遠都無法達成公司期望的時間計劃和各項指標。現代應用程序的復雜性使得軟件開發有時顯得非常神秘莫測。雖然計算機最初是軍用設備，但想讓編程工作完全遵從資本的優先級，卻異常困難。當初軟件工程未能拯救軟件開發，于是企業開始寄希望于敏捷，這種思維模式賦予了開發人員一定的自主性，并希望他們全力以赴達成組織的目標。然而，正如越來越多的開發人員指出的那樣，這種自主權非常有限。在企業的實踐中，敏捷所推崇的方法和價值觀總是以企業的需求為導向。無論辦公場所多么靈活，會議多么隨意，最終目標依然是組織的利潤。

然而，敏捷也有一些優點。有人指出，敏捷具有促進員工團結的潛力。如果團隊能夠獲得真正的自主權，公開分享一切，也許敏捷真的能夠實現承諾。也許管理層在敏捷的助力下，成為了自己的掘墓人。也許軟件開發的下一次危機就來自開發人員自己。

原文鏈接：https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/?continueFlag=0c2f362fd425fbeef707eadd88e1a6bd