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

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

　　那個(gè)scrum大師（坐著(zhù)的那個(gè)人，別人都站著(zhù)）會(huì )在敏捷工具Rally或Jira中及時(shí)記下這點(diǎn)，然后會(huì )說(shuō)：“你差三個(gè)模塊。預計今天可以寫(xiě)好這些模塊嗎？”

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

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

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

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

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

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

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

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

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

　　同樣重要的是，在開(kāi)源軟件中，客戶(hù)可能最終會(huì )過(guò)問(wèn)項目幾個(gè)月，因為那幾個(gè)月通常是最關(guān)注設計的時(shí)段。然而項目拖得越久，其他需求就越有可能占用這個(gè)客戶(hù)越來(lái)越多的時(shí)間，以至于客戶(hù)的參與頂多也就看一眼。

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

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

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

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

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

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

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

　　當然，問(wèn)題在于細節，在于人類(lèi)行為的本質(zhì)。

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

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

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

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

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

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

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

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

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

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

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

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

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

　　公平地說(shuō)，雖然企業(yè)知識領(lǐng)域有幾種開(kāi)發(fā)方法，但這個(gè)領(lǐng)域本身足夠新，沒(méi)有一種方法可以像敏捷在應用程序開(kāi)發(fā)領(lǐng)域那樣在企業(yè)數據系統領(lǐng)域揚名立萬(wàn)。這應該不足為奇——近期才開(kāi)始關(guān)注企業(yè)數據本身。

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

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

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

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

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

　　因此，敏捷沒(méi)“死”，但它變得越來(lái)越邊緣化。

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