5.5 對比至少兩個規(guī)模化擴展產(chǎn)品負責人的模式

5.5 contrast at least two patterns for scaling the Product Owner role.

Nexus

Nexus：應用于多個Scrum團隊處理同一個產(chǎn)品或問題，“規(guī)某笞铮化的Scrum仍然是Scrum”。

Nexus 有唯一的一名 Product Owner喻圃，負責管理 Scrum Team 工作的惟一的一份Product Backlog源梭。

Nexus Framework

Nexus Integration Team：

組成包括:

??Product Owner：Nexus 處理惟一的 Product Backlog铺呵，如 Scrum 所述，一份 Product Backlog 有唯一的一名 Product Owner，對 Product Backlog 的內容擁有最終決定權婉弹。Product Owner 負責產(chǎn)品價值最大化睬魂，由 Nexus 中的 Scrum Team 來執(zhí)行和集成工作。Product Owner 還負責對 Product Backlog 進行有效管理镀赌。如何做到這一點汉买，在不同的組織、Nexus佩脊、Scrum Team 和個體之間可能會存在很大差異蛙粘。

??Scrum Master：Nexus Integration Team 中的 Scrum Master 負責確保 Nexus 框架如 Nexus 指南中所述的那樣得到理解和實施。該 Scrum Master 也可以是這個 Nexus 的一個或多個 Scrum 團隊中的 Scrum Master威彰。

??一個或多個 Nexus Integration Team 成員：Nexus Integration Team 通常由 Scrum Team 的成員組成出牧，他們幫助 Scrum Team 采用工具和實踐，這些工具和實踐有助于 Scrum Team 交付有價值的和有用的 Integrated Increment歇盼，通常符合 Definition of Done舔痕。

我的理解：

1. 唯一一名PO，工作范圍是整個大產(chǎn)品

2. 允許組織自由發(fā)揮

3. Backlog梳理是自上而下的

在規(guī)谋海化情景下伯复，跨團隊的 Product Backlog Refinement服務于雙重目的:

? 幫助 Scrum Team 預估哪個團隊將交付哪些 Product Backlog 條目。

? 識別跨團隊之間的依賴關系邢笙。

如有需要啸如，每個 Scrum Team 將各自繼續(xù)梳理Product Backlog，以便在 Nexus Sprint Planning 事件中氮惯，Product Backlog

條目已經(jīng)為被選擇準備就緒叮雳。一個充分梳理的 Product Backlog 將可以最大限度地減少在 Nexus Sprint

Planning 時新依賴關系的涌現(xiàn)。

4. 與Scrum保持一致妇汗，在Scrum上加殼

Scrum@Scale

Scrum@Scale：Scrum@Scale是一個對Scrum進行擴展的框架帘不。通過使用Scrum來擴展Scrum，它徹底簡化了規(guī)模擴展杨箭。它僅僅包含一些Scrum團隊寞焙，這些團隊通過Scrum of Scrums和MetaScrums進行整合。在此框架中互婿，一致采用Scrum指南進行運作的Scrum團隊網(wǎng)絡可以解決復雜自適應問題捣郊，同時高效并創(chuàng)造性地交付最大價值的產(chǎn)品。

產(chǎn)品負責人循環(huán)：

如果一組產(chǎn)品負責人有必要整合一個唯一的待辦清單擒悬，以供Scrum of Scrums來工作模她，那么他們自己就形成一個團隊稱為MetaScrum稻艰。每個SoS都有一個對應的MetaScrum懂牧。MetaScrum沿著同一路徑來對齊多個團隊的優(yōu)先級，這樣他們就可以整合多個待辦清單，并和干系人保持一致以得到他們對待辦清單的支持僧凤。MetaScrum舉行一種規(guī)男笳欤化的待辦清單梳理活動。

每個產(chǎn)品負責人（或其代理）都必須參加

這個事件是領導者躯保、干系人或其他客戶表達各自傾向的論壇

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

??創(chuàng)建產(chǎn)品的主要愿景并且使之對整個組織可見验懊。

??和干系人保持一致以確保他們支持產(chǎn)品待辦清單的實現(xiàn)。

??創(chuàng)建唯一的排序的待辦清單尸变；確保規(guī)避了重復工作义图。

??針對SoS內所有團隊創(chuàng)建統(tǒng)一的“完成的定義”。

??消除由SoS提出的依賴召烂。

??生成一份整合的發(fā)布計劃碱工。

??監(jiān)控能夠洞察產(chǎn)品的度量，并基于其進行決策奏夫。

類似于SoS怕篷，多個MetaScrum本身也作為Scrum團隊來運作。所以酗昼，需要某人來扮演SM來保持團隊的正常溝通廊谓。他們還需要唯一的人來負責協(xié)調，使得MetaScrum覆蓋的所有團隊創(chuàng)建出唯一的產(chǎn)品待辦清單麻削。這個人被指定為產(chǎn)品總負責人蹂析。

產(chǎn)品總負責人(CPO)

通過MetaScrum，產(chǎn)品總負責人與各個團隊的產(chǎn)品負責人來協(xié)調優(yōu)先級碟婆。他們以干系人以及顧客需求來對齊待辦事項的優(yōu)先級电抚。類似于SoSM，可以是某個團隊的PO來扮演這個角色竖共，或者是某個人全職擔任這個角色蝙叛。他們的主要職責和普通PO是一樣的，但是在擴展的時候：

??建立整個產(chǎn)品的戰(zhàn)略愿景

??創(chuàng)建唯一的公给、排序的待辦清單借帘，包含將要被所有團隊交付的價值。

??這些事項對于一個團隊的PO來說可以是更大規(guī)模的故事淌铐。

??與相應的SoSM緊密工作在一起肺然，以便有效地部署MetaScrum團隊創(chuàng)建的發(fā)布計劃。

??監(jiān)控客戶對產(chǎn)品的反饋并相應地調整待辦清單腿准。

擴展MetaScrum

如同SoS可以增長到SoSoS际起，MetaScrum也可以用同樣的機制進行擴展拾碌。沒有專門的術語對應這些擴展單元，他們的CPO們也沒有專門的擴展頭銜街望。我們鼓勵每個組織發(fā)展自己的方式校翔。下圖中，我們選擇了再增加一個“總”以突出那些PO灾前。

高管MetaScrum（EMS）

MetaScrum使得PO及其對應的SoS能夠以一種網(wǎng)狀設計進行無限地擴展防症。整個敏捷組織的MetaScrum是高管MetaScrum。EMS擁有組織的愿景并設立整個公司的戰(zhàn)略優(yōu)先級哎甲，使各個團隊圍繞共同目標來對齊蔫敲。

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

產(chǎn)品負責人組織的輸出/效果

PO組織(各種MetaScrum炭玫，CPO和高管MetaScrum)作為整體來工作以滿足產(chǎn)品負責人循環(huán)的組件：戰(zhàn)略愿景燕偶、待辦清單優(yōu)先級排序、待辦清單分解和梳理础嫡，以及發(fā)布計劃

設置戰(zhàn)略愿景的目標是：

??透過一個共享的路徑清晰地對齊整個組織指么。

??清晰而有力地表述組織為什么存在。

??描述組織會做什么從而調度其關鍵資產(chǎn)以支持其使命榴鼎。

??持續(xù)更新以響應快速變化的市場情況伯诬。

待辦清單優(yōu)先級排序的目標是：

??針對待交付的產(chǎn)品、功能和服務巫财，識別出一個清晰的排序盗似。

??待辦清單的排序反映了價值創(chuàng)造、風險緩解和內部依賴平项。

??在分解和梳理待辦清單之前赫舒，先在整個敏捷組織內對高層舉措進行排序。

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

??把復雜項目和產(chǎn)品分解為獨立的可工作元素闽瓢，每個元素都可以被一個團隊在一個Sprint中完成接癌。

??捕獲和提煉涌現(xiàn)的需求和客戶反饋。

??確保所有的待辦事項條目是真的“準備就緒”以便被各個團隊拉取扣讼。

發(fā)布計劃的目標是：

??預報關鍵特性和能力的交付

??向干系人溝通交付預期

??按需更新優(yōu)先級排序

我的理解：

1. 無限擴展

2. 是否會不可避免的出現(xiàn)金字塔結構（層級關系）

3. 底層Scrum需要做好