敏捷走到頭了！

作者：Kurt Cagle是一名數據科學家兼未來學家，關注計算機技術與社會的交匯。他是智能數據公司Semantical，LLC的創始人，目前在開發一個基於雲的知識庫，將於2020年初公開發布。

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

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

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

「scrum大師，我會按您的要求寫三個模塊，我拖慢了團隊的平均進度，現在有負諸位。」

「夥計，你看著辦，sprint（迭代開發周期）下周二完工，管理層盯著。」

神聖的曲棍球棒隨後會傳遞給下一個開發員；就像惴惴不安的僧侶一樣，我們將該死的曲棍球棒遞給下一個可憐蟲時，我們其餘人會長鬆一口氣。

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

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

小即好

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

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

敏捷很時髦、很酷，還涉及斐波那契數列。有什麼不喜歡的呢？

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

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

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

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

變得敏捷

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

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

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

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

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

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

敏捷在哪裡碰壁？

當然，問題在於細節，在於人類行為的本質。

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

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

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

這就是為什麼「但它會擴展嗎？」進入各地程序員的辭彙庫。只有在你幾乎完全構建好了系統，並嘗試讓系統在更極端的條件下運行時，擴展問題才出現。解決方案常常需要丟棄你剛構建的相當多組件，這讓各地的經理們驚愕不已。

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

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

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

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

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

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

對敏捷最熱衷的常常是人力資源諮詢機構，儘管它們在任何項目方面的目標是，讓受雇開發項目的開發員和支持人員儘可能多。這頗具諷刺意味，因為出現的情況是，敏捷在經典的瀑布方法（注重精確的規範和詳細的預先規劃）實際上優先的業務部門用得最多。

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

數據項目和後敏捷世界

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

企業數據系統（EDS）格外重視數據建模，視數據源和組織規模而定，複雜性決定了需要短則幾天、長則幾個月。

EDS項目往往專註於查詢、轉換和數據移動（攝取和服務），沒有一個通常面向客戶。

EDS項目通常在進行中，需要結合自動化數據攝取和主動數據篩選，而不是有時間限制的應用程序開發。

由於EDS具有通常廣泛的特性，navigator、知識庫、數據中心和類似應用程序比專門的應用程序更合適，這意味著對定製開發的需求也保持在最低限度。

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

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

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

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

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

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！