详解规模化敏捷框架 Scrum@Scale 、LeSS 、SAFe
2022-12-09
来源：ShineScrum捷行
实践者来说Scrum@Scale和LeSS是相对容易接受，而SAFe是管理者相对容易接受，观点与角度不一样。
2.8DevOps
DevOps在企业级敏捷中已经是一个不可或缺的基础能力，企业能够做到功能按需发布、快速获取用户反馈、持续改进。DevOps从SAFe 4.5版本正式加入，并且有它自己的一个DevOps认证SDP。而LeSS和Scrum@Scale并没在框架中提及，DevOps应该是由Team去肩负起来，这种原则和思维方式已经融入到框架之中，所以在框架中并没有明确声明。
2.9Product Owner
Product Owner在每一个框架中都是关键人物。SAFe中有它领域内的认证POPM。LeSS与Scrum@Scale并有没额外的PO认证，但后者对PO的能力要求并不低于前者。LeSS一个PO要支持50人的团队，大概7个Scrum团队，对PO的能力要求极高。在CLP的课程中会有一个篇幅去讲产品的定义，笔者清楚记得当时问了讲师一个问题。为什么要讲产品的定义？这个系统变量也是通过系统思考推导出来的，因为PO对产品定义不清晰，会影响整个团队的目标实现。
Scrum@Scale的Meta Scrum里PO更是需要有导引能力，并且与SM互补和有交集，扩展了PO的职责，识别价值流，引导会议等。通常我们衡量一位PO的指标都是直接与他负责的产品挂勾，相信每一个人都有追求卓越的心，但我们往往忽视了PO们所处系统的环境，环境影响了心智模式。我们是否为PO提供了可持续发展的空间和环境。
2.10沟通饱和度(Communication Saturation)
上表列出三个框架各自有特色的设计和活动，它们之间似乎都没有很大的关系。但笔者发现它们背后要平衡的是一个指标，就是沟通饱和度。如果我们从沟通饱和度的维度来看这些设计，就会发现这些设计和活动之前的关系。沟通是团队协作过程中最大的成本之一。Scrum设计之初，Jeff在他的书中（《敏捷革命》/《The Art of Doing Twice the Work in Half the Time》）第三章团队规模一节，就提及设计Scrum团队人数时考虑的就是这个指标。另外，在学习Scrum@Scale的Slide Deck时候也发现这个线索暗中贯穿整个框架。
( 图11：沟通饱和角色数量关系图)
( 图12：Jeff Sutherland的一条推文）
( 图13：Software Engineering Institute的论文)
三个框架都以不同的形式去找到团队沟通饱和度的平衡点，如果我们明白框架背后的逻辑那么我们就可以去设计我们自己的机制，团队沟通饱和度越高那么团队共享的知识就越多，需求就越明确。但要达到这种状态是需要成本的，工作时间不可能全部用于沟通，即我们的沟通饱和度不可能达到100%。假若我们想要沟通饱和度达到50%，那么这个机制
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
