當心SAFe（企業級擴充套件敏捷框架）變成黑暗的邪惡化身 - Sean Dexter

banq發表於2020-01-09
套件敏捷框架

企業級可擴充套件敏捷框架是一些原則和實踐的集合，旨在為大型公司提供一種“擴充套件”敏捷工作模型的方法。自2011年成立以來，SAFe經歷了巨大的增長。全球將近有一百萬人成為SAFe認證從業者。
我實際上認為SAFe 非常糟糕。它宣稱看似明智的價值觀，然後轉而強加了扼殺真正敏捷性的過程和結構。有許多質量各異的“擴充套件框架”，但特別是SAFe體現了最嚴重的誤解和應用不佳的敏捷思維。
SAFe與敏捷思維方式不一致的許多方式應該很清楚。它以程式設計為中心的官僚主義、複雜、包括許多通常不必要的過程，削弱了團隊的自主權等等。

SAFe實現官僚地自上而下的控制
在最高階別（稱為“投資組合”），SAFe確實主張為不確定的“價值流”提供資金-通常代表產品，產品線或客戶型別。但是，控制資金的精益專案組合管理團隊（LPM）（以前負責瀑布式專案預算的人可能是唯一的權力）批准每個流向哪些專案組合（大型計劃）。Epics並不是對需要解決的問題的解釋。它們是關於如何最好地解決這些問題的預先形成的想法。
高階思想者提出想法，低階思想者執行那些想法。忽略了最接近工作的人可能最有能力做出決定的可能性。 
SAFe將小型產品團隊（通常是Scrum團隊）召集到“敏捷釋出培訓”中，這些團隊具有額外的管理角色層，這些角色包括產品經理（PM），系統架構師（SA）和釋出培訓工程師（RTE）。在“程式設計級別”中跨每個組，通常，這些角色會阻礙團隊的自治。它們與提供的價值成比例地增加了流程和通訊開銷。
SA和PM定義並分解較大的工作（通常從上面的投資組合過程繼承），然後將這些工作傳遞給團隊，從理論上講，產品負責人和團隊可以會優先考慮其他較小的工作，而不是強加於他們的工作，來自最高層領導部署的工作視為最重要的工作就具有自然的壓力。因此，產品負責人的角色必須被簡化為撰寫故事和檢查驗收標準，而不是作為產品領導責任的單一最初意圖。
系統架構師無法接近實際的工程工作，因此他們傳遞的體系結構計劃可能與工作的實際情況脫節。這些角色是大型設計前瀑布專案的標誌，並且在SAFe中得到了很好的保留。
釋出培訓工程師定義一致的跨團隊流程和節奏，並處理許多操作任務。最終，這為單個團隊留出了更多空間來修改，改進或試驗自己的實踐，而這些實踐都偏離了既定標準。
有時，所有這些問題都會透過新增“大型解決方案級別”而再次重複出現，“大型解決方案級別” 是一組團隊，每個團隊的角色與程式設計級別的團隊相似，但跨越發行培訓。發生這種情況時，很可能會重複同樣的問題，但是解決方案級別似乎不太常見。

SAFe採用最差的方法來管理依賴項
依賴關係是團隊需要等待其他地方完成一些事情才能完成自己的工作的例項。SAFe的構造是一種倒退的態度，即依賴是生活中不可改變的事實，有時甚至將它們稱為戰略優勢。以下是SAFe未重視甚至完全忽略的一些建議：

  1. 鼓勵內包(inner-sourcing )文化，一個團隊可以將工作提交到另一個團隊的程式碼庫，而不必依賴於他們，而不必接受合併
  2. 使團隊成員可以在需要時輕鬆地臨時或永久交換團隊
  3. 專注於僱用，組織和培訓團隊，無需外部幫助即可滿足自己的需求

SAFe實際選擇如何管理依賴項是透過更加關注計劃、流程、層次結構和標準化。可以預見，這將導致大量會議干擾完成工作的能力。它透過一次全面推廣而強加了這種方法，該推廣會立即影響整個組織。如果沒有其他繁瑣的結構，就不會考慮在哪些領域可以讓團隊自力更生。

SAFe過度圍繞程式設計
SAFe的一項核心功能是大約10周的程式設計增量（PI）。您可以想到包含所有常規Sprint的大型Sprint。
每個PI都以PI程式設計活動開始，該活動持續約兩天。PI程式設計還需要在程式設計級別進行前程式設計和後程式設計活動。
讓人們親自聚在一起建立關係，共享資訊並圍繞目標定向無疑具有一定的價值。另一方面，使用有限的時間視窗根據預先定義的功能為特定的使用者故事制定10周的計劃，然後要求對這些程式設計做出承諾，其價值將大大降低。
一旦PI程式設計結束，一旦學到新知識，那些基於有限理解和眾多假設而建立的程式設計將被淘汰。團隊將不斷地陷入沒有意義的工作和重新定位期望的過程中，原因可能是他們之上的人可能無法理解的原因。


SAFe圍繞數量而不是價值
在所有關注量度指標、估算和透過管道進行變動的工作中，很容易失去真正有價值或成功的概念。
SAFe意識到它不是以價值為中心的，並且最近在其文件中增加了“設計思想”，“以客戶為中心”和其他概念以彌補損失。到目前為止，我還不相信它會在其過程中進行任何重大更改，而這些更改實際上為這些事情留出了空間，並且甚至一開始就理解它們也感到很困惑。

SAFe不必要地複雜
SAFe具有天生的優勢，可以防止受到批評。它是如此複雜，以至於難以完全理解。儘管我花了很多時間研究框架，但我仍然可能會出錯或遺漏某些重要方面。但是，複雜性本身就是一個合理的問題。SAFe有如此多的會議，檢查點，價值和方法，幾乎​​不可能使每個人都在同一頁面上。

SAFe限制回顧和持續改進
程式設計級別及更高階別的角色可能無法參加所有團隊回顧。這意味著實際上可以改變許多正在討論的事情的人們將不會直接聽取回顧。
SAFe試圖對此進行補償的方式還不夠。

SAFe降低了其彙總的概念
SAFe的關鍵是現有概念的集合，例如Scrum，看板，精益產品，精益使用者體驗和DevOP。如果您不熟悉，建議您隨時間推移而不是一次全部探索每個概念。許多功能本身很有價值，但是SAFe不能在實際合成它們方面做得很好，有時會增加混亂。
SAFe通常會擁護其實踐遵循“精益敏捷”原則。訣竅在於，“精益敏捷”實際上並不指“精益”或“敏捷”原則。相反，“ 精益敏捷原則 ”是SAFe自己設計的創造。這套新的“原則”扭曲了它所吸收的概念。

SAFe不敏捷
到目前為止，SAFe與敏捷思維方式不一致的許多方式應該很清楚。它以程式設計為中心的官僚主義、複雜、包括許多通常不必要的過程，削弱了團隊的自主權等等。

事實證明SAFe起作用的所有案例研究如何？
scaledagileframework.com上有約40個成功採用SAFe的案例研究。失敗的案例研究明顯缺乏。相反的縮寫，安全涉及跨越一個巨大的生態系統為一到一個巨大的新的程式同步變化巨大的風險。除非這40家成功的公司中的每家都擁有11,250名獲得SAFE認證的從業人員，否則我們不會聽到很多公司的訊息。
2016年，消費技術公司Fitbit向市場釋出了四款受到消費者好評的新產品，並出貨了超過2200萬臺裝置。一年之內交付最多產品的部分原因是該公司對SAFe （Scaled AgileFramework ）的承諾以及成功採用SAFe 作為擴充套件團隊以達到目標日期的一種方式。
現在，我們無法真正將Fitbit的失敗歸因於我們擁有的資訊量對SAFe的採用。但是，如果一家公司可以為此付出很大的努力，並且仍然希望採用SAFe來提高他們的產品決策的響應速度，那麼在檢查其餘案例研究時，我的視線會更加狹窄。

這是過渡步驟，對嗎？
SAFe路線圖中沒有任何地方實際上將其任何核心實踐稱為過渡性的。如果這是一個過渡框架，那麼在提供任何型別的過渡計劃方面都做得很差。
對認證的過度關注也損害了框架的靈活性。如果您花費大量的時間來獲得認證，認證將成為您自己價值的一部分。

點選標題見原文
 

相關文章