规模化敏捷SAFe和LeSS的同与不同

2、两者的核心基础理论很多相似之处，比如都强调精益开发、系统思考、质量内建、透明、排队论等。

3、两者都是以Scrum作为基础，SAFe的团队层其实就是按照Scrum去运行的；而LeSS更是直接在原则中宣称“规模化的Scrum也是Scrum”。

4、两者都强调多个团队的开发进度都需要协调一致，也就是说无论SAFe还是LeSS，对于多团队之间的Sprint必须对齐，要有相同的开始和结束时间。

5、两者都强调要透明，信息要所有人都清晰。比如两者其实都有一个所有团队全员参加的计划会议：对于SAFe来说是PI计划会；而对于LeSS来说则是LeSS的Sprint计划一。其实两者目标都是让所有人在相同的环境下理解特性和故事。除此之外，对于SAFe的系统演示、LeSS的多团队PBR等都在强调信息需要透明需要被所有人掌握。

6、两者都需要把多团队的交付物整合成统一的潜在可交付产品增量PSPI，其中LeSS是明确指出只有一个PSPI；而SAFe虽然没有明确规定，但是其系统演示中是要求所有的交付物合在一起的。

1、两者解决大规模扩展问题的思路截然不同

SAFe是通过增加层级和角色的方式解决扩展问题，比如团队层是按Scrum Team的粒度来，多个团队的管理则在上面加一层变成项目群层，而多个项目群的管理再往上加一层又变成价值流层。以此类推，因此衍生了新的流程和角色；而LeSS强调的是“LeSS is more”，不主张随便增加角色和流程。LeSS觉得请神容易送神难，加了角色以后想要减就很难了。所以LeSS会尽可能利用现有Scrum的框架去优化，而不是往上增加太多新的流程。

2、具体实施方式不同

对于SAFe来说，其实施的两个要点：一是在不同的Scrum团队之上增加一个版本发布火车ART的概念，这个ART就把多个scrum团队组成一个大团队；二是通过一个项目群增量PI的概念把多个Sprint规定成一个时间盒，一般为8-12周，也就是4-6个sprint。当然刚才也说到，每个团队的Sprint开始和结束时间还是要对齐的。通过这两个要点把多个scrum team的运作组织起来；而对于LeSS来说，其基础还是依据Scrum流程，它强调不管几个scrum team，都只有1个Product Owner、1份product backlog和1个潜在可发布产品PSPI。

也就是说LeSS控制一头一尾，首先一头指的是产品待办事项列表必须只有一个（即使是Huge Less所谓的需求领域待办事项也只是产品待办事项列表的一个视图而已，并不是真正独立的一份待办事项），因为LeSS觉得如果每个团队都有自己的product backlog的话，大家都会陷入在自己的高价值需求优先级中而失去了全局性、系统性的思考和分析，所以最好只有一份Product Backlog，而且只有一个产品Prodcut Owner，由产品Product Owner说了算，这样避免了混乱；一尾是指潜在可交付产品增量PSPI必须只有一个，这就要求多个scrum团队最终需要把代码合并生成一个可交付件，也体现了集中式代码管理机制的要求。然后LeSS在中间可以包含多个Scrum团队，每个Scrum团队都有单独的Sprint Backlog，不过同样多团队的Sprint开始和结束时间都必须一致。

3、角色的不同

对于SAFe来说，会增加很多新的角色，比如项目群层有发布火车工程师RTE、系统架构师/工程师、系统团队（负责自动化测试、CI/CD、端到端集成测试）等。比如价值流层还会增加解决方案管理者、解决方案架构师、价值流工程师VSE等。而对于LeSS来说，只在Huge LeSS中增加一个新的角色叫领域产品负责人APO，可见LeSS是真的很忌讳随便增加角色。

4、涉及范围不同

SAFe不仅要解决多团队之间联合开发的问题，还从更高的组织层面去思考投资组合和战略层面的问题，也包括财务如何支持的问题；而LeSS更多还是考虑如何做好多团队之间联合开发的问题，并没有涉及太多战略层面的问题。

5、具体细节不同

比如SAFe会有一个创新与计划（Innovation and Planning， IP）的迭代Sprint，为估算提供一个保护带（缓冲时间），为PI计划、创新、持续教育和基础设施构建等工作提供专属时间，这个是LeSS没有；而LeSS有多团队设计研讨会活动，这个SAFe没有太明确的提到。当然还有其它细节就不一而足了。