LeSS 介绍

构造[设计]的方法有两种：

一种方式是使其变得如此简单，以至于显然没有缺陷，

另一种方法是使它变得如此复杂，以至于没有明显的缺陷。

C.A.R. Hoare

单一团队Scrum

Scrum是一个经验过程控制开发框架，跨职能的自我管理团队以迭代的增量方式开发产品。每个带有时间限制的Sprint 都会交付潜在可交付的产品增量。单个产品负责人负责最大化产品价值，对产品待办事项中的项目进行优先级排序，并基于不断的反馈和学习来自适应地确定每个Sprint的目标。一个小团队负责实现Sprint目标；没有限制的单一专业角色。Scrum Master教授团队为何用Scrum以及如何从中获取价值，指导产品负责人，团队和组织应用它，并充当镜像。Scrum中没有项目经理或团队负责人。

经验性的过程控制需要透明性，这种透明性来自于短周期开发和可交付产品增量的审查。它强调对产品及其创建方式的不断学习，检查和调整。这些是基于以下的理解，在开发中，对于详细而公式化的流程配方而言，事情太复杂，太动态了，从而阻碍了提问，参与和改进。

在《Scrum指南》和《Scrum Primer》中，强调的是一个团队。重点不是很多团队一起工作。这自然导致人们考虑大规模 Scrum。

LeSS

LeSS是Scrum -Large-Scale Scrum（LeSS）并不是新的和改进的Scrum。而且这不是底层每个团队的Scrum和在上层运行的一些东西。而是要弄清楚如何尽可能简单地在大规模环境中应用Scrum的原理，目的，元素以及保质保量。像Scrum和其他真正敏捷的框架一样，LeSS是具有高影响力的“刚好够用的方法论”。

Scaled Scrum不是一个仅在团队级别Scrum的特殊扩展框架。
真正的 Scaled Scrum是Scrum的扩展。

…应用到许多团队 -跨职能，跨组件，全栈的功能团队，由3–9名学习型人员组成，从UX到代码到视频，这些都可以完成，并创建完成的任务和可交付的产品。

…一起工作 -团队之所以一起工作是因为他们有一个共同的目标，即在共同的Sprint结束时交付一个共同的可交付产品，并且每个团队都在乎这一点，因为他们是负责整个而非部分的功能团队。

…关于一个产品 – 什么产品？实际客户使用的广泛，完整的端到端以客户为中心的解决方案。它不是组件，平台，功能层或库。

背景

在2002年，当Caige撰写Agile & Iterative Development时，很多人认为敏捷开发仅使用于小型团队。但是当我们两（Caige and Bas)都对将Scrum应用于大型，多站点和离岸开发感兴趣并提出了越来越多的要求。因此，自2005年以来，我们一直与客户合作以扩展Scrum。如今，两个LeSS框架（Smaller LeSS 和 LeSS Huge）已在全球不同领域的大集团中采用：

• 电信设备—爱立信和诺基亚网络
• 投资和零售银行—UBS瑞银
• 交易系统— ION Trading
• 营销平台和品牌分析— Vendasta
• 视频会议—思科
• 在线游戏（投注）— bwin.party
• 离岸外包— Valtech印度

从大的角度来看，典型的LeSS 应用案例是什么？可能有五个团队分布在一到两个地点。我们参与了规模达数百人的应用，以及涉及多达一千多人的LeSS Huge案例，涉及许多的开发中心，数以千万计的C ++代码以及自定义硬件。

实验，指南，规则，原则

LeSS的前两本书强调：产品开发中没有最佳实践之类的东西。在特定的情况下，只有适当的做法。

做法视情况而定；轻描淡写地声称他们是“最好的”，从而使他们脱离了动机和背景。它们成为仪式。推行所谓的最佳实践会扼杀学习，质疑，参与和持续改进的文化。人们为什么要挑战最好？

因此，早期的LeSS书籍分享了我们和我们的客户尝试过的实验，并且我们鼓励并鼓励了这种思维方式。但是随着时间的流逝，我们发现只有实验的思维方式存在两个问题：

• 新手小组做出不利于自己的非熟练决策，无目的应用LeSS，存在明显的问题；例如，小组创建了需求区域，每个区域有一个团队。
• 新手小组问：“我们从哪里开始？最重要的是什么？”可以理解，他们看不到关键的基础知识。

在此基础上的反馈，我们做了反思，并回到了Shu-Ha-Ri的学习模式：Shu -遵循规则学习基础知识。Ha -打破规则和发现内容。Ri-掌握并找到属于自己的方式。在Shu级LeSS的采用中，对于勉强足以启动经验过程控制和整个产品重点的框架，有一些规则。这些规则定义了两个LeSS框架。

总结并基于这些观点，LeSS包括：

• 规则 – 入门和构成基础的一些规则。它们定义了LeSS框架的关键要素，这些要素应当支持经验过程控制和整个产品重点。例如，对每个Sprint进行一次总体回顾。
• 指南 -一组适度的指南，可有效采用规则并进行部分实验；根据LeSS的多年经验值得尝试。指南包含提示。通常是有帮助的，是需要不断改进的领域；例如三个采纳原则。
• 实验-许多实验都是视场景而论甚至可能都不值得尝试；
• 原则（从本质上讲，是一组原则），这些原则是从应用LeSS的经验中提取的，这些原则为规则，指南和实验提供了指导；例如，关注整个产品。

LeSS 完整的示意图：

LeSS 原则

LeSS的规则定义了LeSS的框架。但是规则是极简的，并不能回答如何在你特定的环境中应用LeSS。LeSS的原则提供了做出这些决定的依据。

Large-Scale Scrum还是Scrum-它不是新的和改进的Scrum。相反，LeSS旨在尽可能简单地弄清楚如何在大规模环境中应用Scrum的原理，规则，元素和目的。

透明度-基于切实可行的项目，短周期，需要共同努力，共同的定义以及消除工作场所的恐惧感。

More with less —我们不想要更多的角色，因为更多的角色导致对团队的责任减少。我们不希望有更多工件，因为更多工件会导致团队与客户之间的距离更大。我们不希望有更多的流程，因为这会导致较少的学习和团队对流程的所有权。取而代之的是，我们希望拥有更少的角色，从而拥有更多负责任的团队；我们希望拥有更多以客户为中心的团队，通过减少工件，来构建有用的产品；我们希望拥有更多的团队对流程的拥有权，并通过定义更少的流程来进行更有意义的工作。我们需要通过减少来获取更多。

关注整个产品 -一个产品待办事项列表，一个产品负责人，一个可交付产品，一个Sprint（无论3个或33个团队）。客户需要紧密结合的产品中有价值的功能，而不是单独模块中的技术组件。

以客户为中心—重点学习并解决客户的实际问题。识别付费客户眼中的价值和浪费。从他们的角度减少等待时间。增加并加强与真实客户的反馈循环。每个人都知道他们今天的工作与客户的关系以及如何给客户带来价值。

持续改进追求完美，这是一个完美的目标：自始至终，尽可能低成本的，无缺陷的方式创造和交付产品，让客户感到满意，改善环境并改善生活。为实现该目标不断保持谦逊和尝试根本的改进。

精益思维–建立一个组织系统，其基础是视经理为教师，他们应用和教授精益思想，设法改进，Stop and Fix，并实践Go See。增添尊重人和持续挑战现状改进思想这两个支柱。所有人都朝着完美的目标迈进。

系统思考 -查看，理解和优化整个系统（而非部分），并使用系统建模来探索系统动态。避免关注个人和单一团队效率或者产出的局部优化。客户关心从概念到现金的整个周期和流程，而不是单个步骤，并且本地优化几乎总是对整体进行局部优化。

经验过程控制-不断检查和调整产品，过程，行为，组织设计和实践，以适应当下情况的方式进行演进。做到这一点，而不是遵循一套规定的所谓最佳做法，而这些最佳做法常常会忽略当下环境，产生仪式性的追随者，阻碍学习和变革并压制人们的参与和主人翁意识。

排队论 -了解研发领域中队列系统如何运行，并将这些见解应用于管理队列大小，在制品限制，多任务处理，工作包和变化。

两个框架： LeSS和 LeSS Huge

Large-Scale Scrum 有两个框架：

• LeSS。 2-8个团队
• LeSS Huge。8个以上团队

LeSS 一词有多个含义，它既表示通常意义下的Large-Scale Scrum，又指smaller LeSS 框架（2-8个团队）。

神奇的数字8

实际上，8并不是一个神奇的数字，如果你的团队成功的将Smaller LeSS框架应用到8个团队以上，那就太好了。但是我们还没有看到…。这只是一个上限的经验观察。并且在一些案例中，例如不同复杂的目标，没有经验的多语种跨地域团队，很可能少于8个团队。

无论如何，在某些时候，（1）单个产品负责人不能再掌握整个产品的概述；（2）产品负责人无法平衡外部和内部关注点；（3）产品待办事项列表是如此之大，以至于一个人很难与之共事。

当小组达到临界点时，可能是时候从Smaller LeSS框架更改为LeSS Huge。另一方面，我们建议先尝试变得更好，更小和更简单，然后再变得更大。

框架通则

LeSS和LeSS Huge框架具有共同的要素：

• 一位产品负责人和一位产品待办列表
• 在所有团队中有一个共同的Sprint
• 一个潜在可交付的产品增量