LeSS规则 (2016年四月)

LeSS规则是LeSS框架的定义。这些是我们认为导入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产品

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

LeSS Sprint

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

LeSS巨型框架规则

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

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

LeSS巨型结构

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

LeSS巨型产品

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

LeSS巨型Sprint

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