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

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

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

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

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

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

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

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

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

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

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

　　開(kāi)放軟件項(xiàng)目之所以成功，就是由于完成一個(gè)項(xiàng)目所需的任務(wù)是比較獨(dú)立的（self-contained）——可以針對(duì)任務(wù)快速編程，可以在幾周內(nèi)交付功能；設(shè)計(jì)可能很緊急，因?yàn)樵缭缃ê媒缑婧蟛粩喔倪M(jìn)是可以接受、甚至受到鼓勵(lì)的做法；一旦完成，維護(hù)是別人的問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　從長(zhǎng)遠(yuǎn)來(lái)看這表明工作方法正朝異步事件模型發(fā)展；在這種模型中，信息流連接起來(lái)、映射，然后以不可預(yù)測(cè)的方式轉(zhuǎn)換成原生模型。我們發(fā)布平臺(tái)，然后發(fā)布“如同連續(xù)劇”的內(nèi)容，一些小到一條推文，一些大到數(shù)GB的游戲更新。雖然敏捷的一些方面會(huì)仍然存在，但后敏捷世界有不同的優(yōu)先事項(xiàng)和要求，我們預(yù)計(jì)最后接它班的任何范式會(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