规模化敏捷LeSS（二）：LeSS团队实践指南

Scrum 能够帮助一个5-9人的小团队以迭代增量的方式开发产品，在每一迭代结束时，交付潜在的可交付的产品增量。正是由于其灵活性，Scrum 方法现已成为团队软件交付方法的首选，近期发布的15届敏捷状态报告也显示，66%的受访者及其所在的敏捷团队最常用 Scrum 方法。

但随着敏捷在团队中得到越发广泛的实践，越来越多的人意识到全组织规模化敏捷实践在当下带来的机遇。但当人们简单地将 Scrum 套用到多团队实践中的时候，又出现了各种各样的问题。为了解决大规模开发团队的敏捷应用问题，一款多团队的规模化敏捷框架 Large Scale Scrum（LeSS）应运而生。

在之前的文章中，介绍过 LeSS 的“诞生”，在此就不再赘述。在这篇文章中，我们会详细聊一下 LeSS 的具体实践：

一、框架

为了让框架更好地应用到多团队中去，Bia 和 Craig 两人决定要尽量避免向框架内添加角色、工件、流程等情况，防止因过多的定义而限制团队的经验实践。其中，他们还提出了“守、破、离”三个阶段：

基于此，LeSS框架保留了Scrum的许多实践与想法，如产品负责人、开发团队、Scrum Master三角色，以及Sprint计划会议、每日站会、回顾会议等。尽管这些概念与Scrum中的实践相同，但侧重点会有所不同。

产品负责人有两个关键的职责：一个是对产品待办列表中的事项进行优先级排序，另一个是与团队合作澄清产品待办列表中的事项。

澄清产品待办列表中事项需要产品负责人在团队与用户/客户之间担任桥梁的作用，帮助团队与用户/客户直接对话，避免产生产品的需求理解分歧。

团队的要求在前一篇文章有也有提到过，主要是自管理的、跨职能的、专注的、长期存在的，以及共处一地的。这将会让团队中的每位成员为实现团队的共同目标，决定自己如何去做。

在LeSS框架中，Scrum Master需要作为一个全职角色来帮助团队解决过程中遇到的困难。一名Scrum Master最多可管理3个团队。

LeSS中的Sprint是产品级的Sprint，这意味着，各个团队处在同一Sprint中，而在这一Sprint结束后，多个团队将交出一个集成的潜在可交付产品增量。这意味着，所有团队的Sprint计划会议、Sprint评审与回顾会议都是同时进行的。在具体的实施层面，LeSS又给出了一套应用流程：

产品待办列表细化会议（PBR）分为三层：

整体PBR是一个简短的整体产品待办列表细化会议，主要包括产品负责人以及所有团队成员。这一会议主要为团队分配要实施的事项。

在LeSS中，多团队PBR通过专家、用户/客户、产品负责人、团队成员的共同参与，来推进Sprint，提高跨团队的适应性。多团队PBR一般只有两个团队。

但团队PBR在LeSS中比较少见，一般会应用在巨大且模糊不清的项目背景下，需要先让一个团队清除迷雾，后续逐步加入其他团队的情况中。

Sprint计划会议分为两部分：

这一会议是所有团队的会议，会议将划分各个团队的具体工作事项。如果团队的数量较少，可以全体团队成员参与这一会议。如果有两个以上的团队，则需要每个团队派出一个团队代表（除Scrum Master外）参与会议。

这一会议是各团队内部的会议，团队在此会议上制定自己团队的Sprint计划。有时为了团队之间的分享与学习，两个或多个团队可能会在同一房间的不同区域举行自己团队的计划会议。

与Scrum中的每日站会不同的是，其他团队的成员可以加入该团队的每日站会，进行信息共享，更好地协调团队之间的合作。

Sprint评审会议需要所有团队一起评审该Sprint交付的潜在可交付产品增量，应实现所有人就产品进行协作的机会。这里的所有人指的是除产品负责人之外，还包括团队成员、利益相关者等。

回顾会议最长持续45分钟，分为两种情况：其一是团队内部展开回顾会议，其二是产品负责人、Scrum Master、团队代表进行整体回顾，主要讨论跨团队的协作、系统问题。

与Scrum一样，在一整套带有流程的框架下，LeSS提供了足够的具体实践，以及足够的灵活性以及扩展性，帮助大规模团队探索自己的敏捷之路。在此基础上，大规模团队可以调整团队实践，最终打造出真正适合自己的规模化敏捷实践。

此外，还要注意的一点是，LeSS框架更适合于8个以下的团队数量，如果团队数量超过8个，就需要应用LeSS Huge框架。具体LeSS Huge框架是如何应用的呢？详见下一期。

0 人点赞