LeSS规则 (2024年11月)

(what changed since previous version)
LeSS规则是LeSS组织设计的定义。它们是我们认为必需的东西。为什么？这在Why LeSS?中进行了解释。

LeSS基础规则

LeSS基础规则应用于2-“8”个团队的产品。

LeSS结构

用真正的团队作为基本模块来构建组织。
每个团队是：1）自管理的、2）跨职能的、3）同在一地的、4）长期的。
团队是以客户为中心的特性团队。
Scrum Master负责一个运转良好的LeSS导入。他们关注于团队、产品负责人、组织和开发实践。一个Scrum Master不只关注一个团队，而是整个组织系统。
Scrum Master是一份专门的全职工作。
一个Scrum Master可以服务1－3个团队。
在LeSS里，管理者是可选的，但是如果存在管理者，他们的角色可能会改变。他们的焦点从管理日常产品工作转向改进产品开发系统的价值交付能力。
管理者的角色是通过实践现场观察、鼓励停下来修复，以及“实验胜于遵从”来改进产品开发系统。
对产品组“一开始”就建立完整的LeSS结构，这对LeSS导入至关重要。
对超越产品组的更大组织，通过现场观察来演进地导入LeSS，从而创建一个以实验和改进为常态的组织。

LeSS产品

对整个可以交付的产品有一个产品负责人和一份产品待办列表。
产品负责人不应独自工作于产品待办列表的梳理；她通过让多个团队直接与客户／用户以及干系人工作来获得支持。
所有的优先级排序都通过产品负责人，但是澄清尽量由团队和客户／用户以及干系人直接进行。
产品的定义应该是在现实的前提下尽量广并且以终端用户／客户为中心。随着时间的推移，产品的定义可能会扩大。我们倾向于更广的定义。
对整个产品有一个所有团队通用的完成的定义。
每个团队可以扩展通用的定义来形成自己团队更为严格的完成的定义。
完美的目标是通过改进完成的定义达到每个迭代（或者更频繁）都产出可交付的产品。

LeSS迭代

有一个产品层面的迭代，而不是每个团队有不同的迭代。每个团队同时开始和结束一个迭代。每个迭代产出一个集成的完整产品。
迭代计划由两部分组成：迭代计划一是所有团队共同的，而迭代计划二通常是各团队分别做。对相关性强的条目安排在一个共享空间内做多团队的迭代计划二。
迭代计划一由产品负责人和所有团队参加。他们一起试探性地选择每个团队将在下一个迭代工作的条目。团队们会识别一起合作的机会，并澄清最后的问题。
每个团队有自己的迭代待办列表。
迭代计划二是让团队决定他们怎么做所选的条目。这通常涉及设计并产生他们的迭代待办列表。
每个团队有自己的每日站会。
跨团队协调由团队决定。倾向于分布式和非正式协调而非集中式协调。强调实时交流和非正式的网络，通过代码交流、跨团队会议、组件导师、旅行者、侦察员和开放空间。
产品待办列表梳理倾向于多团队来做以增加分享学习和对协调机会加以利用。
有一个产品的迭代评审；对所有团队都是共同的。确保合适的干系人能够参加并贡献有效检验和适应所需要的信息。
每个团队有自己的迭代回顾。
在团队回顾之后举行一个整体回顾来讨论跨团队和系统性的问题，并创建改进实验。这个会议由产品负责人、Scrum Master、团队代表和管理者（如果有的话）参加。

LeSS巨型规则

LeSS巨型应用于“8”个以上团队的产品。避免在小型产品组上应用LeSS巨型，因为这会带来更多的开销和局部优化。

如果没有特别指出，所有LeSS基础规则都应用于LeSS巨型。每个需求领域就像是一个基础的LeSS。

LeSS巨型结构

从客户角度强相关的客户需求会以需求领域分组。
每个团队专攻一个需求领域。团队会长期固定于某个领域；但是当其它领域的价值变得更高时，团队可以改变其工作的需求领域。
每个需求领域有一个领域产品负责人。
每个需求领域有“4-8”个团队。避免超出这个范围。
LeSS巨型的导入，包括其结构变化，是以演进增量的方式发生的。
每天都记得：LeSS巨型的导入会需要很多个月或年、无限的耐心、还有幽默感。

LeSS巨型产品

有一个（整体）产品负责人来负责产品层面的优先级排序和决定哪些团队工作在哪个领域。她和领域产品负责人紧密工作。
领域产品负责人对他们的团队来说就是产品负责人。
有一份产品待办列表；里面的每个条目只属于一个需求领域。
每个需求领域有一份领域产品待办列表。这个列表概念上来说是整份产品待办列表上一个更细粒度的视图。

LeSS巨型迭代

有一个产品层面的迭代，而不是针对需求领域有不同的迭代。每个迭代结束都有一个集成的整体产品。
产品负责人和领域产品负责人会频繁同步。在迭代计划前他们确保团队都将工作在最有价值的条目上。在迭代评审后，他们在产品层面做出适应。