SCRUM@SCALE指南- 20210903
2021-09-09 11:38:37 0 举报AI智能生成
坚持一日一思维导图，加油！ 近期钻研主题：敏捷 参考链接：https://www.scrumcn.com/agile/scrumatscale.html 最后，走过路过点个小赞 👍 ，谢谢！
作者其他创作
大纲/内容
价值观驱动的文化
建立健康的组织
在经验主义环境中打造价值观驱动的文化
Scrum的价值观
驱动经验决策
驱动经验决策
Scrum的价值观
开放
保证透明深入到所有的工作和过程
缺乏
无法做到对工作和过程进行真诚地检视和改进
勇气
采取必要而大胆的变革
以创新的方式更快地交付价值
专注
承诺
尊重
以尊重工作人员为本
三大支柱
透明
检视
适应
Scrum@Scale
支持服务型领导风格
基于意图的领导模式
帮助组织茁壮成长
营造积极环境
用可持续的节奏工作
承诺把客户价值交付作为首要事务
启动SCRUM@SCALE
实现大型Scrum团队网络时
先针对一个小规模团队集开发出一个可扩展的参考模型
任何Scrum实施上的短板在部署到多个团队时都将被放大
首先建立小规模scrum团队集
能够良好实施
解决那些阻碍敏捷的组织问题
一个参考模型
引入到组织
作为在整个组织范围内扩展Scrum的模式
参考模型的加速
延迟交付
制造浪费
妨碍业务敏捷性的障碍及瓶颈
解决手段
将Scrum扩展到整个组织
在整个价值链条上做优化
Scrum@Scale
在组织中贯彻落实Scrum
有机地分配速度和质量
实现同步线性增长
生产率
组织
具体战略
产品
服务
SCRUM MASTER循环
团队级过程
组成
三个工件
五个事件
三个角色
目标
使已完成且通过品质测试的工作最大程度地流动起来
每个冲刺都能在团队速率上得到少许提升
以一种对团队来说既可持续又极为充实的方式来运作
协调“怎么做”
-SCRUM OF SCRUMS，
缩写为SOS
-SCRUM OF SCRUMS，
缩写为SOS
Scrum of Scrums（SoS）
彼此协作的团队可以组建一个“Scrum of Scrums（SoS）”
一个跨团队协作的Scrum团队
由Scrum Master们组成的团队本身就是一个Scrum团队
负责在每个冲刺结束时从所有参与的Scrum团队中集成得到完整的潜在可交付产品增量
实时响应各参与团队提出的障碍
作为一个发布团队
能够直接向客户交付价值
（Sacled Daily Scrum），
简称：SDS
简称：SDS
一个跨团队的Scrum每日例会
每个团队都会派代表参加SDS
团队中的任何人或者任意数量的人都有可能参加
通常是Scrum Master参加
目的
协调团队，以及消除团队交付价值的障碍
SDS事件
时间被限制在15分钟以内
每个团队必须派代表参加会议
是一个团队代表们解决三个简单问题的讨论会
本团队有什么障碍会妨碍其他团队完成其冲刺目标
或者影响即将到来的发布版本
本团队是否正在做任何会妨碍其他团队完成其冲刺目标的事情？
或者影响即将到来的发布版本
我们是否发现了任何新的跨团队依赖，或者发现了现存依赖的解决方法？
SoS必须具备所有必需的技能
产品负责人的代理人
负责解决优先级问题
经验丰富的架构师、QA负责人
其他具有操作技能的人们
刚开始启动Scrum@Scale时
不具备支撑持续部署的基础设施
不得不
建立一个“集成团队”或“发布团队”
克服工程技术缺陷而产生的额外工作
鼓励SoS
积极地解决集成和部署障碍
打造实现超高生产率所需的环境
例如亚马逊有3300个Scrum团队，平均每秒部署一次以上
SOS MASTER
（THE SCRUM OF SCRUMS MASTER，
缩写为SOSM）
（THE SCRUM OF SCRUMS MASTER，
缩写为SOSM）
对团队们联合产出的发布版本负责
职责
制定组织可见的障碍待办列表
消除各个团队无法自行解决的障碍
对障碍进行优先级排序，并特别关注跨团队依赖和待办列表的分布情况
提升SoS的效能
与产品负责人们密切协作，在每个冲刺中至少部署一个潜在可发布产品增量
结合产品负责人的发布规划，协调各个团队的部署工作
扩展SOS
Scrum of Scrum of Scrums（SoSoS）
多个SoS协作
基于组织和实施团队的规模
交付非常复杂的产品可能需要多个SoS协作
在多个Scrum of Scrum之上
建立一个Scrum of Scrum of Scrums（SoSoS）
Scrum团队群的一个有机模式
可以无限扩展
每个SoSoS应该有自己的SoSoS Master（缩写：SoSoM
优点
减少组织内的沟通路径数
使复杂度得到封装
协作方式
完全相同
SoSoS与SoS
SoS与单个Scrum团队
子主题
4或5人是最佳的协作规模
决策层行动小组
（EXECUTIVE ACTION TEAM，
缩写为EAT）
（EXECUTIVE ACTION TEAM，
缩写为EAT）
决策层行动小组
Executive Action Team ，
缩写为EAT
缩写为EAT
针对整个敏捷组织的SoS
各个SoS不能消除的障碍，最终会反馈到EAT
组成
在行政上和财务上得到充分授权的个体
也需要一个PO和一个SM
职能
协调多个SoS（或多个SoSoS）
最好能像Scrum团队一样每天碰面
个冲刺他们必须至少碰面一次
有一个透明的待办列表
EAT协调5组25个Scrum团队的示例图
子主题
EAT的待办列表和职责
组织变革待办列表
经过优先级排序的待完成敏捷事项清单
跟进执行落地情况
例如
原先组织中存在传统的产品开发生命周期，
那么就必须创建、实施和支持一个
全新的敏捷产品开发生命周期
那么就必须创建、实施和支持一个
全新的敏捷产品开发生命周期
职责
对组织内的Scrum质量负责
对组织内的Scrum质量负责
在组织范围内为参考模型创建一个敏捷运作系统，
包括企业运作的规则、规程和指南，
以使敏捷能得以实施
包括企业运作的规则、规程和指南，
以使敏捷能得以实施
度量和改进组织中的Scrum质量
在组织内打造业务敏捷性能力
为Scrum专业人员创建一个持续学习中心
支持探索新的工作方式
MetaScrum
产品负责人组织
产品负责人组织
由PO和关键干系人们组成的团队
以类似SoS的形式把PO们也组织起来
建立和支持一个相应的产品负责人组织
SCRUM MASTER
组织的产出/成果
组织的产出/成果
SM组织
SoS
SoSoS
EAT
协同完成Scrum Master循环中的其他组件
持续改进
消除障碍
跨团队协调和部署
持续改进和消除障碍的目标
识别障碍并把它们转化为
组织改进的机会
组织改进的机会
维护一个安全和结构化的环境，
以对障碍进行优先级排序，
消除障碍并验证由此带来的改进
以对障碍进行优先级排序，
消除障碍并验证由此带来的改进
确保组织中的可见性，
以促进变革
以促进变革
跨团队协调的目标
协调跨多个相关团队的类似过程
管理跨团队依赖，
确保它们不会转变为障碍
确保它们不会转变为障碍
维护团队规范和准则的一致性，
以确保输出一致
以确保输出一致
部署的目标
向客户持续地交付有价值的成品
把来自不同团队的工作成果集成为一个无缝的产品
确保客户体验的高质量
产品负责人循环
协调“做什么”– MetaScrum
“MetaScrum”的团队
一个SoS需要一份唯一的产品待办列表作为输入
负责整合这份产品待办列表的这些产品负责人自身构成一个称为“MetaScrum”的团队
每个SoS都有一个相关的MetaScrum
将所有团队的优先级沿着一条路径进行排列，以便整合产品待办列表
通过与干系人达成一致来获得他们对整合后产品待办列表的支持
执行多团队的当前发布的产品待办列表精化
每个团队的PO（或者PO代理人）都必须参加。
这个事件是一个供领导层、干系人或其他客户表达他们喜好的讨论会
MetaScrum的主要职能
为产品规划一个总体愿景并使其对组织可见
与关键干系人达成一致，以确保其支持产品待办列表的实施
生成一份唯一的、经过优先级排序的产品待办列表，确保避免重复劳动
创建一个统一的“完成的定义”，应用于SoS中的所有团队
消除SoS提出的依赖
生成已整合的发布规划
决定采用哪些度量指标来洞察产品，并执行监控
首席产品负责人
（CHIEF PRODUCT OWNER ，
缩写为CPO）
（CHIEF PRODUCT OWNER ，
缩写为CPO）
首席产品负责人
负责协调本MetaScrum的所有团队
整合出一份唯一的产品待办列表
CPO与各个团队的产品负责人协调优先级顺序
职责
规划整个产品的战略愿景
创建一份唯一的、经过优先级排序的产品待办列表，包括所有团队要交付的价值
与单个团队PO的产品待办列表项相比，这些产品待办列表项可能是更大的故事
与相关的SoSM密切协作，使MetaScrum团队生成的发布规划得到高效部署
监控客户的产品反馈，并对产品待办列表进行相应的调整
扩展METASCRUM
每个组织自行定义扩展单位术语和扩展头衔
当PO团队扩大时，我们选择添加一个额外的“首席（Chief）”修饰词到其头衔中
理想规模的Scrum团队和理想规模的MetaScrum
子主题
决策层METASCRUM
（EXECUTIVE METASCRUM ，
缩写为EMS）
（EXECUTIVE METASCRUM ，
缩写为EMS）
MetaScrum
使我们设计一个产品负责人网络
能与相关的SoS一起无限扩展
决策层MetaScrum
（Executive MetaScrum ，
缩写为EMS）
（Executive MetaScrum ，
缩写为EMS）
针对整个敏捷组织的MetaScrum
拥有组织愿景
为整个集体设置战略优先级
所有团队都围绕共同目标调整一致
EMS协调5组25个团队的示例图
子主题
产品负责人组织的
产出/成果
产出/成果
PO组织
各个MetaScrum
CPO
EMS
协同实现产品负责人循环的组件
战略愿景
待办列表优先级排序
待办列表分解&精化
发布规划
规划战略愿景的目标
使整个组织沿着一条共享的前进路径清晰地调整一致
令人信服地表明组织存在的意义
描述组织将如何撬动关键资产以支持其使命
持续地更新，以应对快速变化的市场环境
待办列表优先级排序的目标
将待交付的产品、特性和服务，
确定一个清晰的优先级顺序
确定一个清晰的优先级顺序
在待办列表的排序中，
要反映出价值创造、风险缓解和内部依赖
要反映出价值创造、风险缓解和内部依赖
在待办列表分解和精化前，
先在整个敏捷组织层面进行高级事项的优先级排序
先在整个敏捷组织层面进行高级事项的优先级排序
待办列表分解&精化的目标
把复杂的项目和产品分解成独立的功能单元，
这些单元应当能由单个团队在一个冲刺内完成
这些单元应当能由单个团队在一个冲刺内完成
捕获和提炼浮现出的需求和客户反馈
确保所有的待办列表项都是真地“就绪”，
以便能够被各个团队领取
以便能够被各个团队领取
发布规划的目标
预报关键特性和能力的交付
与干系人沟通交付预期
必要时更新优先级
理解反馈
反馈组件
PO与SM循环的第二个交点
产品反馈
调整产品待办列表来驱动持续改进
发布反馈
调整发布机制来驱动持续改进
获取和分析反馈的目标
验证我们的假设
理解客户如何使用产品以及如何与产品交互
捕获对新特性和新功能的创意
定义现有功能的改进点
更新产品/项目的进展，提炼发布规划并与干系人达成一致
识别对部署方式和部署机制的改进点
度量和透明
彻底的透明
Scrum能最佳运作的关键
出现在拥抱Scrum价值观的组织中
赋予组织真诚地评估其工作进展
检视和改变产品及过程使之更适应的能力
Scrum的经验主义本质的根基
度量
SM循环和PO循环都需要
度量指标
分别由SM组织和PO组织决定
可能是唯一的
不需要任何特定的度量指标集
组织最低程度的度量
生产率
例如，每冲刺的交付可用产品量的变值
价值交付
例如，每单位团队工作量的商业价值
质量
例如，缺陷率或服务宕机时间
可持续性
例如，团队的幸福感
度量和透明的目标
向所有决策者（包括团队成员）
提供适度的背景信息，
以便做出正确的决策
提供适度的背景信息，
以便做出正确的决策
尽可能缩短反馈周期，
以避免矫枉过正
以避免矫枉过正
要尽可能地减少团队、
干系人或领导的额外投入
干系人或领导的额外投入
关于组织设计的一些说明
Scrum@Sacle的“可自由扩展（Sacle-Free）”的自然属性
基于组件的方式设计组织架构
根据市场需要进行团队的重构和再平衡
通过开发外包，
一些企业获得了其它方式无法获得的人才，
并按需进行扩张和雇用
一些企业获得了其它方式无法获得的人才，
并按需进行扩张和雇用
避免
过长的滞后时间
妥协的沟通
低劣的质量
在组织规模和全球分布上都可以线性扩展
子主题
专家组成的虚拟团队
知识团队
基础设施团队代表
每个专业设置一位PO
专家人数太少而不可能为每个团队都配备
作为一个小组与Scrum团队们通过服务等级协议进行协作
所有对某专业的服务请求都必须流经该专业的PO
由PO负责把服务请求转化为透明的、经过优先级排序的待办列表
这些团队并不是所有成员都坐在一起的集中封闭式团队
表示为空心五边形的原因
他们的团队成员都坐在实际的Scrum团队中，但他们自身组成了这个虚拟Scrum团队
实现在组织中散播待办列表和过程改进
独立的Scrum团队
客户关系
法律/合规
人力运营
其他所有团队可能都会依赖他们
对EAT和EMS的表示
显示为重叠
有2位成员在两个团队中都存在
非常小的组织或实施
EAT和EMS可以由完全相同的一组成员组成
结束语
Scrum@Scale
为提高生产率而设计
使整个组织在改善质量和显著改善工作环境的情况下实现事半功倍
在大型组织中恰当地实施本框架
可以降低产品和服务的成本
提高质量和促进创新
能让组织贯彻和执行Scrum而设计
所有的团队
领导
人力资源
法律
咨询
培训
产品
服务
实施相同风格的Scrum
精简和强化组织
良好实施的Scrum能够运作起整个组织
参考链接
https://www.scrumcn.com/agile/scrumatscale.html
英文：
https://www.scrumatscale.com/scrum-at-scale-guide-read-online/
SCRUM@SCALE指南概述
目的
优化组织整体战略
高效协调多团队的新生态系统
采用可自由扩展的架构（Scale-Free）
建立"最小可行的管理机构”
独立实施Scrum@Scale
包含
构成Scrum @ Scale框架的组件定义
扩展角色
扩展事件
组织工件
把它们组织在一起的规则
Scrum@Scale
Jeff Sutherland博士
基于Scrum
基本原则
复杂适应系统理论
博弈论
面向对象技术
为什么需要SCRUM@SCALE
Scrum是为使单个团队而设计
组织的扩张以及Scrum团队数量的增长，团队们的最佳产出（可工作的产品）以及团队速率在开始下降
实现组织的线性可扩展性
可自由扩展的架构（Scale-Free）
能有效协调多团队的框架
基于其独特的需求
被组织成员群体接受的可持续变化节奏
有机地扩展
覆盖
所有的部门、产品和服务
应用于
行业、政府或学术的各类组织机构的多个领域
SCRUM@SCALE的定义
Scrum
一个框架
解决复杂的自适应难题
高效并创造性地交付最高可能价值的产品
《Scrum指南》
一套最小特征集
彻底的透明
促使检视和适应
促进创新
提升绩效和团队的幸福感
Scrum@Scale
定义
一个框架
一个用于扩展Scrum的框架
使用Scrum来扩展Scrum
通过
SoS（Scrum of Scrums）
MetaScrum
协调的Scrum团队们组成
遵从《Scrum指南》运作的多个Scrum团队组成的网络组织
解决复杂的自适应难题
创造性地交付最高可能价值的产品
特点
轻量的
最小可行的管理机构
易于理解的
由且仅由单个或多个Scrum团队组成
难以精通的
需要实施全新的运作模式
允许组织自行定制其转型策略和实施方式
转型工作
聚焦于其认为最有价值或者最需要变革的区域
再向其他区域推进
关注
从职责上分离“做什么”和“怎么做”
两个循环
Scrum Master循环（负责“怎么做”）
产品负责人循环（负责“做什么”）
产生
能协调多个团队往一处使劲的强有力框架
明确权力和责任
消除会妨碍团队们实现最佳生产率的浪费性组织冲突
“产品”
可以是硬件、软件、复杂集成系统、事务过程、服务等等
取决于Scrum团队们所处的领域
SCRUM@SCALE框架的组件
子主题
职业：本科
0 条评论
下一页
