Scrum At Scale® 指南
版权全部© 2006-2018 Jeff Sutherland 及 Scrum Inc.api
Scrum@Scale是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);网络
简体中文版受权译文连接：http://www./scrum-at-scale-guide-chinese/，欢迎转载，请保留全部版权信息并遵循共享许可协议进行演绎。架构
Scrum@Scale指南之目的
最初在Scrum指南中描述的Scrum，是单个团队进行开发、交付和持续发展复杂产品的框架。自诞生以来，它已经扩展到须要多个团队合做来建立产品、处理过程、服务和系统。建立Scrum@Scale是为了有效地整合这种新型的团队生态系统，从而优化组织的总体策略。为了实现这个目标，它利用一个自由扩展的架构创建起一个“最小可行的官僚机构”，天然地将单个Scrum团队的功能扩展到整个组织中。app
本指南包括构成Scrum@Scale框架的组件定义，包括扩展的角色、扩展的事件、企业级工件，以及将它们组织在一块儿的各类规则。框架
Jeff Sutherland博士基于Scrum、复杂自适应系统理论、博弈论、面向对象技术等背后的基础原则开发了Scrum@Scale。本指南采纳了许多有经验的Scrum实践者的输入，基于他们的现场工做成果。本指南之目标是读者可以自行实施Scrum@Scale。分布式
为何要Scrum@Scale?
Scrum是为单个团队而设计，使其可以在可持续的速率下发挥最佳生产力。在该领域中，人们发现随着组织内的Scrum团队数量增加，最佳输出（可工做的产品）及那些团队的速率会开始降低（好比因为跨团队依赖和重复劳动等问题）。很明显，为了得到线性的可扩展性，人们须要一个有效整合那些团队的框架。设计Scrum@Scale是为了利用自由扩展的架构达成这个目标。ide
经过使用无标度架构，组织的增加并不受限于以一组武断规则所决定的特定方式；相反，它能够有机地基于本身的独特需求而增加，并维持可持续的变革速度，从而能够被组织的成员们接受。post
Scrum@Scale是为组织的总体扩展而设计：全部部门、产品和服务。它能够被运用到不一样领域，包括工商业、政府或学术界中的各种组织。学习
Scrum@Scale的定义
Scrum（名词）：Scrum是一个框架，在此框架中，人们能够解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。
Scrum指南是最小功能的集合，它经过完全的透明性促进检视和适应性，从而驱动创新、绩效和团队幸福感。
Scrum@Scale（名词）：Scrum@Scale是一个框架，在此框架中，一致采用Scrum指南进行运做的Scrum团队网络能够解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。
注意： 这些“产品”能够是硬件、软件、复杂的集成系统、处理过程、服务等，取决于Scrum团队所处的领域。
Scrum@Scale是: * 轻量的 – 最小可行的官僚机构 * 易于理解的 – 仅仅包含Scrum团队们 * 难以精通的 – 须要实施一个全新的运做模型
Scrum@Scale是一个对Scrum进行扩展的框架。经过使用Scrum来扩展Scrum，它完全简化了规模扩展。它仅仅包含一些Scrum团队，这些团队经过Scrum of Scrums和MetaScrums进行整合。
Scrum@Scale自己基于组件的性质容许组织定制他们的转型策略和实现方式。它使得他们得到一种能力，能够将转型的努力聚焦在他们认为最有价值或最须要改变的领域内，而后再向其余方面取得进展。
在Scrum中，要注意区分对“What”与“How”的问责。在Scrum@Scale中也是同样，那么就要明确地理解权限和职责，从而消除浪费性的组织冲突，令团队更容易达致最佳生产力。
为了区分这两个权限，Scrum@Scale包含两个回路：Scrum Master回路（“How”）和产品负责人回路（“What”），彼此具备两个相互接触点。总之，这些回路造就了一个强大的框架，整合多个团队朝着同一个方向而努力。
Scrum@Scale框架的组件
价值观驱动的文化
除了区分对“What”与“How”的问责，Scrum@Scale还进一步在实证背景下创造价值驱动的文化，旨在创建健康的组织。Scrum的价值观包括：开放、勇气、专一、尊重和承诺。这些价值观驱动着实验性决策，而其取决于透明、检视和调整这三大支柱。
开放支持着全部工做和过程的透明性，没有这种透明度，就没法诚实地检视并试图更好地调整它们。勇气指的是大胆跳跃，这是以创新方式更快地交付价值所须要的。
专一和承诺是咱们处理工做职责的方式，把交付客户价值做为最高优先级。最后，全部这一切都必须发生在一个尊重每一个人的工做环境中，不然不可能创造任何东西。
Scrum@Scale支持仆人式领导风格和基于意图的领导力模型，以帮助组织蓬勃发展，1培养一个以可持续速率进行工做的积极环境，致力于将面向客户价值放在努力的第一位。
开始使用Scrum@Scale
在实施大型团队网络时，针对少许团队开发出一个可扩展的参考模型是相当重要的。当部署多个团队时，Scrum实施中的任何缺陷都会被放大。
所以，第一个挑战就是创建少许良好实施Scrum的团队。这组团队克服了那些阻碍敏捷性的组织问题，并为Scrum建立一个在组织中众所周知可运行的参考模型，将其用做整个组织范围内扩展Scrum的模式。
随着团队参考模型的加速，延迟交付、产生浪费或妨碍业务敏捷性的障碍及瓶颈会变得明显。消除这些问题的最有效方法是在整个组织中传播Scrum，以便优化整个价值流。
Scrum@Scale经过使组织浸泡在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负责人和其余操做技能组。当启动Scrum@Scale时，团队们可能还不具有可以支持持续部署的基础架构。这会迫使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回路交叉的第二个点。产品反馈经过调整产品待办清单来驱动持续改进，发布反馈经过调整部署机制来驱动持续改进。获取和分析反馈的目标是：
- 验证咱们的假设。
- 理解顾客如何使用产品和与产品互动。
- 捕获新特性和新功能的创意。
- 定义针对已有功能的改进。
- 朝着产品/项目完成的方向更新进度，以更好地规划发布计划并与干系人对齐。
- 识别出部署方法和机制的改进项。
度量与透明性
完全的透明性是Scrum最佳状态运做的本质，可是只在可以拥抱Scrum价值观的组织中可行。它使组织可以诚实地评估进度并检视和调整其产品及过程。这是Scrum指南中记载的Scrum的实证主义本性的基石。
SM和PO回路各自须要的度量会分别由SM和PO组织来决策。对于两个特定组织以及那些组织中的特定功能来讲，度量也多是惟一的。Scrum@Scale并不要求任何特定的度量集，可是它推荐了最低配置，即组织应该度量以下方面:
- 生产力 —— 例如，每一个Sprint交付的可工做产品的总量变化
- 价值交付 —— 例如，单位团队工做量可以带来的业务价值
- 质量 —— 例如，缺陷率或者服务宕机时间
- 可持续性 —— 例如，团队满意度
设置这些度量指标以及透明性是为了：
- 提供适当的上下文给全部的决策者——包括团队成员在内——以作出优秀的决策。
- 尽可能缩短反馈周期以免矫枉过正。
- 最小化地要求团队、干系人和领导者进行额外投入。
关于组织设计的一些说明
Scrum@Scale自由扩展的本性，容许将组织设计为一个个组件，就像框架自己同样。它容许从新平衡和重构团队，从而响应市场。随着组织的增加，分布式团队带来的益处可能也很重要。一些组织在没法获取人才的时候则经过外包开发来扩展和签约。Scrum@Scale展现了如何扩展这种状况，同时避免过长的延迟时间、妥协的沟通以及低劣的质量，使得组织在规模上和地理分布上兼具线性扩展性。5
在这个组织图中，知识和基础设施团队表示一些虚拟的专业团队，这些专家的数量太少，难以保证在每一个团队中都配备。他们做为一个组与多个Scrum团队进行整合，遵守服务水平协议，每一个专业方面请求都流经同一个PO，他将那些请求转换为透明的已排序的待办清单。值得注意的是，这些团队并非坐在一块儿的一群各自为政的个体(这是为何他们被标记为中空多边形)；这些团队成员都坐在实际的Scrum团队当中，可是他们组成这个虚拟Scrum是为了传播待办清单和过程改进。
客户关系，法务/合规、人力运营也包含在这里，由于他们是组织中必要的部分，他们将独立于Scrum团队而存在，其余人将依赖于他们。
关于EAT和EMS的最后一点：在这个图中，因为有2个成员同时存在于这两个团队中，因此二者看起来是重叠了。在很是小的组织或者实施中，EAT和EMS能够由同一批人组成。
结束语
Scrum@Scale是为了扩展生产力而设计的，使得整个组织在一个显著改善的工做环境中可以高质量地作到事半功倍。在大型组织中适当的应用本框架能够削减产品和服务的成本，而且提高质量和创新。
Scrum@Scale是为了让Scrum浸透组织而设计的。全部团队，包括了领导层、人力资源、法务、咨询和培训，以及产品和服务团队，他们在精简和提高组织的时候都采用同一种Scrum风格。
良好实施的Scrum能够运做起整个组织。
致谢
咱们感谢IDX建立了Scrum of Scrums，它容许Scrum扩展到上百个团队，6感谢PatientKeeper建立了MetaScrum，7它使得创新产品能快速部署，感谢OpenView Venture Partners将Scrum扩展到整个组织。8 咱们珍视来自英特尔的二万五千多人实施Scrum的输入，教会了咱们——“没有事物能扩展”——除了一个自由扩展的架构，还要感谢具备最大的Scrum团队的SAP产品组织，教会了咱们让2000多个Scrum团队一块儿工做的必要因素就是让管理层参与到MetaScrum中。
敏捷教练和培训师们与Jeff Sutherland一块儿工做，在亚马逊、GE、3M、丰田、Spotify和不少其余公司实施了这些概念，这对于在更广范围的不一样领域的公司中验证这些概念是很是有帮助的。
最后，Avi Schneier和Alex Sutherland制定和编辑本文的工做是价值无量的。
- Marquet, L David, Turn the Ship Around!: How to Create Leadership at Every Level, Greenleaf Book Group, 2012 ↩
- McChrystal, General Stanley and Collins, Tantum and Silverman, David and Fussell, Chris, Team of teams: New rules of engagement for a complex world, Penguin, 2015 ↩
- Monica, R. (2018). Personal Communication: Amazon Scrum Implementation. J. Sutherland. Seattle, Amazon. ↩
- Hackman, J Richard, Leading teams: Setting the stage for great performances, Harvard Business Press, 2002 ↩
- Sutherland, Jeff and Schoonheim, Guido and Rustenburg, Eelco and Rijk, Maurits, “Fully distributed scrum: The secret sauce for hyperproductive offshored development teams”, AGILE’08. Conference, IEEE: 339-344, 2008 ↩
- Sutherland, Jeff, “Inventing and Reinventing SCRUM in five Companies”, Sur le site officiel de l’alliance agile, 2001 ↩
- Sutherland, Jeff, “Future of scrum: Parallel pipelining of sprints in complex projects”, Proceedings of the Agile Development Conference, IEEE Computer Society 90-102, 2005. ↩
- Sutherland, Jeff and Altman, Igor, “Take no prisoners: How a venture capital group does scrum”, Agile Conference, 2009. AGILE’09, IEEE 350-355. 2009 ↩
