规模化敏捷框架之LeSS

Scrum 是目前比较流行的敏捷框架，Scrum 敏捷开发团队由产品负责人（Product Owner）、敏捷教练（Scrum Master）、软件开发人员和其他合作人员组成。团队在这个指导框架下协同工作、开发、创造和交付有价值的产品来解决复杂的问题。但如果要在公司内扩展 Scrum 实践，就必须通过 LeSS 等敏捷框架（Large-Scale Scrum，LeSS）来解决规模扩展的问题。

一、什么是 LeSS 框架

LeSS 是一个用于将 Scrum 扩展到在共同服务同一个产品的多个团队的框架。它是以单个 Scrum 团队为基础，并且遵循Ken Schwaber和Jeff Sutherland在《Scrum指南》的定义，但却有效的扩展到多个团队。

《Large-Scale Scrum： More with LeSS》一书的作者浓缩了他们多年的经验将 LeSS 改善，将其定义为一个降低敏捷规模化复杂性和浪费的有价值框架。LeSS 框架旨在通过重新梳理规则和实践，尽可能简单地将 Scrum 原则和价值观应用在大规模企业环境中。有些人将 LeSS 的简单解读为“勉强能用”，但这并不意味着该方法不行。

二、LeSS 框架结构

LeSS 敏捷框架理论是通过600多个实践案例总结得出，其中涉及大规模团队的敏捷实践，打破了当时人们对敏捷开发只适合小型、本地协作团队的局限性观点。LeSS 框架的实践、指南、和原则为了满足大规模团队的敏捷需求提供了指导。并且，随着 LeSS 规则的完善，它在定义和如何执行落方面也越来越清晰。

1.LeSS 框架的原则

LeSS 敏捷框架有十项原则，旨在帮助整个企业更好的规模化应用Scrum的价值、原则和达成目标。它有助于创建更负责任、更加以客户为中心、协作更密切的团队。它让团队专注于学习、协作无间、秉持以客户为中心的价值观，从而提升团队的竞争力和市场响应能力。以下是 LeSS 敏捷框架的十大原则：

大规模 Scrum 仍是 Scrum，遵从Scrum原则和价值观
注重流程管理和经验积累（Empirical Process Control）
重视团队之间的透明度（Transparency）
强调简单，事半功倍（More with Less）
聚焦整体产品目标（Whole Product Focus）
以客户为中心（Customer Centric）
持续改进以求完美（Continuous Improvementtowards Perfection）
强调系统思维（System Thinking）
精益思想（Lean thinking）
强调优先级（Queue Theory）

2.LeSS 框架的角色

LeSS提供两种配置：小型的 LeSS 实践由2到8个团队组成（10-50人），他们服务于同一个产品的开发。大型的LeSS 实践由8个以上的团队组成（50-6000+人）。

大型的 LeSS 实践也是基于小型的LeSS实践发展，大型 LeSS 实践会增设两个或多个区域产品负责人（Product Owner），以及一些额外的工件和调整。我们建议从小型 LeSS 实践开始尝试，并逐步的积累经验、改进，然后再逐步拓展为大型 LeSS 实践。

这里推荐两种落地方式：

在某段时间内基于单个大型产品的某个需求领域展开；
或者是逐步扩大工作范围、完成的定义和产品的定义，将多个团队囊括其中；

这可以在将 LeSS 扩展到整个组织之前，让团队适应 LeSS 框架，降低负面影响，并获得管理层支持。

3.LeSS 指南

LeSS 指南是由作者 Craig Larman 和 Bas Vodde 基于 LeSS 实验创建的，虽然它们在某种程度上是他们的第三本书《大规模Scrum：更多LeSS 》的意外副产品，但该指南对于理解和采用 LeSS 的方法、定义相关人员的角色和职责、如何在团队之间进行协调和整合等等非常有帮助。你可以根据需要去引入指南中的原则，他们并非都是必须选项。（相关书籍推荐：《Scaling Lean & Agile Development》、《Practices for Scaling Lean & Agile Development》）

4.LeSS中的角色和规划

基础的 LeSS 框架基于 Scrum 框架设立，包括关键的 Scrum 角色：负责产品规划和迭代方向的产品负责人、负责产品迭代交付的研发团队，以及指导团队不断精进的 Scrum Master。LeSS 框架对角色的职能范围进行了拓展，产品经理相关角色需要帮助多个团队去持续改进和解决进度障碍。

在大型LeSS实践框架中，多个单产品/某个领域的产品负责人和一个全局产品负责人组成了产品负责人团队。单产品负责人工作的范围有限且领域更聚焦，遵循以客户为中心原则。

相对于 Scrum 框架，LeSS 框架在产品待办列表会议（PBR）这一实践上进行了扩展和补充。产品待办列表细化会议（PBR）PBR会议通过一组并行的 LeSS 迭代执行，将迭代计划扩展到重点领域。在每个迭代（sprint）中都需要持续开展这些会议，以了解、讨论和优化项目，为未来的迭代做准备。

PBR 会议的主要活动是：

1）分解产品大项目；

2）澄清要做的产品待办事项；

3）评估任务的故事点、风险、依赖性和价值。

和 Scrum 敏捷开发一样，除了迭代计划会外，LeSS 框架中的迭代演示和回顾也是审查团队交付内容以及复盘改进的重要会议，同时也是团队展示提供客户价值的机会，各团队将和其产品负责人、用户、客户及利益相关者同时在各自会议分别演示和讨论他们可交付的产品增量。

最后，在迭代结束时，首先由每个团队召开自己的团队回顾会议，之后再进行全体回顾会议，由产品负责人、所有的 Scrum Master、各团队代表和管理者参加。

三、LeSS 与其他框架以及Scrum框架有什么不同？

LeSS 框架汲取了其他敏捷框架的灵感，包括五大方面：有来自敏捷宣言及其12项原则的灵感，有迭代的节奏、有整个组织的同步、精益开发实践以及DevOps， CI/CD 和测试驱动开发（TDD），此外还有一些其他特点。

1.LeSS 框架和 Scrum框架的区别

我们经常看到“ LeSS 和 Scrum 哪个好？”的问题，但其实两者没有对比的意义。LeSS 不是 Scrum 的更好版本，两者没有谁更好一说。因为 LeSS 是基于 Scrum 的扩展，以支持在更大规模的团队中使用。

小型 LeSS 和单个 Scrum 团队的流程很相似，在 LeSS 中，有一个产品待办列表、一个产品所有者和完成定义。虽然由多个团队组成，但所有团队都会按照 Scrum 流程一样工作，在每次迭代结束时交付工作。虽然由一个产品所有者负责一个产品待办列表，但这些工作将分配给多个团队完成。特别是在大型 LeSS 框架中，产品所有者职责范围会扩大到多团队和多个产品模块。因此，产品所有者需要推动产品待办列表细化会议，协调所有团队的工作交付。

此外，在 LeSS 中，迭代计划会分为两部分：

1）多团队迭代计划会：所有团队负责人参加和分配产品工作；

2）单个团队迭代计划会：安排要交付的工作，同时安排与其他团队合作沟通。

除了计划会，其他如每日站会和回顾会议，在 LeSS 框架中都有细微差别。

2.LeSS 框架与 SAFe 框架的区别

除了 LeSS 框架，其他大规模敏捷框架如 Scrum of Scrums 或 Scrum@Scale 也在大型软件开发团队中越来越受欢迎，其中一个先进的理论框架是 Scalized Agile Framework®（SAFe）。

LeSS 和 SAFe 之间有很多相似之处。例如，两者都基于 Scrum 扩展，纳入了精益思维、持续改进和以客户为中心等原则。但两者不同之处在于，LeSS 专注于通过简化组织结构来保持灵活性和适应性；而 SAFe 需要增加其他角色：发布火车工程师（RTE）、解决方案火车工程师（STE）和产品管理者。此外 SAFe 还增加了一些新流程、新工件和新组织。对比之下，在大多情况下 LeSS 没有 SAFe 框架那么复杂。