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