引子：規模化敏捷轉型從來不是一件容易的事情。當只有1-2個敏捷團隊進行協同的時候，計劃和工作同步是可控的。團隊和產品負責人互相聊一聊，基本就能搞清楚需要做什么，一個簡單的SOS架構（Scrum of Scrums）就能搞定。但是，當涉及到多個團隊的時候，事情將會變得十分痛苦：

• 特別是如何讓各個團隊向著同一個方向前進而不是成為互相的羈絆；

• 如何在跨多個迭代、多個團隊、多個產品的情況下進行計劃和安排優先級；

• 如何讓所有團隊保持同樣的交付節奏；

• 如何實現跨團隊的持續集成；

• 如何解決團隊間工作的依賴；

• 如何消除項目整體的風險；

• 如何防止需求的緊急搭車；

• 如何防止局部優化；

• 如何選擇適合的協調人；

• 如何提高團隊間開會的效率。

• ……

這些問題都需要解決。同時，規模化敏捷轉型影響巨大，不僅僅要保證轉型的效果，還要降低轉型的各種風險，也就是說規模化敏捷必須是SAFe（安全的）。但如何做到這一點呢？我們采訪了一位資深敏捷實踐從業者，看看他的現身說法：Even， 現任某公司技術產品經理 10年+研發經驗 曾任某銀行內部敏捷與DevOps教練 DevOps廣州社區核心組織者 POPM@SAFe
專注敏捷與DevOps, 熱愛技術，專研產品與創新，自帶正能量，喜歡結交有上進心的志朋好友，熱衷分享并積極參與社區活動。背景：Even所在公司，一個敏捷發布火車(ART)有十幾個團隊，一個PO一般帶2個團隊，他現在是其中的一個PO（你知道嗎？人家以前還擔任過Scrum Master呢，這華麗轉型，是典型的斜杠青年啊！！）；給大家來幾張照片，看看人家的SAFe 實際場景。圖1 十幾個團隊同時開早會的場景，好壯觀啊！！

圖2 是開PI planning會議的場景，十幾個團隊的人一起做計劃，挑戰的不僅僅是公司有沒有這么大的會議室，更是如何同步多人進行高效會議，幸好SAFe有標準的建議日程與形式。

1、你們在實施SAFe之前組織中遇到了哪些痛點？?痛點1：加人后感覺并沒有增加生產力因為是新的部門，在最近的一年中，都不斷有新人加入，至少增加了幾十個人，目前部門大概300多人，研發占7到8成吧，我們實行了1年多的SAFe，感覺在增加研發人數的過程中，好像并沒有對交付產生實質的增產，由于一些原因，不是很方便公布數據，這個是否和SAFe或者敏捷有關，不得而知。痛點2：我們是在追求epic的完成率嗎？從開始到現在，已經是第9個PI（program increment)了，除了前3個PI是適應期之外，后面的PI里，每個PI的完成率并沒有實質性的提高，甚至有降低的情況出現，我們是在追求epic的完成率嗎？為什么提出這個問題，因為我們是做平臺的，可以比如是做阿里云平臺，對于大型的平臺型產品來說，我們交付的東西不能在一個sprint甚至是一個PI完成，這個是非常正常的事情，所以我們在反問自己，我們是在追求epic的完成率嗎？痛點3：前端與測試團隊的劃分問題我們還有一幫做前端的同事，嘗試過把他們分到一個團隊，也嘗試過把他們分到項目組，兩種方式都不是很成功。由于我們是做平臺的，并不是每個團隊都需要前端，所以把他們分到團隊并不是很成功，把他們單獨組隊，他們因為不能獨自接feature來做，也不是很成功。這也算是一個痛點吧。對于測試團隊來說，也有這樣的問題，這兩個團隊都是半實半虛的。2、眾多大型敏捷選擇SAFe的原因？?在我加入之前就已經跑了3個PI了，這個我從前輩處聽說的是，他們選擇的時候看到SAFe比較適合平臺型的產品，因為我們是做平臺的，有scrum, 有PI（大迭代），有發布火車，有PO和Product Manager,這些角色，看起來蠻適合的，至于是否對比過Less,我的了解是沒有。你就當是湊巧選中了吧，恰好我們的北歐文化還是比較適合敏捷的，Spotify和Henrik就是北歐那邊的:)3、實施這個給您這個角色帶來的變化和益處？?我本人以前的角色是TL，就當是SM吧，以前我們是跑Scrum的，當然我的項目是有界面font-end 那種，跑起來很順暢，現在跑了一年的SAFe后，感覺SAFe是大型敏捷的救星，真的，為什么這么說呢？1) SAFe有詳細的落地細則。Scrum里面的東西太空泛了，基本上沒有教練教的話，可以說是五花八門，主要是它對3個角色是如何落地的沒有非常詳細的指引，而SAFe呢，它對每一個角色都有明確的定義，都有sample如何去落地，如果你能通過考試的話，可以說基本能掌握一個角色是如何執行的，但是scrum呢，那個考試被我喻為全世界最水的認證。2) SAFe適合大型的敏捷團隊。我們的產品線剛好是幾百人的團隊，這在IT企業里面，可以說是非常常見的，但是scrum卻不行，而且它的一個PI的定義也是很適合大型產品的開發，一個PI是10周的時間。沒有了解過Less,上過DAD的培訓，感覺DAD的方法論很吹水啊。3) SAFe并沒有拋棄scrum。SAFe里面的小迭代仍然是采取scrum的形式，為有敏捷基礎的企業的過渡提供了非常順滑的鋪墊。4) SAFe設立的RTE角色非常像傳統的項目經理（PM)的角色。這為PM是否在敏捷中存在開辟了一條新的道路。5) SAFe里面的CoP的概念。為敏捷的實施提供了落地的土壤和傳承。我們有SA的CoP，有PO的CoP,有前端團隊的CoP，都為產品的演進、技術的修煉、敏捷文化的落地提供了很好的流程支持。感謝Even的分享，非常非常棒！讓我們對SAFe的信心更近了一步！！其實，在SAFe 最新發布的4.6版本中，與時俱進，新增加了對企業DevOps能力的支持，因為對于多團隊協作而言，沒有持續交付DevOps的支撐，協作將會是非常痛苦的，發布速度也很難提升上去！所以，SAFe把“DevOps按需發布能力”作為精益企業的五大核心能力之一！

總結

以上是生活随笔為你收集整理的规模化敏捷必须SAFe的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。