大规模敏捷-LeSS

Large-Scale Scrum，LeSS

官网详情Overview - Large Scale Scrum (LeSS) https://less.works/zh-CN/less/homepage

LeSS的核心依然是采用Scrum，在尽量不添加角色的前提下，考虑在一个产品、一个产品待办列表、一个产品负责人下，多团队如何进行迭代。大规模Scrum包含两个框架，一个是小型LeSS（支持2～8个团队，8～81人），一个是巨型LeSS（支持8个以上团队）。

十个准则：

聚焦完整产品（Whole Product Focus）——一个产品待办事项列表、一个产品负责人、一个可交付产品、一个迭代，无论是3个团队还是33个团队。

以用户为中心（Customer Centric）——识别付费用户眼中的价值和白费，从他们的角度减少周期时间，添加与真实用户的反馈回路。每个人都理解他们今天的工作与付费用户的关系。

大规模Scrum仍是Scrum（Large-Scale Scrum is Scrum）——LeSS是纯粹的Scrum，Scrum有什么，LeSS就有什么。

透明度（Transparency）——基于客观的、有形的“完成”条目、短周期、协同工作、共同定义，以及对工作场所恐惧的消除等，使工作进展、风险、问题等变得更加透明。

经验过程控制（Empirical Process Control）——持续检查和调整产品、过程、行为、组织设计和实践。

持续改进以求完美（Continuous Improvement towardsPerfection）——为“完美”目标做无尽的谦虚和激进的改进实验。

精益思想（Lean thinking）——精益思想屋的基础是管理者作为老师，来应用和教授精益思想及管理改进；支柱是尊重人和持续挑战现状来改进的心态；屋顶是精益思想的目标，即朝着“完美”目标前进。

以少为多（More with Less）——更少的流程，团队会有更多的学习；更少的白费和开销，团队可以产出更多的价值；更少的角色、工件、特定部门，团队会更自主、更负责任、具备远大目标，以及可以离用户更近。

排队论（Queue Theory）——在动态变化环境中，小批量规模、短队列及限制在制品，带来较短周期时间（快速交付价值），以及减少变异性。

系统思考（System Thinking）——观察、了解和优化整个系统而不是局部优化，并使用系统建模来探究系统的动态。避免将重点放在个人和单个团队的效率或者生产力上。用户关心的是整体上从概念到盈利的周期时间，而不是单个步骤，局部优化一个部分并不肯定能对整体产生积极影响。

小型LeSS的3个角色

（1）只有一个产品负责人——所有的优先级排序都通过产品负责人，但是澄清尽量由团队和用户／客户及利益相关者直接进行。这也正是为什么只有一个PO的起因。

（2）2～8个特性团队，每个团队3～9人——每个团队是自管理的、跨职能的、在同一地点的、长期的。

（3）每1～3个团队设置1个Scrum Master，Scrum Master是一份专职和全职工作，不只关注一个团队，而是整个组织系统。注：LeSS包含的人员共8～81人。

小型LeSS的3个工件

（1）一个且只有一个产品待办列表；

（2）每个团队有自己的迭代待办列表；

（3）一个且只有一个潜在可发布产品增量。

小型LeSS的7个事件：

（1）迭代（Sprint）：统一迭代节奏

有一个产品层面的Sprint，而不是每个团队有不同的Sprint。每个团队同时开始和结束一个Sprint。每个Sprint产出一个集成的完整产品。

（2）迭代计划会议（Sprint Planning）：两次会议，先总后分

迭代计划会议第一部分（Sprint Planning 1，SP1）——由所有团队成员或者者团队、产品负责人、Scrum Master参与，他们一起试探性地选择每个团队将在下一个Sprint工作的待办事项，以及定义各团队的迭代目标。团队会识别一起合作的机会，并澄清最终的问题。

迭代计划会议第二部分（Sprint Planning 2，SP2）——由各团队并行地执行，来决定如何完成所选择的待办事项。对那些相关性强的条目，也经常采用在同一房间内进行多团队迭代计划会议，即并行地进行SP2。

（3）每日站立会议（Daily Scrum）

每个团队有自己的每日站立会议。跨团队协调由团队决定。每日站立会议倾向于分布式和非正式协调而非集中式协调。

（4）产品待办列表梳理睬议（Product Backlog Refinement，PBR）

团队利用研讨会的机会与客户和利益相关者澄清后续要做的待办事项，包括拆分大的待办事项、澄清待办事项直到准备好可以迭代开发、采用相同的单位进行相对故事点估算等。

总体产品待办列表梳理（Overall Product Backlog Refinement）——决定将由哪个团队来做哪些待办事项，并做进一步的深度梳理。参与人员：团队代表或者者所有团队成员、产品负责人、Scrum Master或者者领域专家等。

单团队产品待办列表梳理（Team-level Product BacklogRefinement）——和Scrum一样，参与人员为单团队所有成员、Scrum Master，没有PO，但是有客户、用户或者者利益相关者等。

多团队产品待办列表梳理（Multi-team Product BacklogRefinement）——两个或者者多个团队的所有成员、Scrum Master、客户、用户或者者利益相关者一起梳理一组相关的待办事项。从每个团队抽取人员组成临时混合小组，在同一个房间的不同区域并行进行梳理，“30分钟”时间盒之后，每个区域留下一两个人，小组其余所有成员轮转到下一个区域进行梳理。留下来的人通常包括用户、客户或者其余利益相关者。之后合起来分享见地和协调。

（5）初始产品待办列表梳理睬议（Initial Product BacklogRefinement，IPBR）

初始PBR针对一个产品仅做一次初始PBR。在第一次迭代之前，或者者在第一次转型到Scrum的时候，进行初始PBR，来定义愿景、发现待办事项、拆分大的条目、澄清待办事项直到准备好可以迭代开发及完成的定义（DoD）。参与人员：产品负责人、Scrum Master、所有团队所有成员、用户、客户、领域专家等

（6）迭代评审会议（Sprint Review）

小型LeSS的迭代评审会议和Scrum一样，在迭代结束的时候对潜在可交付的产品增量进行评审。参与人员：产品负责人、Scrum Master、小Scrum团队所有成员、用户、客户、领域专家等。

（7）回顾会议（Retrospective）：先小团队，再大团队

在迭代结束的时候对工作方式进行迭代回顾。首先每个团队都召开自己的团队回顾会议（TeamRetrospective），与Scrum的迭代回顾会议一致。之后，进行全体回顾会议（Overall Retrospective），这个会议由产品负责人、所有的Scrum Master、各团队代表和管理者（假如有的话）参与。

巨型LeSS

当开发一个产品所需要的人数超过8个团队时，就需要巨型LeSS框架。巨型LeSS包含了多个并行的小型LeSS