2

再給敏捷一次機會

(資料圖片僅供參考)

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

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

可復(fù)雜的大團隊呢，天然就會慢，天然就復(fù)雜，天然就會深度依賴。而現(xiàn)如今的汽車軟件供應(yīng)鏈就是典型的大團隊，著實難以應(yīng)對。

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

下面我們會初步總結(jié)一些亮點。

3

SAFe的幾個主要增量與亮點

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

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

協(xié)調(diào)對齊

信息透明

快速集成

節(jié)奏同步

給知識工作者自由度

設(shè)計敏捷

敏捷發(fā)布火車

PI（Planning Interval）規(guī)劃會議

4

SAFe導(dǎo)入汽車企業(yè)的對應(yīng)價值??????????

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

4.1 協(xié)調(diào)對齊

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

可當(dāng)團隊擴充到50人、200人、1000人、10000人時呢，就是喊破喉嚨也像是在玩?zhèn)髀曂驳挠螒颍阶詈蠖紓鞯闷吡惆寺洌踔吝€是跨國、跨公司，想打個電話都得考慮時差。

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

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

協(xié)調(diào)對齊會涉及到方方面面，這里重點講以下幾點：

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

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

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

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

4.2 信息透明

透明并不新鮮，所有的敏捷都在強調(diào)透明，但還是覺得這對大規(guī)模團隊敏捷轉(zhuǎn)型的意義不凡。

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

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

4.3 快速集成

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

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

此外，我們汽車軟件開發(fā)經(jīng)常遇到的一個瓶頸是，沒有ECU、沒有線束、沒有周邊件、沒有臺架、沒有整車環(huán)境，這所有的東西都代表了一層層集成，所以，集成既是目標(biāo)，也是實現(xiàn)目標(biāo)的手段。

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

4.4 節(jié)奏同步

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

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

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

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

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

在整車軟件開發(fā)中，節(jié)奏的穩(wěn)定可以讓所有有依賴關(guān)系的團隊能夠穩(wěn)定可預(yù)測地協(xié)作，這是節(jié)奏的意義。

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

4.5 給知識工作者自由度

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

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

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

4.6 設(shè)計敏捷

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

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

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

設(shè)計水平的突破將會讓效率有數(shù)量級的躍遷，這個不多講，需要沉淀及量變引發(fā)質(zhì)變。

4.7敏捷發(fā)布火車

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

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

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

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

產(chǎn)品管理（Product Management，PM）擁有、定義敏捷發(fā)布火車待辦事項，并確定其優(yōu)先級。

系統(tǒng)架構(gòu)師（System Architect，SA）為敏捷發(fā)布火車相關(guān)團隊提供架構(gòu)指導(dǎo)和技術(shù)支持。

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

業(yè)務(wù)負責(zé)人（Business Owner，BO）是敏捷發(fā)布火車的關(guān)鍵利益相關(guān)者。

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

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

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

平臺團隊：圍繞平臺開發(fā)和支持進行組織的團隊，這類平臺負責(zé)為其他團隊提供服務(wù)。

賦能團隊：這類團隊可利用其專業(yè)能力協(xié)助其他團隊，幫助其他團隊熟練掌握新技術(shù)。

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

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

提出了一種相互依賴的多線開發(fā)團隊融合的形式，比較適合復(fù)雜系統(tǒng)化產(chǎn)品的開發(fā)。

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

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

4.8 PI規(guī)劃會議

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

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

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

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

5

寫在最后

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

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

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

SAFe值得一試。

仍然需要大量裁剪。

關(guān)鍵詞：