SAFe 中 Agile 團隊相對 Scrum 的實務運作特性

在朋友之間發表 第一篇關於 Burn Down Chart 的文章, 之後，留言中第一個被問到的問題是：「會很想更深入了解你們 在 SAFe 的經驗」。因此，在本文中我將盡力闡述我們實務上在 SAFe 中運作相對於 Scrum 的特性。我絕不主張這是第一手的真理，也樂於接受 同事們的任何修正與補充。

首先，我以條列方式列出我認為 SAFe 與 SCRUM 運作上最主要的差異。

• Scrum 中的 Increment 與 SAFe 中的 Program Increment
• ART - Agile Release Train
• 互動團隊的數量
• PIPE
• SOS
• PO - 不是業務所有者
• RTE
• 用於學習的第五個衝刺
• System Demo

Scrum 中的 Increment 與 SAFe 中的 Program Increment。 其實是不同的術語，但很容易混淆，因為 我們這裡沒有人使用 Program Increment 這個術語，大家都只說 Increment——而那是另一個 在 SCRUM 中使用的術語。但整體而言，我認為從意義上來說它們相當相似。SCRUM 中的 Increment 本質上是當前產品加上已完成狀態（通過團隊 DOD）的衝刺計畫故事。Program Increment 則是列車（Agile Release Train）向生產環境交付 增量價值的時間區間。在持續時間上，我們是 4 個為期兩週的開發衝刺加上一個 用於學習的衝刺。

Agile Release Train - 是一組共同致力於同一價值流動的團隊所組成的團隊。我們直接 稱之為列車，但依框架正確來說應稱為「Solution」。在我們的情況下，這項規則並未完全 遵守，從技術角度來看團隊經常致力於不同的產品，因為大多數 業務功能都是綜合實現並涉及多個產品。這是從技術面來說。但我確信， 有人會把所有 IT 系統視為公司的一個產品，或許這樣甚至更正確。

互動團隊的數量 在我們的 SAFe 中顯著更多，合計建議一個列車最多 125 人 。我們有 3 個列車，並非每個都遵守這項規則，有些列車人數超過 125 人。據我所知，SCRUM 並未描述如何與其他團隊互動，這與 SAFe 不同，SAFe 對此有非常明確的建議。我認為最鮮明的相關 產出物是 Program Board。

它顯示列車各團隊之間的相互關係，我們每週的 Scrum Of Scrums (SOS) 活動就是透過討論它來進行。

大約每 2.5 個月（每 5 個衝刺）會發生一次 PIPE - Programm Increment Planning Event。 這是所有分散的團隊聚集在同一大廳為期 2 天，規劃接下來 2.5 個月工作的活動。在此活動過程中會產生 Program board 等產出物，例如 它顯示每個列車各團隊之間的所有依賴關係，我在上面已經展示了它的樣子。 每個團隊的 Scrum Master 在此活動中的任務是促進發掘最大數量的 依賴關係，然後盡可能移除它們（例如透過口頭傳授能力從一個團隊 傳給另一個團隊，或將依賴從一個團隊轉移到另一個團隊，使團隊能夠自主實現 其功能而不依賴任何人）。實務上我們就是這樣進行的。首先將功能分解為 User Story，User Story 分配到 4 個衝刺中。功能放置於 Program Board 上並標示出與 其他團隊的依賴關係。在活動期間會對此進行討論與調整。

SOS - Scrum Of Scrum。 此活動每週為每個列車分別舉行。列車所有團隊的 Scrum Master 在線上聚集，播放列車的 Program Board 並討論特定列車各團隊的所有 依賴關係與功能狀態。本質上此活動是為了集中同步列車內各團隊。 有點像站立會議，但每週一次，且不是為團隊，而是為 Scrum Master。

PO（產品負責人） - 不是業務所有者。有 Product Manager——他與相應業務方向的 Bussiness Owner 合作，本質上將功能分配給產品負責人。產品負責人則直接在 團隊中工作——將功能拆分為 User Stories（在我們的情況下是與團隊共同進行），並非總是拆分，但 我們在此方向上持續進步。

RTE (Release Train Engineer - 列車司機。Scrum Master of Scrum Masters。主持其列車的 SOS 活動。在功能層級與 Product Manager 互動。主持 PIPE。

第五個衝刺用於學習 - 是的，與 Scrum 不同，這裡在增量結束時為團隊分配了整整一個衝刺用於學習。我們在實踐中通常首先用它來參加內部培訓，包括 SAFe 相關的培訓，但不僅限於此。我們盡量盡可能將私人課程和聚會安排在這段時間。此外，我們有些開發人員會在第五個衝刺期間擴展自己的技術棧，以便能夠在團隊中填補某人的能力（必要時提供支援）。

System Demo。 在 PIPE 的結果中，每個團隊都有一份增量目標清單，且每個目標都由列車的 Business Owner 按 10 分制評估。這稱為 Business Value。這些目標分為主要目標和擴展目標。主要目標是團隊認為在達成上沒有任何風險的目標。擴展目標是存在達成風險的目標。所有目標都是必須的，工作量規劃涵蓋所有目標。在 System Demo 上，Business Owner 驗收增量的工作成果。假設某團隊有 3 個主要目標，評分分別為 10、6、8，以及 2 個擴展目標，評分為 10、3。假設 Business Owner 分別給出了以下評分：8、6、4、2、0。現在可以計算目標達成百分比：以主要目標的初始分數總和作為 100%，在我們的例子中是 10+6+8=24。達成分數的計算會考慮擴展目標（即團隊在 24 分中達成了 20 分），因此團隊的目標達成百分比為 (20*100)/24 = 83.3%。正常結果被認為是達成 80% 到 100%。

在其他所有方面我們都按 SCRUM 運作。嗯，或者幾乎所有方面 :) 至於我們的經驗：我可以說，從我的角度來看，演進是顯而易見的。經過一年的運作，團隊大幅成長，變得自組織，有些團隊確實解體了，但即使在這其中也能看到某種演進。成長也還有空間。

來自 facebook 同事的評論

«Zhenya，你好！很高興你在寫，做得好！稍微糾正一下關於列車的說法——它們不是圍繞產品組建的，而是圍繞價值流組建的。而在零售業，從 SAFe 的角度來看，我們不是列車，而是 Solution。只是為了溝通方便和簡化理解，我們繼續稱之為列車)»

– Konstantin Voronin （Ingosstrakh 專案辦公室代表）

«嗯，也許有人會注意到，從 SAFe 的角度來看，目標評估是在 I&A 上進行的（SD 作為其中一部分納入，但與評估沒有直接關聯），而 SD 本身應該每個衝刺都進行（在團隊演示之後）。但我們目前還遠未達到這一點，所以我們有意識地按照你文章中寫的那樣來稱呼一切)»

– Konstantin Voronin （Ingosstrakh 專案辦公室代表）

«Zhenya，請繼續，非常有用！»

– Alexey Ionov （SAFe 認證培訓師）