5.5 对比至少两个规模化扩展产品负责人的模式
5.5 contrast at least two patterns for scaling the Product Owner role.
Nexus
Nexus：应用于多个Scrum团队处理同一个产品或问题，“规模化的Scrum仍然是Scrum”。
Nexus 有唯一的一名 Product Owner，负责管理 Scrum Team 工作的惟一的一份Product Backlog。
Nexus Integration Team：
组成包括:
• Product Owner：Nexus 处理惟一的 Product Backlog，如 Scrum 所述，一份 Product Backlog 有唯一的一名 Product Owner，对 Product Backlog 的内容拥有最终决定权。Product Owner 负责产品价值最大化，由 Nexus 中的 Scrum Team 来执行和集成工作。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，工作范围是整个大产品
2. 允许组织自由发挥
3. Backlog梳理是自上而下的
在规模化情景下，跨团队的 Product Backlog Refinement服务于双重目的:
• 帮助 Scrum Team 预估哪个团队将交付哪些 Product Backlog 条目。
• 识别跨团队之间的依赖关系。
如有需要，每个 Scrum Team 将各自继续梳理Product Backlog，以便在 Nexus Sprint Planning 事件中，Product Backlog
条目已经为被选择准备就绪。一个充分梳理的 Product Backlog 将可以最大限度地减少在 Nexus Sprint
Planning 时新依赖关系的涌现。
4. 与Scrum保持一致，在Scrum上加壳
Scrum@Scale
Scrum@Scale：Scrum@Scale是一个对Scrum进行扩展的框架。通过使用Scrum来扩展Scrum，它彻底简化了规模扩展。它仅仅包含一些Scrum团队，这些团队通过Scrum of Scrums和MetaScrums进行整合。在此框架中，一致采用Scrum指南进行运作的Scrum团队网络可以解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。
产品负责人循环：
如果一组产品负责人有必要整合一个唯一的待办清单，以供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。
高管MetaScrum（EMS）
MetaScrum使得PO及其对应的SoS能够以一种网状设计进行无限地扩展。整个敏捷组织的MetaScrum是高管MetaScrum。EMS拥有组织的愿景并设立整个公司的战略优先级，使各个团队围绕共同目标来对齐。
例图展示了1个EMS，正在协调分为5个组的25个团队：
产品负责人组织的输出/效果
PO组织(各种MetaScrum，CPO和高管MetaScrum)作为整体来工作以满足产品负责人循环的组件：战略愿景、待办清单优先级排序、待办清单分解和梳理，以及发布计划
设置战略愿景的目标是：
∙ 透过一个共享的路径清晰地对齐整个组织。
∙ 清晰而有力地表述组织为什么存在。
∙ 描述组织会做什么从而调度其关键资产以支持其使命。
∙ 持续更新以响应快速变化的市场情况。
待办清单优先级排序的目标是：
∙ 针对待交付的产品、功能和服务，识别出一个清晰的排序。
∙ 待办清单的排序反映了价值创造、风险缓解和内部依赖。
∙ 在分解和梳理待办清单之前，先在整个敏捷组织内对高层举措进行排序。
待办清单分解和梳理的目标是：
∙ 把复杂项目和产品分解为独立的可工作元素，每个元素都可以被一个团队在一个Sprint中完成。
∙ 捕获和提炼涌现的需求和客户反馈。
∙ 确保所有的待办事项条目是真的“准备就绪”以便被各个团队拉取。
发布计划的目标是：
∙ 预报关键特性和能力的交付
∙ 向干系人沟通交付预期
∙ 按需更新优先级排序
我的理解：
1. 无限扩展
2. 是否会不可避免的出现金字塔结构（层级关系）
3. 底层Scrum需要做好
