敏捷擴展：Scrum Master 的 SAFe 最佳實踐

本文是 Toptal 的敏捷擴展系列的第二部分，旨在指導項目經理進行團隊擴展工作。 閱讀第一期，“5 個敏捷擴展框架比較：你應該使用哪個？” 深入了解最受歡迎的選項。

隨著產品的增長和變得越來越複雜，生產它們的團隊也在增長。 當需要擴展時，許多公司從 Scrum 過渡到擴展敏捷框架 (SAFe)，這是一個在企業級實施的系統，允許企業管理需要團隊開發的多個複雜產品。

進入 SAFe 框架的 Scrum master 將進入一個既熟悉又新的環境。 工件、角色和儀式基於 Scrum。 但是，在更高的規模上運營會帶來一些額外的責任，尤其是對於選擇擔任發布火車工程師 (RTE) 角色的 Scrum master，這是一個常見的軌跡。 RTE 充當整個發布系列的 Scrum 主管。 RTE 不再領導一個 9 到 11 人的 Scrum 團隊，而是成為跨多個部門的團隊的僕人式領導，他們組織更大規模和範圍的活動。

基礎知識：從 Scrum 到 SAFe

SAFe 允許公司在多個團隊中應用敏捷方法、價值觀和原則。 由此產生的“團隊團隊”被稱為敏捷發布列車 (ART)。 各個團隊繼續僱用 Scrum master 照常開展業務，而 ART 上類似 Scrum master 的角色由 RTE 完成。 RTE 應用 Scrum 的一般機制和治理，但在組織而不是團隊級別。 其他傳統的團隊級 Scrum 角色和工件也會相應地發生變化。 例如，ART“產品負責人”成為產品經理； “產品積壓”成為程序積壓； “衝刺積壓”是迭代積壓； “產品增量”現在是程序增量（PI）。

SAFe 有四種配置——基本、大型解決方案、組合和完整——您使用的一種取決於您的公司採用該框架的廣泛程度。 這些配置允許在多個級別實施，從多個團隊合作到完整的產品組合集成和企業範圍的業務敏捷性。 但在每個層面，目標仍然是擴展敏捷和 Scrum 實踐，而不是取代它們。

SAFe 中的 Scrum Master

在團隊級別的 SAFe 框架中工作的 Scrum master 會發現他們的工作沒有顯著不同。 他們將繼續作為敏捷團隊的僕人式領導者，負責指導和教育，消除障礙，並營造一個讓團隊成員感到安全的環境，讓他們能夠發揮自己的最佳水平並不斷改進。

但是，會有一些新的責任。 SAFe Scrum master 在 PI 計劃活動和程序執行中支持 RTE，並在 ART 同步會議中代表他們的團隊。 當存在超出團隊能力範圍的障礙時，Scrum master 會將其上報給 RTE。

決定成為 RTE 的 Scrum master 會發現他們的角色帶來了更多的考慮。 ART 可能包括您不熟悉或不熟悉敏捷的團隊，例如業務分析、硬件或合規性。 而且由於 SAFe 的更高配置包括項目或項目組合操作，管理層將直接並定期以他們不會參與 Scrum 的方式參與，確保一切都與企業和/或項目組合級別的目標保持一致。

RTE 負責消除超出單個團隊能力的障礙。 他們與利益相關者溝通並推動 ART 級別的持續改進。 RTE 不僅指導團隊，還指導這些團隊的領導者，幫助各個級別的 ART 朝著自我組織和自我管理的方向發展。

安全事件

正如 Scrum master 促進團隊級別的事件一樣，RTE 促進 ART 級別的事件——PI 計劃、ART 同步、系統演示以及檢查和調整。 作為一名 RTE，與作為 Scrum 主管相比，您將與更廣泛的利益相關者進行接觸，並處理具有相互競爭利益的多個團隊。 每場活動都有更多、更多樣化的參與者，您需要調整優先事項並提前獲得對計劃的支持。

PI 規劃

PI 計劃活動是 SAFe 的重要儀式，這是一個為期兩天的大型會議，通過創建 PI 計劃來調整 ART 內所有團隊在接下來的 8 到 12 週內的目標。 這就像一個衝刺計劃活動，但它跨越多個團隊的多個衝刺。

輸入

• 商業願景
• 要實現的前 10 到 15 個功能列表
• 每個團隊能力的詳細信息

輸出

• PI 計劃（接下來五到六個衝刺的交付計劃）
• 績效指標目標
• 潛在風險清單

PI 計劃活動的一般提示

• 獲得利益相關者的支持。 在會議之前，RTE 應確定關鍵利益相關者是誰，並與小組分享他們的意見。
• 調整優先級。 在會議開始之前，安排與產品管理團隊進行為期一天的會議，以就應交付哪些功能以及未來優先事項達成一致。 在活動中會有很多工作要做，比如風險和依賴關係，而且有基本的方向性協議是很好的。
• 排練！ PI 計劃是一件大事。 花兩天時間排練可能沒什麼用，但與 ART 的團隊領導進行 2 到 4 小時的會議，創造盡可能接近的體驗將大有幫助。 創建活動議程的簡化版本並在排練前分享，以便練習可以從消息靈通的地方開始。
• 為任務蠕變做好準備。 PI 計劃的目標是在相對較短的時間內交付長期計劃。 有時人們會想要詳細了解所有事情，這不是活動的目的。 在排練和會議中向團隊負責人解釋這一點； 提醒團隊，目標是提供高水平的計劃並建立一致性，而不是計劃未來三個月的每一分鐘。
• 準備團隊容量信息。 請您的 Scrum 主管提供接下來 8 到 12 週的容量計算。 期待一些阻力或問題； 例如，Scrum master 可能不知道他們的團隊在接下來的兩個月內將缺席多少次。 在這種情況下，要求進行估算，並在 PI 期間靈活應對容量限制。
• 分享 PI 計劃議程。 至少在活動開始前兩週分發時間表，並準備好回答很多問題。 將有很多與會者，如果 SAFe 對您和您的公司來說是新的，那麼它對許多其他團隊成員來說可能也是新的。 以我的經驗，到第二次或第三次 PI 計劃活動時，隨著團隊熟悉活動並知道會發生什麼，促進者的壓力會變得不那麼強烈。
• 安全管理考勤。 管理人員或高級管理人員通常很難參加為期兩天的活動，但管理人員出席是確保高層一致的必要條件。 至少在 PI 計劃前兩週確認他們的出勤率，並安排他們需要的任何支持。 這同樣適用於需要簽署 PI 目標的企業主。

ART 同步

ART 同步活動是每週一次的會議，RTE 可以在其中深入了解團隊的進度並確定項目風險和障礙。 儘管 RTE 絕不是評估障礙並確定是否需要升級的唯一場合，但這是一個重要的事件，它為提出這些問題提供了一個常規場所。

輸入

• 團隊的進步
• 障礙日誌
• PI 計劃（識別計劃與實際進度之間的任何重大偏差）

輸出

• 升級（如果需要）
• 關於 PI 計劃的任何更改的決定

ART Sync 活動的一般提示

• 鼓勵定期溝通。 因為 ART Sync 是每週一次，而不是像 Scrum 站立會議那樣每天一次，RTE 應該明確表示團隊可以立即提出緊急問題，而不應該等待下一次 ART 同步。
• 準備好數據。 要求 Scrum 主管和產品負責人提供可量化的進度指標，例如燃盡或累積流，以便就進度進行知情對話。
• 超越每週狀態審查。 ART 同步是一個優先級一致並解決問題的事件，而不是簡單的簽到。

系統演示

系統演示旨在展示之前迭代期間創建的全部工作範圍。 在這次活動中，產品經理和他們的團隊向企業主和其他利益相關者展示了 ART 當前形式的綜合進展。

輸入

• 基於所有敏捷團隊成員在上一次迭代過程中的輸出的當前工作狀態

輸出

• 對系統是否適合目的的反饋
• 對積壓的更改（如果需要）

系統演示活動的一般提示

• 排練！ 每隔一周花 30 到 45 分鐘與演示者一起確定他們的細分。
• 扔掉幻燈片。 呈現實際的集成工作。 如果您正在開發軟件產品，請讓演示者向利益相關者展示工作產品增量，而不是幻燈片。 如果可能，請在暫存環境中展示您的產品。 您希望演示準確地模擬最終用戶體驗。 如果您無法每兩週展示一次集成系統，請查看您的交付管道並與團隊討論如何採用 CI/CD 和 DevOps 文化。
• 專注於商業價值。 您的演示文稿面向企業主和利益相關者； 分享對他們來說最重要的東西。
• 保持反饋的重點。 您收到的利益相關者反饋很重要，但這次活動不是對產品願景或路線圖進行重大更改的時候。 準備好將對話引導回高層反饋，團隊可以在以後將其轉化為行動項目。
• 保持簡短。 利益相關者是忙碌的人； 45 到 60 分鐘的會議將導致更頻繁和更積極的出席。
• 留出時間進行問答。 在你的答案中保持透明。 請記住，有時“我不知道，但我們可以找到”是最好的答案。

檢查和調整

檢查和調整是在 PI 結束時舉行的大型回顧會議。 會議分為三個部分，

• PI 系統演示：展示整個 PI 的集成輸出。 它與主系統演示類似，但不是一次迭代，而是展示了整個 PI 的集成工作。
• 定量和定性測量： RTE 有機會展示在 PI 過程中收集的指標。 這些指標包括（但不限於）團隊速度、接受的用戶故事、單元測試覆蓋率或開放缺陷。
• 回顧和解決問題研討會：參與者有機會回顧 PI，反思哪些工作有效，哪些無效，識別系統性問題，並提出解決方法。

輸入

• 團隊的進步
• ART 集成工作的當前狀態，包括所有程序增量的輸出

輸出

• 潛在改進列表

檢查和調整事件的一般提示

• 提前通知企業主。 在活動開始前至少提前兩週通知。 在會議之前與任何與會的產品經理和企業主會面，以就定性結果演示保持一致。
• 確保高級利益相關者的出席。 當您展示團隊的工作和不斷發展的產品時，他們的存在在 PI System 演示中最為重要。 常規系統演示的許多要點在這裡適用：事先排練，避免演示幻燈片，並展示實際可交付成果。
• 避免責備。 在整個會議期間，確保沒有人會受到所提供的數據或回顧中發現的問題的威脅。 如果另一支球隊的人數更高，一些球隊可能會感到嫉妒或防禦，或者如果問題源於他們的球隊，他們會感到被孤立。 擁抱整個團隊的文化，以搶占此類問題。
• 關注系統性問題。 盡量不要過多關注零星的問題，為您的團隊提供他們需要頭腦風暴的空間，並為提出的解決方案自由發揮想像力。
• 創建可操作的提案。 在活動結束時，您應該有待辦事項供團隊實施。 如果您不採取措施解決問題，那麼識別問題將無濟於事。

下表將 SAFe 事件與其 Scrum 等效事件進行了比較，並描述了企業級儀式的頻率和執行情況：

加強和擴大規模

從 Scrum 到 SAFe 的過渡可能會令人生畏。 即使是最熟悉的實踐，以更高的規模運營也總是會帶來新的挑戰和新的思考方式。 如果你選擇成為一名 RTE，你會發現這份工作很大程度上取決於你已經擁有的技能。 RTE 是變革推動者和僕人式領導者，就像 Scrum 大師一樣，這份工作讓你有機會在企業層面上扮演這個角色，提升你的技能以及你的產品。