敏捷是一種強大的方法，但在日益由數(shù)據(jù)驅動的世界，它可能未必是正確的方法。

　　我們開始使用曲棍球棒時，我就知道敏捷走到頭了。每天早上8點，一個團隊的開發(fā)員和架構師會站在鑲嵌有白板的房間，開始傳遞一根玩具曲棍球棒。你接到曲棍球棒時，應該會開始長篇大論：原諒我，上帝，我有罪。我昨天就寫了兩個模塊，因為開了一整天的會，又餓著肚子；我的工作缺不了Joe，他本周因肺炎請病假了。

　　那個scrum大師（坐著的那個人，別人都站著）會在敏捷工具Rally或Jira中及時記下這點，然后會說：“你差三個模塊。預計今天可以寫好這些模塊嗎？”

　　“scrum大師，我會按您的要求寫三個模塊，我拖慢了團隊的平均進度，現(xiàn)在有負諸位。”

　　“伙計，你看著辦，sprint（迭代開發(fā)周期）下周二完工，管理層盯著。”

　　神圣的曲棍球棒隨后會傳遞給下一個開發(fā)員；就像惴惴不安的僧侶一樣，我們將該死的曲棍球棒遞給下一個可憐蟲時，我們其余人會長松一口氣。

　　這不再是一種方法，它已成了一種宗教；就像大多數(shù)宗教一樣，它對外人、甚至必要時對參與者來說其實沒有多大意義。

　　敏捷起初是一個激進的概念。通過將整個產(chǎn)品周期分解成多個較小、易于管理的單位，并與小團隊合作，可以更高效地完成項目（尤其是軟件項目）。這個概念實際上仍然適用。

　　敏捷宣言（Agile Manifesto）與大多數(shù)此類聲明一樣，最初確實是個好主意。核心原則很簡單：你其實不需要一大批人來開發(fā)軟件項目才能完成任務。甚至正相反，到了一定程度，更多的人只會加大溝通阻力，并減慢項目進度。許多真正出色的開源項目都是由2人至12人組成的小型開發(fā)團隊完成的，人數(shù)控制在7人為宜。

　　你的團隊是這等規(guī)模時，設計幾乎可以作為小組活動來完成。說到顯示可證明的進展，兩周是合理的時間。開會時間要短，讓客戶在場可以使他們了解內情。另一種方法：“瀑布方法”（Waterfall methodology）意味著，客戶常常要等六個月才能看到產(chǎn)品；該階段結束時發(fā)布產(chǎn)品通常會出現(xiàn)這一幕：客戶縮在某個角落生悶氣。

　　這些年來，我開始意識到一個微妙但很重要的特點。敏捷宣言一開始就搞錯了——與其說小團隊工作起來更高效是由于它們可以遵循一種精簡的方法來完成項目，還不如說小團隊接手小項目才得以遵循一種精簡的方法、碰碰成功的運氣。

　　開放軟件項目之所以成功，就是由于完成一個項目所需的任務是比較獨立的（self-contained）——可以針對任務快速編程，可以在幾周內交付功能；設計可能很緊急，因為早早建好界面后不斷改進是可以接受、甚至受到鼓勵的做法；一旦完成，維護是別人的問題。

　　同樣重要的是，在開源軟件中，客戶可能最終會過問項目幾個月，因為那幾個月通常是最關注設計的時段。然而項目拖得越久，其他需求就越有可能占用這個客戶越來越多的時間，以至于客戶的參與頂多也就看一眼。

　　敏捷為便條紙（Post-It Note）所做的貢獻比歷史上其他任何技術都要多。

　　敏捷橫空出世時，典型的軟件項目恰好屬于敏捷擅長的范疇內。大多數(shù)軟件項目基于Web，可以在幾天內建好Web界面。它們用數(shù)據(jù)庫來存儲狀態(tài)，Web開發(fā)員通常可以隨意訪問該數(shù)據(jù)庫。這些項目花4到6個月（8到12個為期兩周的sprint）才能完成，它們主要面向客戶（用戶界面是體驗的重要組成部分，而且客戶實際上可以親眼看到變更出現(xiàn)。）

　　它們也是如果功能被砍，應用程序實際上不會因缺少的這項功能顯著降級的項目。大概在這個時候，最簡可行產(chǎn)品（minimal viable product）概念開始深入人心——這個概念是指，頭幾個sprint之后，即使開發(fā)隨后立馬停止，產(chǎn)品也是有用的。

　　毋庸置疑，公司企業(yè)開始引起注意，變得敏捷很快成為了當時的口號。敏捷從一種粗略的宣言變成了一種正式的方法，項目經(jīng)理（現(xiàn)在有了scrum大師這個重要的術語）將與經(jīng)理合作，提出“故事”，描述他們希望產(chǎn)品完成什么任務（即之前所謂的需求），并提出隨后成為完成那些故事所必需的步驟的“任務”，這些任務確立了經(jīng)理（通過scrum大師這個代理）與開發(fā)員或設計師之間的合約。

　　隨后會在這個框架內出現(xiàn)某種“舞蹈”，應用程序的整體形狀發(fā)揮作用，然后出現(xiàn)層層深入的細節(jié)，最后是具體實施。從理論上來說，如果跟蹤這些信息，你就可以確定項目是否延后；如果項目延后，分配額外的資源以改進有問題的方面。

　　從業(yè)務的角度來看，這是巨大的勝利。軟件項目本質上對經(jīng)理來說有點可怕——你投入大量資金，卻不能充分保證會因投入而看到任何成效，于是能夠在圖上看到紅色、黃色、綠色的方框可能讓人稍稍安心。

　　估計的問題在于，它有賴于事先了解所有事實。編程本質上就是適度可知的創(chuàng)新。實現(xiàn)的敏捷方法最初旨在更好地處理這些事實。

　　當然，問題在于細節(jié)，在于人類行為的本質。

　　大多數(shù)項目管理立足于這個想法：任務是可度量的，基于完成這同一任務的其他人設定的度量標準。組裝裝配線是一項很容易預測的任務（舊經(jīng)濟中是這樣），又由于經(jīng)常組裝，可以估計組裝所需的時間（出入沒幾天）。遺憾的是，開發(fā)軟件不可預測。幾乎無一例外的是，就算標價很高，購買現(xiàn)成軟件通常至少更便宜，即使從企業(yè)組織的角度來看未必總是更好。原因很簡單——你尋求的功能早已存在，有人嘗過了首次（數(shù)次）構建這個應用程序的苦頭。

　　構建登錄功能需要多長時間？編寫用戶界面大約需要一小時。編寫后端代碼可能短則30分鐘，長則30天。如果你希望與一個只支持LDAP的非標準平臺上的Active Directory驗證系統(tǒng)全面集成，又希望將兩遍（two-pass）電子郵件驗證系統(tǒng)集成到里面，那么用戶界面（UI）是你最不擔心的方面。一個漂亮的網(wǎng)絡圖儀表板顯示你系統(tǒng)中所有組件如何相互關聯(lián)，并允許拖放操作，你覺得怎么樣？別嚇我了。我仍在做這方面的惡夢。

　　計算機編程界存在一種謬見：所有應用程序最終都可以分解——也就是說，可以將復雜的應用程序分解成多個較簡單的應用程序。然而實際上，除非你讓正確組合的組件正常運行，否則常常無法讓更復雜的行為實際開始工作；就算那樣，你也會在數(shù)據(jù)可用性的同步、內存使用及釋放以及競爭條件等方面遇到問題——等你做好了大部分管道工作，這些問題才顯露出來。

　　這就是為什么“但它會擴展嗎？”進入各地程序員的詞匯庫。只有在你幾乎完全構建好了系統(tǒng)，并嘗試讓系統(tǒng)在更極端的條件下運行時，擴展問題才出現(xiàn)。解決方案常常需要丟棄你剛構建的相當多組件，這讓各地的經(jīng)理們驚愕不已。

　　這就是為什么如果能助一臂之力，開發(fā)員很討厭確定任務具體需要多長時間的原因之一。開發(fā)員要將其工作與其他開發(fā)員整合起來時，尤其是對于同時開發(fā)的那些組件而言，這就成了更嚴重的問題。如果兩個組件的相互關系之間存在“阻抗不匹配”，重新設計那些組件可能增添難以衡量的時間和復雜性。

　　它還表明敏捷并不總能很好地擴展。集成依賴關系常常未加以跟蹤（或被歸入層次化的故事），但它往往是任何軟件開發(fā)中最容易變化的方面之一。

　　實際上，這與其說是敏捷的錯誤，還不是說是其最常用工具的錯誤。嚴格來講，這樣的項目圖是信息圖，而不僅僅是樹。你在空間、時間、組織、抽象和復雜性等方面有依賴項，針對復雜性估計時間常常是這些工具最薄弱的環(huán)節(jié)。另一方面，若有太多的人參與項目，這項工作也會變得更糟，因為管理這類項目的復雜性會逐漸加大。

　　這種方法的還有一個結果是，面對龐大團隊，規(guī)劃所需的時間常常最多占到開發(fā)可用總時間的四分之一。另一個結果是，對最簡可行產(chǎn)品的持續(xù)強調意味著在任何一個時間點，開發(fā)員最終花費大量的時間來構建和展示他們迄今為止的工作成果，占了可用時間中另外的10%到15%，常常耗費在被扔掉的代碼上。

　　由于這實際上在相當于兩周的sprint中留給開發(fā)的時間只有“一周”，另一個缺點是你在這個sprint內只能完成最基本的組件。一旦你為scrum會議耗費了另一天，尤其如此。這種會議通常只有15分鐘，但實際上，出現(xiàn)問題時，會議很可能越來越長。將sprint延長到三周較為明智，但實際上很少有組織這么做。

　　這種會議的另一個副作用影響到了經(jīng)理，他們的角色決定了常常參與組織中多個層面的scrum，這意味著他們因此沒多少時間從事戰(zhàn)略性的領導工作，并迫使他們進行微觀管理，通常效果不佳。

　　對敏捷最熱衷的常常是人力資源咨詢機構，盡管它們在任何項目方面的目標是，讓受雇開發(fā)項目的開發(fā)員和支持人員盡可能多。這頗具諷刺意味，因為出現(xiàn)的情況是，敏捷在經(jīng)典的瀑布方法（注重精確的規(guī)范和詳細的預先規(guī)劃）實際上優(yōu)先的業(yè)務部門用得最多。

　　以數(shù)據(jù)為中心的問題不是很適合敏捷擅長處理的獨立的開源領域。隨著越來越多的商業(yè)項目往這個方向發(fā)展，敏捷這種方法的效用隨之下降。

　　除此之外，值得一提的是，對大批的項目而言，傳統(tǒng)的敏捷方法適得其反。尤其是企業(yè)數(shù)據(jù)項目不符合適合使用敏捷的標準，這有幾個原因：

　　公平地說，雖然企業(yè)知識領域有幾種開發(fā)方法，但這個領域本身足夠新，沒有一種方法可以像敏捷在應用程序開發(fā)領域那樣在企業(yè)數(shù)據(jù)系統(tǒng)領域揚名立萬。這應該不足為奇——近期才開始關注企業(yè)數(shù)據(jù)本身。

　　企業(yè)數(shù)據(jù)項目的一個關鍵方面不在于系統(tǒng)之間管道的技術集成，而在于將數(shù)據(jù)模型從一個系統(tǒng)映射到另一個系統(tǒng)，無論是通過篩選還是通過機器學習。換句話說，所開展的那種工作正從工程問題（用于連接系統(tǒng)的專用短期項目）變?yōu)楹Y選問題（通過少量的技術工具來映射模型）。

　　這種轉變也表明了敏捷的未來最終會怎樣。在許多方面，我們正告別以應用程序為中心的時代——應用程序更輕盈，主要基于Web：在這種環(huán)境下，連接至數(shù)據(jù)集和復合企業(yè)數(shù)據(jù)將比基于客戶端的復雜功能更重要。移動應用程序也是如此——智能手機和平板電腦應用程序日益只是移動HTML + CSS外面那層薄薄的外殼，這與“某某有應用程序”時代相比是個巨變。

　　客戶端是相對輕盈的端點，這意味著敏捷最初問世并最適合的那個環(huán)境：獨立的開源應用程序在消失。如今，典型的應用程序更可能是某種數(shù)據(jù)流，價值不在于編程，而在于數(shù)據(jù)本身，因此編程（以及廣泛得多的現(xiàn)有工具）比20年前、甚至比10年前簡單得多。

　　也許這類應用程序的最后一片天地是游戲這個類別；即使在這個類別，也出現(xiàn)了幾種一致穩(wěn)定的工具集，比如Unreal Engine，這意味著技術組件日益融合，而敏捷其實完全退縮到設計和媒體創(chuàng)作等領域。

　　從長遠來看這表明工作方法正朝異步事件模型發(fā)展；在這種模型中，信息流連接起來、映射，然后以不可預測的方式轉換成原生模型。我們發(fā)布平臺，然后發(fā)布“如同連續(xù)劇”的內容，一些小到一條推文，一些大到數(shù)GB的游戲更新。雖然敏捷的一些方面會仍然存在，但后敏捷世界有不同的優(yōu)先事項和要求，我們預計最后接它班的任何范式會將信息流作為信息的基本單位來處理。

　　因此，敏捷沒“死”，但它變得越來越邊緣化。

　　英文原文鏈接：https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/?ss=ai-big-data#2c9b58572071