敏捷扩展（Scrum Scaling）和敏捷扩展（Scrum Extension）是两个完全不同的概念，不过由于其中文翻译的雷同会让人造成困扰。当然我们在这里主要讨论的是前者。所以为了区分前两者，请允许我将前者改为，规模化Scrum（Scrum Scaling）且我会在文章的最后说点关于敏捷扩展（Scrum Extension）的小故事。
好了，话归正题我来为大家简述下，目前市面上我所知的2种规模化Scrum的方法学：
1、LeSS （官网）
LeSS架构如下图所示：
LeSS主要用于单个产品的多团队Scrum开发所用，真实的保持了Scrum生态。可以说是非常像Scrum的大型扩展Scrum框架，具体可参考上图，与Scrum大致相同：
小型LeSS框架一般包含，1个产品负责人、2到8个团队、每1-3个团队一个Scrum Master。而我们这里所说到团队在LeSS中都是特性团队，真正到具有跨职能和跨组件的能交付端到端价值的全面型团队。对于每个团队，都有一个共同的完成定义，一个潜在的可交付产品增量、一个产品代办事项列表和一个单独的冲刺代办事项列表。整个产品具有一个共同的冲刺周期，且在每个团队完成一个共同的潜在可交付产品增量后结束。
相较于单个Scrum团队，LeSS其具有一些扩展的规则和指南来指导整个团队进行，可能对既有的Scrum事件做一定的调整以适应团队的运行。比如对于大规模团队的冲刺计划会议的实践，LeSS中将其做了一定的调整。具体如下图所示：
又如，对于每日站会。除了常规参会人员之外，还会又其它团队的侦察员来观察。同时LeSS也会增加多团队间交互的多团队每日站会等等。不仅如此，其还提供来足够多的复杂度用以支持扩展比如LeSS的另一种结构称之为巨型LeSS。其结构如下图所示：
标准的LeSS团队框架，适应小于8个Scrum团队使用。而巨型LeSS框架，适用于8个以上的团队。而其中与小型LeSS所不同的是，其增加了产品负责人组（PO Team）由主要产品负责人（CPO）来带领领域产品负责人（APO）。
由于篇幅有限，很多东西都无法尽数。如果各位感兴趣可以去阅读它的创始人克雷格·拉尔曼（Craig Larman），[荷] 巴斯·沃代（Bas Vodde）所写的书籍《大规模Scrum：大规模敏捷组织的设计》或者参加线下的培训。
2、Scrum @ Scale 简称 S@S （官网）
S@S是JJ Surland博士所创造的另一种规模化Scrum的方式，其框架如下图所示：
其主要分为两个循环（Cycle），一个是Scrum Master循环（Scrum Master Cycle），另一个是产品负责人循环（Prod Owner Cycle）。而相对应的有两个团队，一个是吃团队（Executive Action Team - EAT）和快递团队（Executive MetaScrum - EMS）。前者负责如何实现（How），后者负责实现什么（What）。
而对于每个循环都有很多其独特的目标，对于吃团队（EAT）其包括持续改进、障碍移除、跨团队合作、交付；对于产品负责人团队（EMS）其包括产品愿景建立、产品代办列表排序、产品代办列表澄清、发布计划；对于两者共同的目标有：产品发布和反馈、团队特有流程（此流程并不一定指Scrum）并通过度量和透明化来做为考量数据。
虽然也是追求价值最大化的扩展Scrum，其却具有一些特殊的事件例如：Scrum of Scrum简称SoS （和以前的Scrum of Scrum是不同的这个不是单个会议）和特殊的角色SoSM，CPO等等。
以上两种是目前我所知的规模化Scrum的方法论，其最大的特点都是尽量保持了Scrum的生态的前提下，最大程度的做一些水平的扩展而非垂直扩展。
不过即使方法论再好，其实我个人觉得规模化Scrum有时并不见得是个好主意，因为
* 好的产品和创意多来自于小团队。
* 不管什么方法学团队变多其开销和沟通成本必然会增高，这会导致全⽣命周期的总成本（TCO）变高，例如依赖、集成等⻛险容易后移，变更成本增加等等。
* 局部的优化较为容易，但是全局的优化就非常的困难。这也是为什么很多公司在导入敏捷的时侯，样板项目很容易成功，但是等到规模化的时侯却屡屡失败。
* 敏捷是个试验性的过程，人数的增加会阻碍快速反馈。
正文结束
好了说到这里，让我们回到开头提到的敏捷扩展（Scrum Extension）上去吧。
话说2011年的时候，当时Scrum.org宣布：对于Ken Schwaber和Jeff Sutherland最早制定的Scrum流程，他们会接受具备上下文的修改建议。却遭到了很多敏捷大咖的反对，比如Mark Levison，Ron Jeffries等。虽然观点不一，可是大家都觉得Scrum的框架之美在于它的不完备和缺陷。最后包括Ken Schwaber本人在内，也对此做了回应。其结果就是Scrum.org最后放弃了对此的修改Scrum流程的计划。不过其还是会在适当的地方保留那些有用的敏捷扩展。
网友评论