敏捷與軟體的長期危機 - logicmag

一個新的清算時刻正在形成，它可能最終將敏捷從它的寶座上擊落。

把怪人變成工程師
甚至在 "軟體 "這個詞被創造出來之前，軟體開發就處於危機之中。1954年，在底特律的韋恩州立大學召開的一次由工業界、政府和學術界領導人參加的會議上，專家們警告說，訓練有素的程式設計師即將出現短缺。四年後，"軟體 "一詞首次出現在統計學家John W. Tukey的文章中，指的是應用程式設計。到20世紀60年代中期，美國至少有10萬人從事程式設計師工作，但評論家們估計立即會有5萬多人的需求。

在程式設計職業的最初幾十年裡，大多數專家認為制定計算機可讀的指令是一項相對微不足道的工作。畢竟，系統分析員--指定高階架構的專家--已經完成了設計程式和硬體的艱苦智力工作。編碼員的工作只是將設計轉化為計算機可以使用的東西。因此，當人們發現這個翻譯過程實際上對智力要求很高時，就會感到很驚訝。

這些智力要求的性質，以及軟體開發究竟是什麼樣的工作這一更大的問題，今天仍然令管理人員感到困惑。在計算機的早期，對一些人來說，編碼似乎是，或應該是，一個純粹的邏輯問題；畢竟，機器只是做你告訴他們做的事。不言而喻，有一種形式上正確的方法來做事情，而編碼者的工作只是找到它。

然而，程式設計的實際經驗表明，編碼既是藝術也是科學。正如克萊夫-湯普森（Clive Thompson）在其2019年出版的《編碼者》（Coders）一書中指出的那樣，一些最先進的程式設計是由下班後在大學實驗室閒逛的長髮怪人推動的，這些駭客認為自己既是工匠又是邏輯學家。人們無法實際接觸軟體--也許是其儲存介質，但不是軟體本身--這一事實使得軟體開發比其他工程領域更抽象、更神秘。其他領域可以被期望遵守物理定律，而軟體腳下的土地似乎在不斷變化。硬體永遠在改變其引數和能力。

然而，電子資料處理領域--辦公功能的自動化，如時間卡和工資單--正在迅速增長。從IBM租來的為此目的而設計的龐大機器，迅速成為技術上具有前瞻性的運作的標誌。但它們需要一組操作人員來設計程式，準備打卡，並將資料輸入系統。既定的經理們對越來越多的 "計算機男孩 "隊伍的專業知識和職業怪癖感到不滿。他們也反感軟體專案似乎違背了對成本和複雜性的任何估計。著名的電腦科學家弗雷德裡克-布魯克斯（Frederick Brooks）將軟體專案比作狼人：它們開始時像小狗一樣天真無邪，但更多的時候，它們會蛻變成 "一個由錯過的時間表、被破壞的預算和有缺陷的產品組成的怪物。" 那麼，你可以說，到了60年代末，軟體開發正面臨著三個危機：對更多程式設計師的迫切需求；將開發變成更可預測的東西的迫切需要；以及，正如企業所看到的，管理上的需要，讓開發人員不再表現得如此古怪。

正是在這種職業化的精神下，行業領導者鼓勵程式設計師接受 "軟體工程師 "的稱號，許多歷史學家將這一發展追溯到1968年的北約軟體工程會議。組織者指出，計算機工作範圍廣，難以組織，而且出了名的難以管理。那麼，為什麼不從工程的既定領域借用一套方法（和一個標題）呢？這樣一來，程式設計就可以堅定地成為一門科學，擁有所有的秩序、影響力和隨之而來的既定方法論。組織者希望，這也會使工業界更容易管理：軟體工程師可能會更好地順應企業文化，遵循其他學科工程師的模式。"歷史學家Nathan Ensmenger寫道："為了高效的軟體製造，程式設計的黑色藝術必須為軟體工程的科學讓路"。

追逐瀑布方法
而且，它還起了作用--某種程度上。軟體工程 "的稱謂開始流行起來，與寫軟體的人的機構威望一起上升。大學院系採用了這一術語，鼓勵學生在學習程式設計的過程中實踐合理的工程方法，如使用數學證明。電腦科學家Tony Hoare稱，這些技術將 "改變計算機程式設計的神秘和容易出錯的工藝，以滿足工程專業的最高標準"。

經理們興致勃勃地處理組織新的智慧軟體勞動力的任務，導致了許多不同的組織方法。其中一種方法是在IBM建立的首席程式設計師團隊（CPT）框架，把一個 "首席程式設計師 "放在等級制度的首位，監督一批專家的互動。另一種流行的方法是將程式設計師置於多層管理員之下，由管理員做出決定並將工作分配給他們手下的程式設計師。

隨著這些新技術的出現，出現了一套管理開發工作的理念，這種管理理念被稱為（主要是貶義的）"瀑布法"。瀑布法在理論上是有道理的：有人為軟體產品設定了一個目標，並將其生產分成一系列的步驟，每一個步驟在進入下一個任務之前都必須完成和測試。換句話說，開發人員遵循管理層為他們制定的指令碼。

具有諷刺意味的是，"瀑布 "這個詞第一次出現在一篇指責這種方法不現實的文章中，但這個名字和理念還是流行了起來。瀑布法不可抗拒地與管理它的企業層次結構相匹配。它吸引了管理人員，因為正如Nathan Ensmenger所寫的，"軟體工程運動的本質是控制：對複雜性的控制，對預算和時間安排的控制，以及，也許最重要的，對頑固的勞動力的控制。這正是瀑布式開發所要適應的專業人員。

但不久之後，軟體開發又陷入了危機--或者說危機。問題的一部分是要跟上對新的電腦科學家的需求。1980年的大學無法填補必要的教職，以培訓大量有志於成為軟體工程師的學生。"計算機械協會警告說："這種情況嚴重威脅到電腦科學系繼續培養我們的資訊處理行業和日益增長的技術社會所需要的技術人才的能力。

該行業缺乏合格的開發人員並不是它唯一的問題。軟體開發本身似乎也在掙扎。瀑布法對嚴格控制管理的承諾是一個幻影。無論多少檔案、過程或程式，似乎都無法使開發變得可預測。軟體專案規模大，成本高，而且似乎失去了控制--由於需求的變化和專案組之間對細節的爭吵，巨大的計劃沒有完成。儘管經理們努力使軟體開發變得可靠和可預測，但如果有的話，它似乎只是變得更加笨重。正如電腦科學家Jeff Offutt所說，"在20世紀60年代，程式設計師建造了'小木屋'，"而 "在20世紀80年代，程式設計師團隊正在建造辦公大樓"，到了20世紀90年代，則是摩天大樓。然而，技術專家團隊似乎無法協調他們的工作。技術行業顧問彼得-瓦霍爾（Peter Varhol）估計，在20世紀90年代初，從創意到成品，應用程式的開發平均需要三年時間。技術本應使美國企業更聰明、更快速、更有利可圖，但最受尊敬的公司似乎無法讓他們的專案落地。

"工程師 "的稱號，行政等級制度，仔細的計劃和檔案：所有這些都是為了給新興的軟體開發領域帶來秩序和控制。但這似乎適得其反。瀑布法非但沒有為軟體開發者掃清道路，反而用成堆的檔案和無休止的會議堵塞了工作。

就他們而言，工程師們抱怨說，他們感到被強硬的管理技術所限制。他們只想開發軟體。為什麼他們會被文書工作所束縛？20世紀90年代企業程式設計的典型形象是道格拉斯-庫普蘭（Douglas Coupland）的小說《微觀世界》（Microserfs）中那些存在感極強的20多歲的年輕人，或者邁克-賈奇（Mike Judge）的電影《辦公空間》（Office Space）中那些絕望的開發者，他們的憤怒就潛伏在表面之下。

敏捷宣言：卡其褲和爸爸牛仔褲
這可能是世界上最不可能的一群搖滾明星：17箇中年白人，穿著卡其褲和爸爸牛仔褲，都對管理很著迷。2001年2月，被稱為 "敏捷宣言 "的這些現在具有傳奇色彩的作者們聚集在猶他州的雪鳥滑雪場，為軟體開發過程制定新的願景。這並不是他們的第一次會議；他們以不同的形式聚集在一起討論軟體開發已經有一段時間了，儘管在2001年的會議之前，他們還沒有拿出什麼東西來。這一次則不同。白板上寫著《敏捷宣言》，這是一套價值觀，在接下來的幾年裡，從剛起步的初創公司到龐大的公司，這套價值觀在程式設計師的管理中幾乎無處不在。它簡明扼要，令人愉快。

我們正在透過實踐和幫助他人來發現更好的軟體開發方式。

透過這項工作，我們已經開始重視。

• 個人和互動勝過流程和工具
• 工作中的軟體勝過全面的檔案
• 客戶合作勝過合同談判
• 應對變化而不是遵循計劃

組織無政府主義者
關於軟體開發性質的意見變化似乎並不完全發生在2001年，而是發生在《敏捷宣言》發表之前的十年間。越來越多的人--包括開發者和管理者--達成了共識，即軟體開發不可能符合分析家們寄予厚望的流程圖和工作表的要求。正如歷史學家Stuart Shapiro在1997年所寫的那樣，軟體以一種特別複雜的方式存在：問題是 "模糊的、可變的和多方面的，因此很少被證明適合任何一種方法；相反，它們需要混合和適應性的解決方案。那麼，不是表格和時間卡。此外，隨著20世紀90年代程式設計師隊伍的飛速增長，公司不得不僱用沒有經過正式電腦科學培訓的人。這些年輕的工人很可能對20世紀70年代和80年代將軟體開發變成一門科學的努力投入較少。宣言並不是真正的橫空出世：它更像是一個標點符號，強調了多年來對企業管理的主流模式的不滿。

然而，雖然敏捷有一批忠實的追隨者，但它的任務--取消自上而下的計劃和行政等級制度--是一種風險。這意味著管理層將控制權，至少在某種程度上，讓給開發人員自己。而大多數大公司並不願意這樣做，至少在2010年代之前是這樣。不過，根據敏捷諮詢公司Planview的資料，在2012年至2015年期間，有超過50%的實踐開發團隊將自己定性為 "敏捷"。

毫無疑問，這種流行與高速網際網路連線的增長有關，它極大地改變了軟體的釋出方式。以前，軟體每年更新一次，甚至更長的時間間隔也不稀奇。更新必須透過CD-ROM和軟盤等物理媒介來發布，這限制了新版本的速度。但是，高速網際網路使得公司可以按照自己的意願頻繁地推送修復和功能，甚至一天多次。敏捷在這種環境下有很大的意義。

Facebook著名的座右銘："快速行動，打破常規"，很好地詮釋了新時代的精神。這是一個獎勵大膽的時代，在軟體開發和CEO中都是如此。風險投資公司為了尋找 "獨角獸"，在2010年代向技術領域投入了創紀錄的資金，他們希望迅速看到結果。要與初創企業競爭，就必須具備瞬息萬變的能力，不斷髮布，並以極快的速度發展。風險的計算發生了變化：現在看來，堅持瀑布式開發是很危險的，因為敏捷承諾了這麼多的速度。

同樣的，作為一個軟體開發者的意義似乎也發生了變化。在20世紀70年代和80年代，專家們把具有系統意識、熱愛邏輯的科學家作為理想的軟體工作者。但多年來，這一理想未能紮根。1990年代的程式設計師閱讀的是《連線》，而不是《Datamation》。如果他們的特點可以從《敏捷宣言》中推斷出來的話，他們堅定地致力於最高標準，快速而自信地工作，因為管理者 "相信他們能完成工作"。他們拒絕僅僅因為事情一直是這樣做的而去做，將他們的思想轉向 "持續關注技術的卓越性"。他們沒有被多變的、快速變化的要求所嚇倒；相反，他們把這些要求作為一個機會來接受，"為客戶的競爭優勢駕馭變化"。

自由思考的不循規蹈矩者的形象符合敏捷的理念。宣言的作者可能看起來像教科書上的工程師，穿著釦子襯衫，帶著手機皮套，但據他們中的吉姆-海史密斯說，"很難找到更大的組織無政府主義者群體"。特別是在早期，有很多關於敏捷對傳統管理正規化的挑戰的討論。敏捷的擁護者們為這種不合規性感到自豪：該框架 "讓傳統主義者感到恐懼"，Highsmith在2001年寫道。"敏捷在一開始就公開地、激進地反對管理，"軟體開發者和顧問Al Tenhundfeld寫道。"例如，Ken Schwaber[宣言作者]曾大聲疾呼，明確表示他的目標是擺脫所有的專案經理"。

反管理，也許，但不是反企業，不是真的。
我們很想把典型的敏捷開發者看作是60年代末潛伏在打卡機周圍的長髮反文化怪人的復興。
但這兩個角色在重要方面有所不同。
計算機早期的怪人想為把這種新技術用於工作的純粹快感而程式設計。
Agile敏捷想象中的編碼者首先是致力於專案、討厭行政干預，因為這妨礙了他最大的願望，那就是在最高水平上完成他的工作。

就像亞倫-索爾金（Aaron Sorkin）的《社交網路》（The Social Network）中的開發者一樣，他最希望的是進入 "狀態"：戴上耳機，排除雜念，與他的工作處於一種純粹的交流狀態。

管理層的報復
在圖書館工作時，我一直關注著開發人員，欽佩他們的團隊精神和務實精神。不過，隨著時間的推移，我不禁注意到團隊的表面出現了一些裂痕。儘管有速度表和嚴格的功能跟蹤，但開發人員似乎並沒有取得多大的進展。他們都在努力工作，這是顯而易見的，但有一個致命的缺陷：沒有人真正知道這個專案最終應該是什麼樣子的，或者它到底應該有什麼作用。團隊成員可以開發功能，但不清楚所有這些功能被附加到什麼上面。也許這個問題來自於我的工作場所本身的功能障礙，這是很重要的。不過，我開始懷疑敏捷方法論是否有一些侷限性。

事實上，任何接近軟體開發的人都有可能聽說過關於敏捷的傳聞。儘管宣言有很多承諾，但在與從事技術工作的人交談時，人們開始感覺到，在敏捷下工作可能並不是它所宣稱的那種解放的體驗。的確，軟體開發再次陷入危機--但這次是敏捷的危機。在網路上，從普通的開發者到一些原始的宣言作者都在對敏捷實踐提出擔憂。他們談論的是 "敏捷工業綜合體"，即那些收取高額費用來調整敏捷流程的顧問、演講者和教練的網路。幾乎每個人都在抱怨敏捷走錯了方向：在過去的20年裡，敏捷已經偏離了最初的宣言願景，變成了比它本意更嚴格、更費力、更緊張的東西。

問題的一部分是敏捷的靈活性。自由開發者Jan Wischweh稱這為 "沒有真正的蘇格蘭人 "問題。任何有人不喜歡的敏捷實踐，都不可避免地被證明不是敏捷的。宣言的構造使這一點幾乎不可避免：因為宣言沒有規定任何具體的活動，人們必須衡量到位的方法的精神，這完全取決於體驗者。因為它堅持認為自己是一種 "思維方式"，而不是一種方法論，所以敏捷似乎註定要具有任何採用它的組織的一些特徵。而且它對批評有明顯的免疫力，因為它不能被簡化為一套特定的方法。"如果你做錯了一件事，而且它對你不起作用，人們會認為這是因為你做錯了，"一位產品經理告訴我。"而不是因為這個框架有什麼問題。"

儘管它的定義有這種靈活性，但許多開發人員對敏捷的理念失去了信心。Wischweh本人在向一位律師阿姨描述一個階段性會議時遇到了一個轉折點。她感到難以置信。一個有能力的專業人員每天都需要以微小的單位來證明自己的工作，這個概念對她來說是荒謬的。Wischweh開始思考敏捷鼓勵開發人員將自己視為機器中的齒輪的方式。他們可能不會像瀑布模式中那樣被埋沒在層層管理之下，但他們還是將企業的優先事項內化為自己的優先事項。"作為開發人員和IT專業人士，我們喜歡把自己當作知識工作者，他們的工作不能被合理化或商品化。但我認為敏捷試圖完成完全相反的方法，"Wischweh說。

宣言的作者之一Al Tenhundfeld指出，他的同伴們都是在職的開發人員，而且宣言最初是在自我組織的編碼員團隊中被接受的。然而，現在有很多人專門幫助實施敏捷，而敏捷會議眾所周知地傾向於由管理者而非開發者主導。敏捷的普遍性意味著它很可能是由上面強加的，而不是由下面要求的。敏捷專案經理，通常作為 "產品所有者 "被嵌入到團隊中，他們發現自己被拉向兩個方向：一方面是對開發者最好的，另一方面是他們向管理層承諾交付的東西。

即使團隊被拉向多個方向，它也被要求以不斷加快的速度推進專案。畢竟，"衝刺 "的定義是快速。事實上，對我所接觸的許多科技工作者來說，職業倦怠的前景十分明顯。"技術作家薩拉-莫爾（Sarah Moir）說："你試圖在這段時間內定義什麼是合理的。"然後跑到終點線，再做一次。然後再跑到那個終點線，一直跑下去。如果你投入百分之百的能力，這可能是一種疲憊。"

此外，被稱為輕量級的、低調的檢查的日常會議，對一些工人來說，已經成為監視的練習。特別是當工作被分解成小部分時，工人感到有義務列舉他們所完成的每一項任務。每個工人都有壓力來證明他們的價值；他們畢竟是僱員，需要被認為是賺取他們的工資。

"故事點"--團隊用來衡量特定開發任務中所涉及的努力的抽象概念--也失去了一些誘惑力。他們開始是為了讓工程師對其工作的數量和內容進行一些控制。然而，在實踐中，它們經常被用作評估工程師業績的一種方式。"西雅圖的軟體工程師Yvonne Lam說："一旦你把一些東西放在數字工具中，人們想要的監督量就會增加，對嗎？

問題不僅僅在於監督，還在於積分計算成時間軸的方式。一家平臺公司的工程師約翰-伯恩斯(John Burns)回憶說，以前的工作場所只是將故事點乘以一個共同的係數，以便粗略估計一個專案將需要多長時間。儘管故事點的公開地位是一種非正式的、內部的衡量標準，但經理們還是將其作為一種規劃工具。

下一個危機
這些抱怨的背後是對敏捷所承諾的自由的更深層次的懷疑。敏捷的價值觀讚美開發者的獨創性和特立獨行的工作方式。但是，工人們覺得在敏捷中行使的創造力有明顯的限制，特別是因為問題往往被分解成如此小的碎片。很明顯，"敏捷 "消除了許多更明顯的等級管理控制的特徵，"邁克爾-埃比寫道。"但它這樣做只是為了以微妙和細微的方式重新保持它們。" Yvonne Lam指出，敏捷下的自主權有明顯的引數。"人們說你有自主權來決定你要怎麼做工作。這就像，是的，但有時你想要的是自主權，說這是錯誤的工作"。在任何軟體開發專案的過程中都有許多選擇--關於語言、框架、結構--以至於有可能忽視這樣一個事實，即開發人員往往沒有機會對更大的問題進行權衡。

而且，在過去的幾年裡，這些更大的問題已經變得更加重要和緊迫。
我們已經看到了許多科技工作者組織起來改變其公司業務戰略方向的例子：

• 谷歌的開發者們鼓動他們終止與國防部的人工智慧合同，
• 遊戲開發者們鼓動他們結束性騷擾。

敏捷善於將各種功能分門別類，將它們整齊地打包到衝刺階段和交付成果中。實際上，這也是軟體工程的一種趨勢--模組化，或者說 "資訊隱藏"，是人類管理太過複雜的系統的一種重要方式，任何一個人都無法掌握。
但是，透過把功能變成白板上的 "使用者故事"，敏捷有可能創造出Yvonne Lam所說的 "否認鏈"：

在一條流水線上，沒有人在任何時候對團隊創造的東西承擔全部責任。

《敏捷宣言》描繪了一幅誘人的工作場所民主的圖景。問題是，它幾乎總是在致力於底線的工作場所實施，而不是致力於工人的福祉。有時，這些優先事項是一致的；宣言提出了一個強有力的理由，即企業的產品可以透過工人的自主權得到加強。但它們也有可能發生衝突，比如當專案經理在對客戶的承諾和開發人員自己的優先事項之間徘徊時。

"一家學術機構的軟體工程師Mark Matienzo說："人們希望將流程作為一種管理你無法控制的模糊性的方式。"特別是在那些你被視為有些無能為力的地方，無論是對上層管理或行政部門的奇思妙想。所以你可能無法在高層次上影響專案的戰略方向，但敏捷允許某種概念上的開發者自由意志。" 與我交談的產品經理說得更直白。"敏捷使人們認為他們對自己的工作有所有權，但從勞動的角度來看，他們實際上沒有所有權，除非他們有大量的股票期權或其他東西。

軟體開發從未整齊劃一地納入公司所期望的時間表和指標。現代應用程式的複雜性使得它的開發有時感覺像鍊金術一樣合乎邏輯。計算機可能是作為軍事裝備出現的，但要使程式設計工作完全服從於資本的優先次序，卻出奇地困難。當軟體工程不能約束開發的不穩定性時，企業轉向了敏捷，它將開發者要求的自主權與對組織目標的一心一意的關注相結合。然而，這種自主性是有限的，正如開發人員越來越多地指出的那樣。當應用於企業環境中時，敏捷所推崇的方法和價值觀無一例外地都是以企業的需要為導向的。無論工作場所多麼靈活，會議多麼隨意，底線都必須是組織的利潤。

不過，關於敏捷還有一個角度。與我交談的一些人指出，敏捷有可能促進工人之間的團結。如果團隊真正地自我組織，分享關切，並公開發言，也許敏捷實際上可以藉由工人組織起來。也許管理層透過敏捷正在製造自己的掘墓人。也許軟體開發的下一個危機將來自工人本身。

banq注：注意黑字圈重點。