https://blog.csdn.net/chktsang/article/details/85120261## SCRUM@SCA
Scrum，最初概述於《Scrum指南》，是一個單團隊開發、交付和維護複雜產品的框架。自從問世以來，其應用已經拓展到需要多個團隊協作才能完成的產品、事務過程、服務和系統。Scrum@Scale的創建，是為了通過優化組織整體戰略，以高效協調多團隊的新生態系統。它通過採用一個“可自由擴展的架構（Scale-Free）”，建立起一個“最小可行的管理機構”，將單個Scrum團隊的功能自然地擴展到整個組織，以達成此目標。
本指南包含構成Scrum @ Scale框架的組件定義，包括擴展角色、擴展事件和組織工件，以及把它們組織在一起的規則。
Jeff Sutherland博士基於Scrum背後的基本原則、複雜適應系統理論、博弈論和麵向對象技術開發了Scrum@Scale。許多富有經驗的Scrum從業者基於他們的實戰成果為本指南提供了素材。本指南的目標是使讀者能夠獨立實施Scrum@Scale。
Scrum是為使單個團隊而設計，使其能以維持可持續節奏工作於最佳產能。在實戰中，人們發現，隨著組織的擴張以及Scrum團隊數量的增長，團隊們的最佳產出（可工作的產品）以及團隊速率在開始下降（由於諸如跨團隊依賴和重複勞動之類的問題）。顯然，為了實現組織的線性可擴展性，需要一個能有效協調多團隊的框架。Scrum@Scale通過它的“可自由擴展的架構（Scale-Free）”的設計方式，來達成這個目標。
通過採用可自由擴展的架構，組織的擴張不再局限於特定規則下的特定方式；取而代之的是，它可以基於其獨特的需求，以及被組織成員群體接受的可持續變化節奏，有機地擴展。
Scrum@Scale被設計為在組織整體層面進行擴展，覆蓋了所有的部門、產品和服務。它可以應用於行業、政府或學術的各類組織機構的多個領域。
Scrum(名詞)： 是一個框架，在此框架中人們可以解決複雜的自適應難題，同時也能高效並創造性地交付最高可能價值的產品。
《Scrum指南》是一套最小特徵集，通過徹底的透明來促使檢視和適應，以促進創新，提升績效和團隊的幸福感。
Scrum@Scale(名詞)：是一個框架，遵從《Scrum指南》運作的多個Scrum團隊組成的網絡組織能夠使用此框架來解決複雜的自適應難題，同時也能創造性地交付最高可能價值的產品。
說明：這裡的“產品”，可以是硬件、軟件、複雜集成系統、事務過程、服務等等，這取決於Scrum團隊們所處的領域。
Scrum@Scale 是:
Scrum@Scale是一個用於擴展Scrum的框架。它通過使用Scrum來擴展Scrum，徹底簡化了擴展方式。它由且僅有通過SoS（Scrum of Scrums）及MetaScrum來協調的Scrum團隊們組成。
Scrum@Scale具有基於組件的天性，這就允許組織自行定制其轉型策略和實施方式。它賦予轉型組織能力，使他們能先把轉型工作聚焦於其認為最有價值或者最需要變革的區域，然後再向其他區域推進。
在Scrum中，關注從職責上分離“做什麼”和“怎麼做”。在Scrum@Scale中，也同樣關注這一點，以期明確權力和責任，消除會妨礙團隊們實現最佳生產率的浪費性組織衝突。
在分離這兩種權力時，Scrum@Scale包含了兩個循環：Scrum Master循環（負責“怎麼多”）和產品負責人循環（負責“做什麼”），彼此相交於兩個點。總體來說，這兩個循環產生了一個能協調多個團隊往一處使勁的強有力框架。
除了分離“做什麼”和“怎麼做”的職責外，Scrum@Scale進一步旨在建立健康的組織，這是通過在經驗主義環境中打造價值觀驅動的文化來實現的。Scrum的價值觀為：開放、勇氣、專注、尊重和承諾。這些價值觀驅動著經驗決策，後者依賴於透明、檢視和適應這三大支柱。
開放，才能保證透明深入到所有的工作和過程；缺乏這種價值觀，就無法做到對工作和過程進行真誠地檢視和改進。勇氣，指的是採取必要而大膽的變革，以創新的方式更快地交付價值。
專注和承諾，指的是我們對待自己工作義務的方式，要把客戶價值交付置於最高優先級。最後，所有這些都只會發生於以尊重工作人員為本的環境中，失去了人也就無法產出物。
Scrum@Scale通過支持服務型領導風格和基於意圖的領導模式【1】，來幫助組織茁壯成長；這就營造了一個積極的環境，以期用可持續的節奏工作，承諾把客戶價值交付作為首要事務。
在實現大型Scrum團隊網絡時，關鍵是要先針對一個小規模團隊集開發出一個可擴展的參考模型。任何Scrum實施上的短板在部署到多個團隊時都將被放大。
因此，面臨的第一個挑戰是，要先建立起一個能夠良好實施Scrum的小規模團隊集。這個團隊集要解決那些阻礙敏捷的組織問題，並為實施Scrum建立一個參考模型；這個參考模型將會被引入到組織中，作為在整個組織範圍內擴展Scrum的模式。
隨著這個參考模型的加速，延遲交付、製造浪費或妨礙業務敏捷性的障礙及瓶頸將會一一顯現出來。而最有效的問題解決手段就是將Scrum擴展到整個組織，在整個價值鏈條上做優化。
Scrum@Scale通過在組織中貫徹落實Scrum，以及有機地分配速度和質量，來實現生產率與組織具體戰略、產品和服務的同步線性增長。
在《Scrum指南》中明確闡述了團隊級過程。它由三個工件、五個事件和三個角色組成。團隊級過程的目標是：
需要彼此協作的團隊可以組建一個“Scrum of Scrums（SoS）”。SoS是一個跨團隊協作的Scrum團隊，它有一個跨團隊的Scrum每日例會（Sacled Daily Scrum），簡稱：SDS。每個團隊都會派代表參加SDS,儘管團隊中的任何人或者任意數量的人都有可能參加SDS，但通常是Scrum Master參加。SDS的存在是為了協調團隊，以及消除團隊交付價值的障礙。
SDS事件類似於每日Scrum站會，在會上優化團隊網絡的協作和效能。此外，SDS：
這個由Scrum Master們組成的團隊本身就是一個Scrum團隊，負責在每個衝刺結束時從所有參與的Scrum團隊中集成得到完整的潛在可交付產品增量。這個SoS需實時響應各參與團隊提出的障礙。
SOS作為一個發布團隊來運作，必須能夠直接向客戶交付價值。要做到這一點，它需要遵循《Scrum指南》，也就是說，要有自己的角色、工件和事件。這包括待辦列表精化事件，在其中他們決定哪些障礙已經“準備好”被消除、最好該如何消除，以及團隊如何知曉事情已經“完成”。還應該特別關注SoS回顧會議，團隊代表們在會上分享各個團隊學到的經驗和成功實施的過程改進，以便在SoS內部標準化那些跨團隊實踐。
為了在衝刺結束時能交付一個完整集成的潛在可交付產品，SoS必須具備所有必需的技能。它包括產品負責人的代理人，負責解決優先級問題。它可能需要經驗豐富的架構師、QA負責人，以及其他具有操作技能的人們。在剛開始啟動Scrum@Scale時，團隊可能還不具備支撐持續部署的基礎設施。這會迫使SoS不得不建立一個“集成團隊”或“發布團隊”，這是為了克服工程技術缺陷而產生的額外工作。鼓勵SoS去積極地解決集成和部署障礙，以打造實現超高生產率所需的環境，例如亞馬遜有3300個Scrum團隊，平均每秒部署一次以上【3】。
SoS Master（the Scrum of Scrums Master，縮寫為SoSM）對團隊們聯合產出的發布版本負責，必須做到：
基於組織和實施團隊的規模，交付非常複雜的產品可能需要多個SoS協作。在這種情況下，在多個Scrum of Scrum之上，可以建立一個Scrum of Scrum of Scrums（SoSoS）。SoSoS是Scrum團隊群的一個有機模式，可以無限擴展。每個SoSoS應該有自己的SoSoS Master（縮寫：SoSoM），以及每個工件和事件的擴展版本。
通過擴展SoS，可以減少了組織內的溝通路徑數，使復雜度得到封裝。SoSoS與SoS的協作方式，同SoS與單個Scrum團隊的協作方式完全相同，這就為組織提供了線性可擴展性。
示例圖：
說明：儘管《Scrum指南》定義團隊的最佳規模是3到9人，但哈佛大學研究確定的團隊最佳規模是4.6人【4】。針對高效Scrum團隊的實驗也一再表明，4或5人是最佳的協作規模。在本模式中一個SoS包含的團隊數量也採用了這個數值，這是線性可擴展性的關鍵之處。因此，在上面和接下來的圖中，選擇使用五邊形來代表一個5人的團隊。這些圖僅僅是示例而已，您的組織圖可能會有很大的差別。
針對整個敏捷組織的SoS，稱為決策層行動小組（Executive Action Team ，縮寫為EAT）。各個SoS不能消除的障礙，最終會反饋到EAT。因此，它必須由在行政上和財務上得到充分授權的個體組成，才能消除障礙。EAT的職能是協調多個SoS（或多個SoSoS）。同Scrum團隊一樣，它也需要一個PO和一個SM。EAT最好能像Scrum團隊一樣每天碰面。每個衝刺他們必須至少碰面一次，並有一個透明的待辦列表。
展示1個EAT協調5組25個Scrum團隊的示例圖
Scrum是一個區別於傳統項目管理的敏捷運作系統。整個SM組織向EAT匯報，EAT負責通過建立、維護和強化組織中的執行，來實施這個敏捷運作系統。EAT的角色職責是創建一個組織變革待辦列表（經過優先級排序的待完成敏捷事項清單），並跟進執行落地情況。例如，如果原先組織中存在傳統的產品開發生命週期，那麼就必須創建、實施和支持一個全新的敏捷產品開發生命週期。它通常能比舊方法更好地支持質量和合規性問題，但是會以不同的方式和不同的規則及準則來實施。
EAT對組織內的Scrum質量負責。其職責包括但不限於：
最後，EAT必須以類似SoS的形式把PO們也組織起來，建立和支持一個相應的產品負責人組織，以擴展他們的PO功能。這些由PO和關鍵干係人們組成的團隊稱為“MetaScrum”。
SM組織（SoS、SoSoS和EAT）作為一個整體，協同完成Scrum Master循環中的其他組件：持續改進、消除障礙、跨團隊協調和部署。
持續改進和消除障礙的目標是：
跨團隊協調的目標是：
既然SoS的目標是作為發布團隊來運作，產品的部署也在其職責範疇內，而在發布版本中發布什麼內容則屬於產品負責人們的職責範疇。因此，部署的目標是：
一個SoS需要一份唯一的產品待辦列表作為輸入，負責整合這份產品待辦列表的這些產品負責人自身構成一個稱為“MetaScrum”的團隊。每個SoS都有一個相關的MetaScrum。MetaScrum將所有團隊的優先級沿著一條路徑進行排列，以便整合產品待辦列表，並通過與乾係人達成一致來獲得他們對整合後產品待辦列表的支持。各個MetaScrum會執行多團隊的當前發布的產品待辦列表精化。
這個事件按需執行，每個衝刺至少會執行一次，以確保提供一個就緒的產品待辦列表。MetaScrum的主要職能是：
類似於SoS，MetaScrum自身也像Scrum團隊一樣運作。因此，他們需要有人擔任SM並確保團隊在討論時不偏離方向。他們還需要有一個人負責協調本MetaScrum的所有團隊，整合出一份唯一的產品待辦列表。這個人被稱為首席產品負責人（Chief Product Owner，縮寫為CPO）。
通過MetaScrum，CPO與各個團隊的產品負責人協調優先級順序。他們依據干係人和客戶需要來對產品待辦列表進行優先級排序。就像SoSM一樣，CPO可以選擇由某個團隊PO擔任，也可以由某個專職人員來擔任。CPO的主要職責同普通PO是完全一樣的，只不過是擴展層面的：
就像SoS能擴大為SoSoS一樣，MetaScrum也能採用同樣的機制進行擴展。這些擴展單位沒有專門的術語，其CPO也沒有專門的擴展頭銜。我們鼓勵每個組織自行定義這些術語和擴展頭銜。在下圖中，當PO團隊擴大時，我們選擇添加一個額外的“首席（Chief）”修飾詞到其頭銜中。
一些示例圖：
說明：如上所述，這些五邊形代表著理想規模的Scrum團隊和理想規模的MetaScrum。這些圖僅僅是示例而已，您的組織圖可能會有很大的差別。
MetaScrum使我們能夠設計一個產品負責人網絡，這個網絡能與相關的SoS一起無限擴展。針對整個敏捷組織的MetaScrum，即為決策層MetaScrum（Executive MetaScrum ，縮寫為EMS）。EMS擁有組織願景並為整個集體設置戰略優先級，使所有團隊都圍繞共同目標調整一致。
顯示一個EMS協調5組25個團隊的示例圖：
PO組織（各個MetaScrum，CPO和EMS）作為一個整體，協同實現產品負責人循環的組件：戰略願景、待辦列表優先級排序，待辦列表分解&精化，和發布規劃。
規劃戰略願景的目標是：
待辦列表優先級排序的目標是：
待辦列表分解&精化的目標是：
發布規劃的目標是：
反饋組件是PO與SM循環的第二個交點。產品反饋通過調整產品待辦列表來驅動持續改進，而發布反饋則通過調整髮布機制來驅動持續改進。獲取和分析反饋的目標是：
徹底的透明是Scrum能最佳運作的關鍵，但這只可能出現在擁抱Scrum價值觀的組織中。它賦予組織真誠地評估其工作進展，以及檢視和改變產品及過程使之更適應的能力。正如《Scrum指南》所闡述的那樣，這是Scrum的經驗主義本質的根基。
SM循環和PO循環都需要度量，具體的度量指標分別由SM組織和PO組織決定。對於這兩個特定組織以及這兩個組織中的特定職能來說，度量指標可能是唯一的。Scrum@Scale並不需要任何特定的度量指標集，但是它確實建議組織在最低程度上應當度量：
度量和透明的目標是：
Scrum@Sacle的“可自由擴展（Sacle-Free）”的自然屬性，使得我們可以基於組件的方式設計組織架構，就像這個框架自身一樣。它讓我們可以根據市場需要進行團隊的重構和再平衡。隨著組織的發展，獲得分佈式團隊的好處可能是很重要的。通過開發外包，一些企業獲得了其它方式無法獲得的人才，並按需進行擴張和僱用。Scrum@Sacle展示瞭如何做到這一點，同時避免過長的滯後時間，妥協的溝通和低劣的質量，使其可以在組織規模和全球分佈上都可以線性擴展。
在這張組織圖中，知識團隊和基礎設施團隊代表由專家組成的虛擬團隊，由於專家人數太少而不可能為每個團隊都配備。他們作為一個小組與Scrum團隊們通過服務等級協議進行協作，小組中為每個專業都設置了一位PO，所有對某專業的服務請求都必須流經該專業的PO，並由PO負責把服務請求轉化為透明的、經過優先級排序的待辦列表。需要重點說明的是，這些團隊並不是所有成員都坐在一起的集中封閉式團隊（這就是他們被表示為空心五邊形的原因）；他們的團隊成員都坐在實際的Scrum團隊中，但他們自身組成了這個虛擬Scrum團隊，以實現在組織中散播待辦列表和過程改進。
這裡也包括客戶關係、法律/合規，以及人力運營，因為他們也是組織不可或缺的部分，並且將會作為獨立的Scrum團隊而存在，其他所有團隊可能都會依賴他們。
最後再說明一下對EAT和EMS的表示：在這張圖中，他們顯示為重疊的，因為有2位成員在兩個團隊中都存在。在非常小的組織或實施中，EAT和EMS可以由完全相同的一組成員組成。
Scrum@Scale是為提高生產率而設計的，旨在使整個組織在改善質量和顯著改善工作環境的情況下實現事半功倍。在大型組織中恰當地實施本框架，可以降低產品和服務的成本，同時提高質量和促進創新。
Scrum@Scale是為了能讓組織貫徹和執行Scrum而設計的。所有的團隊，包括領導、人力資源、法律、諮詢和培訓，以及產品和服務團隊，實施相同風格的Scrum，同時精簡和強化組織。
良好實施的Scrum能夠運作起整個組織。
我們感謝IDX創建了SoS，這使得Scrum可以擴展到幾百個團隊【6】；感謝PatientKeeper 創建了MetaScrum【7】，這使得創新產品得以快速部署；感謝OpenView Venture Partners把Scrum擴展到整個組織【8 】。我們看重來自Intel的輸入，超過25000人在執行Scrum，這教會我們——除了一個“可自由擴展的架構外（Sacle-Free）”“沒有什麼能擴展”；SAP擁有最大Scrum團隊規模的產品組織，教會我們——管理層參與到MetaScrum中，是實現2000個Scrum團隊協作的關鍵。
那些在亞馬遜、GE、3M、豐田、Spotify和其他許多公司與Jeff Sutherland一起工作和實施這些概念的敏捷教練和培訓師們，為在不同領域的眾多公司中驗證這些概念提供了幫助。
最後，Avi Schneier和Alex Sutherland對本文檔的製作和編輯有著無法估量的價值。
了解Scrum
warren2lynch
iThome鐵人賽
看影片追技術