2. 程式人生 > >Scrum At Scale® 指南-切實可行的規模化擴充套件敏捷

Scrum At Scale® 指南-切實可行的規模化擴充套件敏捷

阿新 • • 發佈：2019-02-02


Scrum At Scale® 指南

版權所有© 2006-2018 Jeff Sutherland 及 Scrum Inc.

[email protected]是Scrum Inc.的註冊商標。本指南基於署名-相同方式共享許可協議4.0釋出。(CC BY-SA 4.0)

簡體中文版原創翻譯團隊：申健 Jacky Shen (CST, CTC, Agile Coach); 王洪亮 Stephen Wang (CSP, Agile Coach); 李國彪 Bill Li (CST, Agile Coach);

[email protected]指南之目的

最初在Scrum指南中描述的Scrum，是單個團隊進行開發、交付和持續發展複雜產品的框架。自誕生以來，它已經擴充套件到需要多個團隊合作來建立產品、處理過程、服務和系統。建立

[email protected]是為了有效地整合這種新型的團隊生態系統，從而優化組織的整體策略。為了實現這個目標，它利用一個自由擴充套件的架構建立起一個“最小可行的官僚機構”，自然地將單個Scrum團隊的功能擴充套件到整個組織中。

本指南包括構成[email protected]框架的元件定義，包括擴充套件的角色、擴充套件的事件、企業級工件，以及將它們組織在一起的各種規則。

Jeff Sutherland博士基於Scrum、複雜自適應系統理論、博弈論、面向物件技術等背後的基礎原則開發了[email protected]。本指南採納了許多有經驗的Scrum實踐者的輸入，基於他們的現場工作成果。本指南之目標是讀者能夠自行實施

[email protected]。

為什麼要[email protected]?

Scrum是為單個團隊而設計，使其能夠在可持續的速率下發揮最佳生產力。在該領域中，人們發現隨著組織內的Scrum團隊數量增長，最佳輸出（可工作的產品）及那些團隊的速率會開始下降（比如由於跨團隊依賴和重複勞動等問題）。很明顯，為了獲得線性的可擴充套件性，人們需要一個有效整合那些團隊的框架。設計[email protected]是為了利用自由擴充套件的架構達成這個目標。

通過使用無標度架構，組織的增長並不受限於以一組武斷規則所決定的特定方式；相反，它可以有機地基於自己的獨特需求而增長，並維持可持續的變革速度，從而可以被組織的成員們接受。

[email protected]是為組織的整體擴充套件而設計：所有部門、產品和服務。它可以被運用到不同領域，包括工商業、政府或學術界中的各類組織。

[email protected]的定義

Scrum（名詞）：Scrum是一個框架，在此框架中，人們可以解決複雜自適應問題，同時高效並創造性地交付最大價值的產品。

Scrum指南是最小功能的集合，它通過徹底的透明性促進檢視和適應性，從而驅動創新、績效和團隊幸福感。

[email protected]（名詞）：[email protected]是一個框架，在此框架中，一致採用Scrum指南進行運作的Scrum團隊網路可以解決複雜自適應問題，同時高效並創造性地交付最大價值的產品。

注意： 這些“產品”可以是硬體、軟體、複雜的整合系統、處理過程、服務等，取決於Scrum團隊所處的領域。

[email protected]是: * 輕量的 – 最小可行的官僚機構 * 易於理解的 – 僅僅包含Scrum團隊們 * 難以精通的 – 需要實施一個全新的運作模型

[email protected]是一個對Scrum進行擴充套件的框架。通過使用Scrum來擴充套件Scrum，它徹底簡化了規模擴充套件。它僅僅包含一些Scrum團隊，這些團隊通過Scrum of Scrums和MetaScrums進行整合。

[email protected]本身基於元件的性質允許組織定製他們的轉型策略和實現方式。它使得他們獲得一種能力，可以將轉型的努力聚焦在他們認為最有價值或最需要改變的領域內，然後再向其他方面取得進展。

在Scrum中，要注意區分對“What”與“How”的問責。在[email protected]中也是一樣，那麼就要明確地理解許可權和職責，從而消除浪費性的組織衝突，令團隊更容易達致最佳生產力。

為了區分這兩個許可權，[email protected]包含兩個迴路：Scrum Master迴路（“How”）和產品負責人迴路（“What”），彼此具有兩個相互接觸點。總之，這些迴路造就了一個強大的框架，整合多個團隊朝著同一個方向而努力。

[email protected]框架的元件

價值觀驅動的文化

除了區分對“What”與“How”的問責，[email protected]還進一步在實證背景下創造價值驅動的文化，旨在建立健康的組織。Scrum的價值觀包括：開放、勇氣、專注、尊重和承諾。這些價值觀驅動著實驗性決策，而其取決於透明、檢視和調整這三大支柱。

開放支援著所有工作和過程的透明性，沒有這種透明度，就無法誠實地檢視並試圖更好地調整它們。勇氣指的是大膽跳躍，這是以創新方式更快地交付價值所需要的。

專注和承諾是我們處理工作職責的方式，把交付客戶價值作為最高優先順序。最後，所有這一切都必須發生在一個尊重每個人的工作環境中，否則不可能創造任何東西。

[email protected]支援僕人式領導風格和基於意圖的領導力模型，以幫助組織蓬勃發展，1培養一個以可持續速率進行工作的積極環境，致力於將面向客戶價值放在努力的第一位。

開始使用[email protected]

在實施大型團隊網路時，針對少量團隊開發出一個可擴充套件的參考模型是至關重要的。當部署多個團隊時，Scrum實施中的任何缺陷都會被放大。

因此，第一個挑戰就是建立少量良好實施Scrum的團隊。這組團隊克服了那些阻礙敏捷性的組織問題，併為Scrum建立一個在組織中眾所周知可執行的參考模型，將其用作整個組織範圍內擴充套件Scrum的模式。

隨著團隊參考模型的加速，延遲交付、產生浪費或妨礙業務敏捷性的障礙及瓶頸會變得明顯。消除這些問題的最有效方法是在整個組織中傳播Scrum，以便優化整個價值流。

[email protected]通過使組織浸泡在Scrum中，並有機地分配速度和質量，從而實現了生產力的線性擴充套件，與組織的特定策略、產品和服務保持一致。

Scrum Master迴路

團隊級過程

在Scrum指南中明確闡述了團隊級過程。它由三個工件、五個事件和三個角色組成。團隊級過程旨在：

  • 最大限度地使完成和通過質量驗證的工作流動起來。
  • 每個Sprint都提高一點點速率。
  • 以一種可持續和豐富的方式運作。

整合如何做事(“How”) – Scrum of Scrums

需要協作的多個團隊組成一個“Scrum of Scrums”（SoS） 。SoS是“團隊之團隊”2，每天舉行一個規模化每日例會（SDS）事件，每個團隊派代表參加（通常是團隊的Scrum Master，儘管任何人都可以參加，也可以派多個人參加）。SDS的存在是為了協調團隊並移除障礙以交付價值。

SDS事件反映了每日Scrum例會，優化了團隊網路的協作和績效。另外，SDS：

  • 少於15分鐘的時間盒。
  • 每個團隊必須派代表參加。
  • 是一個團隊代表們解決3個簡單問題的論壇：
    • 我的團隊有什麼障礙阻止了他們完成他們的Sprint目標（或影響即將釋出的版本）？
    • 我的團隊是否在做任何事情阻止了其他團隊完成他們的Sprint目標（或影響他們即將釋出的版本）？
    • 我們發現了團隊之間的任何新的依賴關係嗎，或者找到了解決現有依賴關係的方法嗎？

這一組Scrum Master們本身就是一個Scrum團隊，負責在每個Sprint末尾從所有參與團隊那裡完全地整合出一個潛在可交付的產品增量。SoS團隊需要實時地應對所有參與團隊所提出的障礙。

SoS充當一個釋出團隊，必須能夠直接地向客戶交付價值。為了能有效地做到這一點，它需要與Scrum指南保持一致；也就是說，要有自己的角色，工件和事件。這包括一個待辦清單梳理事件，他們在其中決定哪些障礙已經“準備好”被移除，最佳移除障礙的方式是怎樣的，團隊如何才能知道它是“完成”的。要特別關注SoS回顧事件，團隊代表們在其中分享各自團隊中的任何成功的學習收穫或流程改進，以便在SoS中的各個團隊能夠將這些實踐標準化下來。

為了在每個Sprint結束時交付一個完全整合的潛在可交付產品，它需要具備所需的所有技能。它具有產品負責人代表來解決優先順序問題。它可能需要經驗豐富的架構師，QA負責人和其他操作技能組。當啟動[email protected]時，團隊們可能還不具備能夠支援持續部署的基礎架構。這會迫使SoS建立一個“整合團隊”或“釋出團隊”，以完成克服工程缺陷所需的額外工作。SoS被鼓勵去激進地解決整合和部署的障礙，因為它創造了一個超高生產力的環境，例如，亞馬遜有3300個Scrum團隊，平均每秒部署超過一次3。

Scrum of Scrums Master (SoSM)

SoSM負責聯合團隊的釋出，並且必須：

  • 使組織可以看到障礙待辦清單。
  • 移除團隊自己無法解決的障礙。
  • 對障礙進行排序，特別要關注跨團隊依賴和產品待辦清單的分配。
  • 提升Scrum of Scrums的效果。
  • 與產品負責人們密切合作，每個Sprint部署至少一個潛在可交付的產品增量。
  • 利用產品負責人的釋出計劃來整合多團隊的部署工作。

擴充套件SoS

根據組織或實施的規模，可能需要多個SoS來交付非常複雜的產品。在那些情況下，可以從多個Scrum的Scrum中建立一個Scrum of Scrum of Scrums（SoSoS)。 SoSoS是Scrum團隊的一個有機模式，可以無限擴充套件。每個SoSoS都應該有SoSoSM角色們，以及每個工件和事件的擴充套件版本。

擴充套件SoS減少了組織內部的溝通路徑數量，因此複雜性被封裝了起來。SoSoS與SoS的介面、SoS與單個Scrum團隊的介面，兩者都採用了相同的方式，從而實現線性可擴充套件性。

示例圖：

注意： 儘管Scrum指南將最優團隊規模定義為3到9人，但哈佛大學的研究認為最優團隊規模為4.6人。4 針對高績效Scrum團隊的研究一再表明4或5人在一起工作是最優人數。對於SoS中的團隊數量，這種模式帶來的線性可擴充套件性是至關重要的。因此，在上圖和下圖中，選擇了五邊形來表示一個5人團隊。這些圖僅僅是示例，您的組織圖表可能會有很大差異。

高管行動小組

針對整個敏捷組織的Scrum of Scrums被稱為高管行動小組（EAT）。EAT是SoS不能移除的那些障礙的終點站。所以，它必須由在政治和財務上得到充分授權的人們組成，去移除那些障礙。EAT的職能是協調多個SoS（或者SoSoS）。和任何Scrum團隊一樣，它也需要具備一個PO和SM。EAT最好也像Scrum團隊一樣可以每天見面。每個Sprint他們必須至少見一次面，並且具備一個透明的待辦清單。

例圖展示了1個EAT，正在協調分佈在5個群組中的25個團隊

EAT的待辦清單及責任

Scrum是一個區別於傳統專案管理的敏捷作業系統。整個SM組織彙報給EAT，後者負責在組織內建立、維護和提升其打造的敏捷作業系統。EAT的角色是建立組織轉型待辦清單（一份經過排序的列表，包含待完成的敏捷舉措）並確保落地執行。例如，如果在一箇舊組織中存在一個傳統的產品開發生命週期，那麼一個新的敏捷產品開發生命週期需要被建立、實現和支援。通常它會比舊方法的更好地支援質量和合規事項，但是需要採納一套不同的規則和指南來實施。另外，組織發展和治理的很多方面也需要調優。

EAT對於整個組織的Scrum質量負責。它的職責包括但不僅於：

  • 為參考模型建立敏捷作業系統，以擴充套件到整個組織，包括提升敏捷性的企業運營規則，過程和指南。
  • 度量和改進組織內的Scrum質量
  • 構建組織內業務敏捷的能力
  • 建立一個針對Scrum專業人士的持續學習中心
  • 支援去探索新型工作方法

最後，EAT必須比照SoS，聚集PO群體來建立和支援相應的的產品負責人組織，從而擴充套件PO職能。這些PO和關鍵干係人的團隊被稱為MetaScrum。

Scrum Master組織的輸出/效果

SM組織（SoS、SoSoS和EAT）作為一個整體來完成Scrum Master迴路的元件：持續改進和移除障礙，跨團隊協調，和部署

持續改進和移除障礙的目標是：

  • 識別障礙並轉化為機遇。
  • 維護一個安全的和結構化的環境以排序和移除障礙，並驗證和落實改進。
  • 確保組織內的可見性以促成變革。

跨團隊協調的目標是：

  • 協調多個關聯團隊間的相似流程。
  • 管理跨團隊依賴以確保它們不會變成障礙。
  • 使團隊規範和指南的保持對齊，以確保持續的輸出。

SoS的目標是像個釋出團隊一樣工作，因此產品部署也是其分內事，而決定釋出內容則是PO的分內事。因此，部署的目標是：

  • 持續流動式地向客戶交付有價值的完成產品。
  • 將不同團隊的工作整合到一個無縫的產品。
  • 確保使用者體驗的高質量。

產品負責人迴路

整合做什麼事(“What”) – MetaScrum

如果一組產品負責人有必要整合一個唯一的待辦清單，以供Scrum of Scrums來工作，那麼他們自己就形成一個團隊稱為MetaScrum。每個SoS都有一個對應的MetaScrum。MetaScrum沿著同一路徑來對齊多個團隊的優先順序，這樣他們就可以整合多個待辦清單，並和干係人保持一致以得到他們對待辦清單的支援。MetaScrum舉行一種規模化的待辦清單梳理活動。

  • 每個產品負責人（或其代理）都必須參加
  • 這個事件是領導者、干係人或其他客戶表達各自傾向的論壇

這個事件按需發生，每個Sprint至少發生一次，以確保一個“就緒”的待辦清單。MetaScrum的主要職能是：

  • 建立產品的主要願景並且使之對整個組織可見。
  • 和干係人保持一致以確保他們支援產品待辦清單的實現。
  • 建立唯一的排序的待辦清單；確保規避了重複工作。
  • 針對SoS內所有團隊建立統一的“完成的定義”。
  • 消除由SoS提出的依賴。
  • 生成一份整合的釋出計劃。
  • 監控能夠洞察產品的度量，並基於其進行決策。

類似於SoS，多個MetaScrum本身也作為Scrum團隊來運作。所以，需要某人來扮演SM來保持團隊的正常溝通。他們還需要唯一的人來負責協調，使得MetaScrum覆蓋的所有團隊創建出唯一的產品待辦清單。這個人被指定為產品總負責人。

產品總負責人(CPO)

通過MetaScrum，產品總負責人與各個團隊的產品負責人來協調優先順序。他們以干係人以及顧客需求來對齊待辦事項的優先順序。類似於SoSM，可以是某個團隊的PO來扮演這個角色，或者是某個人全職擔任這個角色。他們的主要職責和普通PO是一樣的，但是在擴充套件的時候：

  • 建立整個產品的戰略願景
  • 建立唯一的、排序的待辦清單，包含將要被所有團隊交付的價值。
  • 這些事項對於一個團隊的PO來說可以是更大規模的故事。
  • 與相應的SoSM緊密工作在一起，以便有效地部署MetaScrum團隊建立的釋出計劃。
  • 監控客戶對產品的反饋並相應地調整待辦清單。

擴充套件MetaScrum

如同SoS可以增長到SoSoS，MetaScrum也可以用同樣的機制進行擴充套件。沒有專門的術語對應這些擴充套件單元，他們的CPO們也沒有專門的擴充套件頭銜。我們鼓勵每個組織發展自己的方式。下圖中，我們選擇了再增加一個“總”以突出那些PO。

一些例圖：

注意： 如上所述，這些多邊形代表著理想規模的Scrum團隊和MetaScrum。這些圖僅僅作為例子，你的組織圖可能會顯著不同。

高管MetaScrum（EMS）

MetaScrum使得PO及其對應的SoS能夠以一種網狀設計進行無限地擴充套件。整個敏捷組織的MetaScrum是高管MetaScrum。EMS擁有組織的願景並設立整個公司的戰略優先順序，使各個團隊圍繞共同目標來對齊。

例圖展示了1個EMS，正在協調分為5個組的25個團隊：

產品負責人組織的輸出/效果

PO組織(各種MetaScrum，CPO和高管MetaScrum)作為整體來工作以滿足產品負責人迴路的元件：戰略願景、待辦清單優先順序排序、待辦清單分解和梳理，以及釋出計劃

設定戰略願景的目標是：

  • 透過一個共享的路徑清晰地對齊整個組織。
  • 清晰而有力地表述組織為什麼存在。
  • 描述組織會做什麼從而排程其關鍵資產以支援其使命。
  • 持續更新以響應快速變化的市場情況。

待辦清單優先順序排序的目標是：

  • 針對待交付的產品、功能和服務，識別出一個清晰的排序。
  • 待辦清單的排序反映了價值創造、風險緩解和內部依賴。
  • 在分解和梳理待辦清單之前，先在整個敏捷組織內對高層舉措進行排序。

待辦清單分解和梳理的目標是：

  • 把複雜專案和產品分解為獨立的可工作元素，每個元素都可以被一個團隊在一個Sprint中完成。
  • 捕獲和提煉湧現的需求和客戶反饋。
  • 確保所有的待辦事項條目是真的“準備就緒”以便被各個團隊拉取。

釋出計劃的目標是：

  • 預報關鍵特性和能力的交付
  • 向干係人溝通交付預期
  • 按需更新優先順序排序

理解反饋

反饋元件是PO和SM迴路交叉的第二個點。產品反饋通過調整產品待辦清單來驅動持續改進，釋出反饋通過調整部署機制來驅動持續改進。獲取和分析反饋的目標是：