敏捷规模化框架Scrum@Scale精髓 | 线上分享回放
1. S@S消除了不必要的层级，请问那么员工的reporting line如何设计？是否还需要有people manager或chapter lead？
记得在分享中我们提过，S@S里的三类Scrum团队，层级间的沟通机制都是Scrum of Scrum的方式，由SoSM来进行引导，其中大部分员工在ScrumMaster Cycle里，员工汇报最终汇集到EAT和AP里。因此，这里就不再需要有people manager或chapter lead这种沟通的角色了。
2. 一个SoS中可以有多少个Scrum Team（最少，最多）？
一个SoS里最多是5个Scrum团队, 可以参考分享的PPT里的Example2。
3. 左边的SoS中，对团队的类型有要求么？例如是Feature Team，是否可以有专做support的Kanban Team?
我理解的左边是指ScrumMaster Cycle, 团队的类型框架是没有规定的，但可以确定的是所有的团队都是Scrum团队。
4. 最小官僚提现在哪？
最小的官僚体制，是框架中设计的三个类型的Scrum团队集群(Executive Action Team, Enterprise Meta Scrum, Scrum of Scrums)，因为这些Scrum团队集群之间在设计上仍然保留着层级，所以无可避免了官僚，但这已经是框架设计上的一个平衡。
5. 每个团队的迭代周期必须是一样的吗?
理想状态下，我们希望整个组织的迭代周期是一致的，当特殊情况出现不同步的时候，就是AP的职责范围了。
6. 每个Scrum点，不需要角色要求吗？
不太理解Scrum点是指什么，如果是一个Scrum就是Scrum的三个角色，SM、PO和Team,如果是一个SoS这里会多一个SoSM，S@S就是一个Scrum,没有再多的角色了。
7. 所有團隊都是做同一个产品？
理想状态下我们当然希望所有团队都可以专注在一个产品上，这个是最高效的，但S@S的设计目的是让我们的组织具有最快的响应和适应能力，所以这个取决于你对组织的能力要求。
8. S@S和LeSS的区别和优于LeSS的地方 ?
S@S我个人觉得最大的优点是他的组织结构设计，支持无限的扩展，虽然我们没有这个需求，但在案例分享中的2000人团队已经是一个很好的验证。另外就是S@S的设计是面向整个组织系统的，设计了整个组织的结构，而LeSS并没有涉及这一部分。这个主题我们之前发表过系列文章，请参考公众号洞悉规模化敏捷框架系列文章。
9. 这么多PO CPO CCPO是不是会形成新官僚？
请参考问题4的回应。
10. 因为层级分明，一层层的，所以会形成官僚主义？最小官僚主义怎么理解？
请参考问题4的回应。
11. 5个Scrum — 5个SOS — 5个SOSOS 。。。这个是否也是新的层级体现？整个组织是网状的立体结构么？
这就是我们之前提过的官僚最小化的其中一个体现，Scrum of Scrums团队集群。整个组织是网状的。
12. 如果搭建这样组织结构，产品架构是怎么决定？
这里不太理解产品架构的具体定义，产品级别的工作是以EMS为中心展开的，整个企业的产品架构由EAT/AP和EMS共内协作决定，这两个组织的工作是有交集的，就是框架中两环交集的地方。
13. S@S中产品待办列表也是不管有多少层级都只维护一份吗？
理想状态下，一个企业一份待办列表，每个Scrum团队一个PO，对PO的能力要求十分高！具体高能力PO的企业是最高效的。但实际情况并不是如此，这也是为什么要设计AP给PO做支持工作的原因。PO的能力不足时企业会有多份待办列表，随着PO能力提升，我们的目标是减少待办列表的数量。
14. 一个Scrum master管理几个团队，那是一起参加站会，还是分开参加，如果分开参加，又如何按数据中提现出快速的一层层传递？
数量中的例子是一个ScrumMaster带一个团队，所以会有如此快速的反馈。但实践，一个ScrumMaster可以带2个团队，分开来开站会。这要视乎企业对响应速度和ScrumMaster的利用效率两者的平衡。
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/tech/dev/295351.html