9.敏捷软件开发框架 - LeSS 大规模Scrum

最新推荐文章于 2024-07-22 17:43:44 发布

YYDataV软件开发

最新推荐文章于 2024-07-22 17:43:44 发布

阅读量767

点赞数

分类专栏： # 【敏捷开发ACP】文章标签：项目管理 ACP LeSS 大规模Scrum框架

原文链接：https://weread.qq.com/web/reader/d11329f071dbddc6d11fa83kaab325601eaab3238922e53

版权

【敏捷开发ACP】专栏收录该内容

24 篇文章 24 订阅

订阅专栏

大规模Scrum（Large-Scale Scrum，LeSS）是应用于共同开发统一产品的许多团队的Scrum。LeSS研究的是如何在大规模环境中，尽可能简单地应用Scrum的原则、规则、要素和目的。LeSS的核心仍然是采用Scrum，在尽量不增加角色的前提下，考虑在一个产品、一个产品待办列表、一个产品负责人下，多团队如何进行迭代。大规模Scrum包含两个框架，一个是小型LeSS（支持2～8个团队，8～81人），一个是巨型LeSS（支持8个以上团队）。

LeSS十大原则

LeSS的十大原则可以分成4类

1．单一产品

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

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

2．按Scrum迭代

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

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

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

3．消除浪费持续改进

（1）持续改进以求完美（Continuous Improvementtowards Perfection）——为“完美”目标做无尽的谦虚和激进的改进试验。

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

4．组织和运作设计

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

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

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

小型LeSS

小型LeSS框架如图所示，与Scrum一致，针对多个小团队做了最小化的扩展。

资料来源：https://less.works/zh-CN/less/framework/index.html。

1．小型LeSS的3个角色

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

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

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

注：LeSS包含的人员共8～81人。

2．小型LeSS的3个工件

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

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

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

3．小型LeSS的事件

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

（2）迭代计划会议（Sprint Planning）——小型LeSS计划会议与Scrum的迭代计划会议的目的，以及要解决的问题是一样的，也分为两个部分，只不过具体的形式有所变化来适应多团队的情况，如图所示。

资料来源：https://less.works/zh-CN/less/framework/sprint-planning-one.html。

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

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

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

（4）产品待办列表梳理会议（Product Backlog Refinement，PBR）——团队利用研讨会的机会与用户和利益相关者澄清后续要做的待办事项，包括拆分大的待办事项、澄清待办事项直到准备好可以迭代开发、采用相同的单位进行相对故事点估算等。LeSS产品待办列表梳理会议如图所示。

资料来源：https://less.works/zh-CN/less/framework/product-backlog-refinement.html

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

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

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

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

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

资料来源：https://less.works/zh-CN/less/framework/sprint-review.html。

可以采用迭代评审集市（Sprint Review Bazaar）方式。

分散方式探索：各团队并行在同一个房间内不同区域分别演示潜在可交付的产品增量，和产品负责人、用户、客户及利益相关者讨论。

聚合方式决定产品方向：全体人员对下一个迭代的方向，讨论变更和新的创意等。

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