浅谈LeSS与SAFe的区别（三）

本文继续介绍LeSS与SAFe的不同点。

区别四：迭代节奏

LeSS 就是大规模的Scrum，所有团队/每个领域的所有团队都采用相同节奏的敏捷实践，它沿用Scrum的迭代的概念。

SAFe 整体也是Scrum 实践的扩展，但是敏捷团队可以选用Scrum 或看板方法。同一发布火车/价值流/投资组合的所有的敏捷团队才使用相同的迭代节奏。SAFe 增加了项目群增量PI，默认包含5个迭代，而且最后一个迭代是创新与计划迭代。SAFe的迭代节奏分一个大节奏PI和小迭代两种。

区别五：组件团队与特性团队

Scrum的一个始终不变的中心主题是不懈地关注交付客户价值。工作的顺序是基于为客户提供价值，而不是基于开发的便利性。LeSS大部分团队是以客户为中心的特性团队。

图片来源：《大规模Scrum：大规模敏捷组织的设计》

SAFe中特性团队和组建团队都是合法存在的，鼓励特性团队的存在，但没有强调这个比例。

区别六：产品负责人和产品经理的定义

小型LeSS中有且仅有一个产品负责人，负责2-8个敏捷团队，或者巨型LeSS中每个领域有一个产品负责人。产品负责人常常需要其他产品经理的支持。产品经理没有明确统一的归属。“产品负责人团队”中没有分析师、需求说明编写人员、UI/UX设计人员或架构师。这些角色会导致现状问题和新标签旧结构问题。这些专家们应该加入常规特性团队。

LeSS中产品负责人的责任：所有优先级顺序都由产品负责人确定，但优先级的澄清工作应尽可能直接在团队、客户/用户和其他利益相关者之间进行。

LeSS中产品负责人应予以关注的：1）方向和优先级——决定下一步的发展方向2）愿景、演进和采用技术——着眼于长远3）人际关系和政治——让每个人都快乐（足够地）4）判断和预测——评估市场和竞争对手。以下些东西最好委托给团队1）澄清——探索条目的详细含义2）管理工作——报告和跟踪指标3）跨部门协调——联系生产、销售等4）了解市场、技术和竞争对手。

LeSS中产品负责人不应承担以下任务：1）管理依赖项或在团队之间做协调工作2）预测和规划团队的工作3）质疑估算数字4）甚至，在人与人之间传递信息。

LeSS中一个完整的可交付产品对应一个产品负责人和一个产品待办事项列表。每个团队一个单独的sprint 待办事项列表，所有的团队共用一个产品待办事项列表。在巨型LeSS中，也是有一个总的产品待办事项列表，和多个领域待办事项列表。LeSS在产品待办事项列表梳理过程中，让团队自领任务自己选择做哪部分条目，鼓励团队尝试不同的需求，不限制在自己熟悉的领域。

SAFe中每个敏捷团队一个产品负责人，产品负责人（Product Owner, PO）是团队的一员。在项目群层，产品经理是三驾马车之一，可看成是客户需求在组织内部的代言人，项目群待办事项列表的负责人，每个产品经理通常可以支持最多4个产品负责人，每个产品负责人最多可以负责1～2个敏捷团队的待办事项列表。

图PM/PO的人员比例模型

图片来源：《SAFe4.0 参考指南》

在SAFe中每个团队一个产品待办事项列表，项目群层有项目群层的待办事项列表，价值流层有价值流待办事项列表，投资组合层有投资组合待办事项列表。

区别七：关于产品的定义

LeSS通过广泛的产品定义，降低组织的复杂性，消除了不必要的、复杂的组织结构，并且是以更简单的方式解决了这些问题。广泛的产品定义是首要选择。同时也通过他们共性和结构来约束产品的定义。

SAFe中没有特别强调产品的定义，同时包含了项目、产品、解决方案等的概念。

区别八：Scrum of Scrum

LeSS：Scrum of Scrum是正式的集中式会议，因此不建议设置。但是，大多数刚开始采用大规模方法的团队都会觉得他们必须有Scrum of Scrum，因为他们对大规模方法可能还存在一些错误的理解，所以尽管这并不真正有用，他们也依旧想继续使用Scrum of Scrum。

SAFe：发布火车工程师（RTE）通常每周（或根据需要可以更加频繁）组织Scrum of Scrums（SoS）会议，来持续协调处理敏捷发布火车上的依赖关系，并将进展和障碍以可视化的方式呈现出来。该会议的时间一般不超过30分钟，随后可以召开“跟进会”来解决发现的问题。

区别九：软件工具的采用

LeSS拒绝Sprint待办事项列表软件工具：Sprint待办事项列表用于团队管理自己，它不是为产品负责人或外部跟踪而设，虽然数字工具能用于产品待办事项列表，但对于Sprint待办事项列表，LeSS建议不要使用任何软件工具来管理；只需使用实物可视化管理方法即可，例如墙上卡片。原因如下：

1）增加与团队的交互，增加信息交流——墙上卡片的方法鼓励团队行为，而计算机卡片的方法鼓励个人行为。此外，简单性、易用性和易变更性，以及全景可视化能够使团队积极主动地处理他们贴在墙上的Sprint待办事项列表中的信息。当团队使用软件工具时，实践中我们看到的则是相反的情况。

2）增加SP2期间的交互——我们观察到计算机会使SP2期间的协作趋向终止。

3）防止跟踪和微观管理——如果团队将Sprint待办事项列表信息放在软件工具中，会让经理们或者产品负责人习惯性的跟踪团队、比较团队，并进行微观管理。

SAFe中建议同时使用物理看板和电子看板两套，电子看板可以记录过程数据，以便度量。

以上内容参考自：

1《大规模Scrum：大规模敏捷组织的设计》作者：克雷格·拉尔曼巴斯·沃代

2https://www.scaledagileframework.com/#，和《SAFe4.0 参考指南》