2

再給敏捷一次機會

(資料圖片僅供參考)

以前接觸的敏捷呢，大抵是以Scrum為代表的小規模敏捷，各路英豪基本都套過殼了、實踐過了，很多人說沒啥用，當然，也有的人在ppt里寫的有用。

實際上，小團隊天然就是敏捷的，人少，事少，幾個人坐在一起開會、加班就能快速響應，離客戶也非常近，敏捷方法可以一定程度規整下，但本身似乎不起決定作用。

可復雜的大團隊呢，天然就會慢，天然就復雜，天然就會深度依賴。而現如今的汽車軟件供應鏈就是典型的大團隊，著實難以應對。

反復糾纏之下，我是對小團隊小規模敏捷沒啥耐心了，而正在我與敏捷徹底決裂的最后關口，最近，參與到了一個SAFe轉型項目，些許點滴讓我意識到，似乎這些因素確實會對大團隊汽車軟件開發有些益處，這給我帶來了興致。于是，我私自決定，再給敏捷一次機會，但是給SAFe的。

下面我們會初步總結一些亮點。

3

SAFe的幾個主要增量與亮點

精益、價值、互動、解耦、小顆粒、迭代、增量……這些理念都是所有敏捷方法論提及的，SAFe也不例外，我們不多講，我們站在汽車行業的立場，把一些主要增量或者亮點提煉出來。

SAFe有著自己的價值觀、原則、方法與實踐，進而形成一整套有邏輯層次的框架體系，但出于實用的目的，且只著眼于關鍵點，我們就不做分類，僅做平級羅列。?????????????????

協調對齊

信息透明

快速集成

節奏同步

給知識工作者自由度

設計敏捷

敏捷發布火車

PI（Planning Interval）規劃會議

4

SAFe導入汽車企業的對應價值??????????

在這一小節，我們開始將上面總結出來的8個點與汽車企業匹配，嘗試看其適用性。?

4.1 協調對齊

小團隊不太存在這種問題，一個5個人的團隊，喊一嗓子就知道對方怎么想的、要做什么了。

可當團隊擴充到50人、200人、1000人、10000人時呢，就是喊破喉嚨也像是在玩傳聲筒的游戲，到最后都傳得七零八落，甚至還是跨國、跨公司，想打個電話都得考慮時差。

這讓我想起以前在一家大型外企做項目經理時的經歷，公司流程規定，PM必須一周組織一次會議，目的就是對齊信息與協調行動，雖然顯得粗笨，但倒是個最常見的解決方法。

汽車企業基本就屬于這類跨組織的大團隊，對齊團隊的想法、觀念，觀點極為困難，又極為有價值，SAFe把這一點提出來，算是切中了一些要害。

協調對齊會涉及到方方面面，這里重點講以下幾點：

背景信息的對齊。在大型汽車組織里，尤其是開發、測試等細分領域的角色，往往處于領任務的小視角里，不知道為什么做，不知道為什么這個時間做，也不知道做給誰。我們不談使命、愿景、價值觀，至少在不知道任何背景信息的前提下，人的主觀能動性會很差。

統一組織溝通語言。初到一家大型外企時，我們通常需要一套術語表來快速入門，這套術語表就是這個組織的溝通語言之一，它的存在就不至于讓我們面臨我講的ABC和你講的ABC是兩回事這種情景。再舉個軟件的例子，軟件開發經常會劃分各類feature、system、sub-system、module、unit名稱，這些名稱的對齊與映射就是一個非常提升效率的工作。

深入理解客戶。廣義來看，客戶是全方位的，只要你要交付結果給對方驗收，對方就是你的客戶。這樣的話，汽車體系里會有大量的“客戶”存在，把對客戶理解的一致拿出來強調也應是題中之義。

持續檢驗對齊程度。時局動蕩不安，公司內部也是風起云涌，對齊僅僅是暫時的，我們需要不斷對齊。這讓人本能地會想到多開會，但是否有更好的實踐，我們暫且不表，繼續往下看。

4.2 信息透明

透明并不新鮮，所有的敏捷都在強調透明，但還是覺得這對大規模團隊敏捷轉型的意義不凡。

看到一個說法是，管理者的權力之一是信息差，所謂信息差就是話語權。話沒毛病，毛病是，我們經常會看到一種本該令人匪夷所思卻又被教育“年輕人不要太較真"的現象，比如，A團隊正在做一件B團隊半年前已經證明沒意義的事，而C團隊正在用另一種思路做同樣的事，但是，很有默契的是，ABC這三個團隊都悄悄地等待一鳴驚人，見面時還要微笑致意，我啥都沒干。

信息不共享，這是一種很可怕的文化，而這種文化在汽車企業里比比皆是。期待能設計一種可視化的工作流程或者工具來一定程度打破這種無用的壁壘。

4.3 快速集成

看到這一條，我甚至有點興奮。

為什么很多互聯網出身的產品經理講的東西很難引起汽車人的共鳴？就是因為汽車不是一個產品，而是一大堆產品的集合，而這集合又不是簡單堆疊，是有機的集成，是磕磕碰碰的集成，是手心手背都是肉的取舍下的集成，是只有集成后才能體現功能與性能的集成。這大大小小的各層級集成占了汽車開發的半壁江山。

此外，我們汽車軟件開發經常遇到的一個瓶頸是，沒有ECU、沒有線束、沒有周邊件、沒有臺架、沒有整車環境，這所有的東西都代表了一層層集成，所以，集成既是目標，也是實現目標的手段。

因此，加大開發環境的投入，支持快速不斷地集成，對于規模化敏捷頗為必要，要避免憋大招。

4.4 節奏同步

最早接觸節奏（時間盒）這個概念是在幾年前和一個宣稱在走敏捷的印度軟件團隊合作的故事里。

當時，我的項目非常著急，因為要趕客戶一個月后的交樣，一個關鍵環節是需要印度軟件團隊完成某個重要feature的上線，經過千辛萬苦，恰好匹配上了印度團隊的2周sprint時間盒。

可是，還沒等氣兒喘勻，軟件項目經理就帶來個噩耗，原來忙中出錯，給印度團隊的需求基線傳遞錯誤......

再去溝通，告訴我們兩周后才接新需求。然后，我們只能坐在那里等著交樣延期......盡管后來通過其他方法解決了問題，但當時這個“時間盒”的說法讓我覺得既蠢且壞。

后來慢慢知道，印度團隊是同步支持全球很多項目的軟件開發，堅守時間盒就是保持固定的節奏，節奏的穩定會讓很多相關方的規劃能夠執行。拋開我的單個項目的立場，放在整個組織看，理論上，是能夠保持更全面的穩定價值交付的。

在整車軟件開發中，節奏的穩定可以讓所有有依賴關系的團隊能夠穩定可預測地協作，這是節奏的意義。

除了單線有節奏，還有多線的同步，這是SAFe在這里的關鍵點，這讓汽車軟件多至幾十條線的開發能夠被統一調度，也有利于我們的跨職能權衡，以及4.3講的集成，否則，各層級集成就會存在大量的等待。

4.5 給知識工作者自由度

特別是軟件開發相關人員，是非常典型的知識工作者，靠腦力活動來實現價值增值。

很多管理者有著非常大的ego，自視甚高，不可否認，管理者有著相對宏觀的視角，但是對于如何處理手里的工作，沒有人比員工自己更有發言權。

給知識工作者信息、自由度、支持，并釋放他們的激情與活力，這應該是一個優秀管理者應該且能夠做到的。否則，員工只能把精力花在去證明你是對的上面了。

4.6 設計敏捷

說起這個，我非常快速地想到了防錯，這種源自機械結構的設計理念可以很方便用來解釋“設計敏捷”的內涵。

對于上圖左側的ABC形狀，怎么才能不放錯呢？染色？教育？培訓？練習？實際上，最有效的方式是放不錯，就像右側那張圖。

設計敏捷的內涵也在于此，從架構、軟件、工具本身的設計上就具備敏捷的特性，比如，常講的解耦與自動化。

設計水平的突破將會讓效率有數量級的躍遷，這個不多講，需要沉淀及量變引發質變。

4.7敏捷發布火車

這個名詞是SAFe比較典型的增量之一。

按照SAFe的理念，一輛敏捷發布火車是指由5~12個敏捷團隊（PO、Scrum Master、Team）組成的虛擬組織（50~125+人），利用時間盒迭代來保持節奏，并過PI規劃會議來實現同步，以及通過敏捷發布火車待辦事項來對齊共同目標。

從SAFe的角度，提供了5類角色的定義：

發布火車工程師（Release Train Engineer，RTE）是敏捷發布火車的教練。

產品管理（Product Management，PM）擁有、定義敏捷發布火車待辦事項，并確定其優先級。

系統架構師（System Architect，SA）為敏捷發布火車相關團隊提供架構指導和技術支持。

系統團隊（System Team）提供流程和工具，以便盡早、頻繁地集成與評估資產。

業務負責人（Business Owner，BO）是敏捷發布火車的關鍵利益相關者。

此外，還提供了4類團隊定義：

流對齊團隊：圍繞工作流程進行組織的團隊，能夠為客戶或最終用戶直接交付價值。

復雜子系統團隊（專項團隊）：圍繞特定子系統進行組織的團隊，這類子系統需要深厚的專業技能和專業知識提供支持。

平臺團隊：圍繞平臺開發和支持進行組織的團隊，這類平臺負責為其他團隊提供服務。

賦能團隊：這類團隊可利用其專業能力協助其他團隊，幫助其他團隊熟練掌握新技術。

客觀來看，這些角色和團隊在傳統汽車電子企業里本身也幾乎都存在，并不具備明顯的特殊性。

當然，敏捷發布火車仍然頗有意義，主要價值貢獻在于以下3點：

提出了一種相互依賴的多線開發團隊融合的形式，比較適合復雜系統化產品的開發。

通過節奏同步保證了可預期的價值交付，并減少了等待浪費。

這種組織模式有助于直接交付價值，較容易實現勁往一處使和縮短交流路徑。

4.8 PI規劃會議

對比敏捷發布火車，PI是另一個SAFe更核心的增量，以及最具代表性的形式。

PI規劃會議是一項有固定節奏的活動，可作為敏捷發布火車的心跳，確保敏捷發布火車每8~12周舉辦一次為期兩天的PI規劃會議，會議上可以進行feature優先級定義、故事點估算以及處理接口與依賴等事務。

這種強制的見面會能夠提供一個溝通平臺，讓大家對齊、協調，并快速決策。

不過，幾次實際體驗下來，效果雖逐漸好轉，但還不盡如人意，比我預想的要差一些，多數人還是無法被調動起積極性來，仍然需要持續摸索、調整。

5

寫在最后

說句開玩笑的話，SAFe是讓我對敏捷的印象有了很大的改觀。

我們前面總結的SAFe的8個亮點（協調對齊、信息透明、快速集成、節奏同步、給知識工作者自由度、設計敏捷、敏捷發布火車、PI規劃會議）確實能對應上大型汽車組織的通病和痛點。

但實踐下來，仍然感受到很大的不適，需要適配。截至目前，個人的觀感分兩部分：

SAFe值得一試。

仍然需要大量裁剪。

關鍵詞：