规模化敏捷可能存在的问题：沟通的有效性降低、协作更复杂、对齐困难、集成复杂
敏捷宣言是否依然适用于规模化敏捷？结论是依然试用
规模化敏捷的几种方式： SAFe/LeSS/DAD/EA/Nexus/Scrum@Scale
SoS（scrum of scrums ）的实现方式
Backlog如何维护？
1:一个PO，一个PBL，区分不同的team
2:一个PO，维护多个PBL
3：每个团队有自己的PO，每个PO负责自己的backlog，团队之间的协同，在PO之上增加一个大的PO,senior ,来维护大的PBL .
需求清晰后，每个团队要迭代，要冲刺，如何解决对齐，协同，集成的问题团队1，周二迭代，......每个团队在不同时间节点交付，如何把多个团队的交付集成起来？常用方法：同时开始，同时结束，这样来实现对齐。多团队项目里最常见的问题是依赖，怎么解决？单团队每日站会来解决，多团队通过SOS会议来解决，即每个团队派一个代表参加会议，谁都可以，一般是SM，
SOS落地的时候，Spotify 一个音乐公司，他们创造了一种Spotify的模式，他们称之为tribe群落，部落与部落之间产生协同，成立行会，采用原始部落的形态。
LeSS出发点非常好，也就是越简单越好，大规模的scrum，多团队工作在一个
LeSS多团队一起约好时间，然后到时间大家一起来开会，一起开计划会，来决定what
to do，下半场再单团队开会，选择好之后，然后进行拆解，任务认领.......,结束同时结束，每个人都有一个潜在交付。
回顾：每个团队自己回顾，分别回顾后再派代表参加大的回顾，尽量简化产品。跨层级较多的时候，增加一个senior PO
LeSS落地挑战比较大。
简单产品，并拆分团队。3个主要角色整体上只需要一套，因此存在落地的挑战。
SAFe
从小公司发展到大公司，逐渐的有了部门，有了部门就有了层级，有了层级会出现上传下达，部门墙，每个部门重点不一致，层级智能化组织就会导致协同问题，客户响应速度慢。如何打破部门墙，怎么推翻，即通过价值流为基础重新引入第二套操作系统，即双操作系统，双OS.
按照以客户为中心的价值流网络建立的第二套操作系统，也是SAFe引入的概念。在现有组织架构基础上进行再次组织和协同
SAFe核心价值观对齐（协同一致）透明内建质量项目群实施
SAFe演进的过程离不开敏捷开发、精益产品开发和系统思考
SAFe精益屋增加了创新的概念，精益的持续改进，在SAFe有时候翻译为无情的改进，毫无反悔的改进，要更决绝。实现业务的敏捷
SAFe精髓是成功的基石，10大关键要素[
1.精益-敏捷领导力，最重要的如果领导层不认同敏捷，转型是不能成功的，每个领导者必须发挥领导力
2.团队迭代周固定，2周
3.增加PI的概念，，叫做一个项目群的增量，通过8-10周，即4-5个迭代产生一个PI
5.如何对齐？所有人同时开始同时结束，每两周结束的时候，要求必须进行一次系统DEMO
6.项目群，增加三个角色：release
train engineer（超级SM）,product
manager（大PO）,SYSTEM ARCH(大架构师)
7.团队及技术敏捷能力强调通过用户故事来描述和交付价值，每两周进行一次系统级别的发布，DEVOPS按需发布的能力，每两周进行一次系统级别的发布，8-10周，系统级方案的交付，你可以在迭代内交付，也可以在多个迭代后交付，交付和迭代没有对应关系，项目群通过特性和收益来进行价值描述和交付。团队项目层讲特性，讲特性需求之外，还要讲技术层的需求，技术架构的储备
敏捷火车的要求
定点发车，你赶上就上，赶不上就不上，你要带着满足安全要求的货物过安检，新增三个角色：RTE（超级SM）,大PO，SYS ARCH
火车的人数：5-12个团队，50-125，人类是从猿转变过来的，但经常产生的人数不超过125人。一个项目群默认是10周，前四周产品的迭代，最后一个迭代是创新迭代，技术债的补偿。
SAFe
如何设定优先级
WSJF基于价值的优先级，加权最短作业优先=CoD/Duration