LeSS- 大规模敏捷开发框架实践心路

什么是 LeSS?

对于小规模产品，一个 Scrum 团队也许可以很好地应对，然而在现实中，涉及到大规模的产品开发时，常常会出现需要多个团队协同开发一个较复杂产品的情况。那么，多个团队如何通过有效合作来完成一个产品的开发呢？

Scrum 现有的基本框架难以满足这种复杂多变的管理需求，LeSS 应运而生。

什么是 LeSS？

“LeSS — Large-Scale Scrum, is Scrum applied to many teams working together on one product.” LeSS - 大规模敏捷依然是 Scrum，依然是三个角色，三个工件，五个会议，五个价值。LeSS 框架想要解决的问题是如何将 Scrum 的原则，元素尽可能简单够用地使用到多个团队，合作开发一个产品的场景里去。

LeSS 架构图

适用范围

根据定义，LeSS 框架规则应用于 2-8 个 scrum 团队同时合作开发同一个产品的情景，超过 8 个团队的情况下则推荐使用 LeSS Huge。

LeSS 在团队中的应用所引发的变革

帮助团队从组件团队(Component Team)转型为功能团队(Feature Team)

在 LeSS 的定义中，团队是功能团队，而非组件团队。

当软件系统庞大、复杂时，通常把一个系统分解为多个组件。传统组织通常把开发者按照组件分组成为组件团队，也只有该组人有权限修改、维护这个组件。而在 LeSS 的理念中，我们要求构建功能团队, 一个功能团队能够从端到端完整地交付一个功能特性，要求团队能够做到自管理，跨职能并且能够长期合作。

为什么需要功能团队？

也许大家都会有这样的感受，在组件团队中，一个简单的功能在各个部门中来回许久也未必能够真正付诸实践，因为每个团队在计划的过程中可能会产生繁多的项目管理需求，在需求实施的过程中也会因为职能不同而产生高昂的沟通成本、等待成本，甚至到后期才发现问题的返工成本。一旦产生这种情况，将会给公司带来诸多的浪费。

在 LeSS 中，所有的项目团队是灵活的功能团队，产品需求会分阶段被拆分成多个不同的小产品需求。在一个团队中，需求需要能从前到后依次完成直至产出一个可交付使用的软件，这对团队的要求变得更高。一个团队，不仅能独立完成客户的价值交付，更能减少项目管理时间，从而把更多的时间和精力投入于团队自身发展和技术领域的精进当中。

在作者的项目中，通过团队结构的改变，很明显地观察到，功能团队对产品的质量交付要求有更多的关注，并会主动地审视自己的产品缺陷，提高各职能角色之间的协作，从而提升了产品质量并提高团队效率和能力。

LeSS 团队共享一个产品待办列表，一个产品负责人

在 LeSS 中，团队专注于整体的产品，只有一个产品负责人 (PO)。所有工作于同一个项目的团队共享一份产品待办列表 (Product backlog)。这很大程度上避免了由于需求对每个团队之间需求优先级不一致或不明确所带来的工作浪费以及产生的冗余的项目管理需求。

在作者的团队中，所有功能团队共享唯一一份优先级明确的产品待办列表，团队只需要看一份列表，确定自己未来一个迭代甚至多个迭代可能会做的功能，可以提前开始做调研，提早反馈问题。

团队在共享同一份列表的同时，也可以看到其他功能团队在同一迭代的计划，加深对整个产品交付版本的了解，也帮助团队提前识别依赖与风险。

Scrum Master 在 LeSS 中的职责变化

在 LeSS 中，Scrum Master 不再只是团队的 Scrum Master。Scrum Master 不只需要做引导团队内的敏捷实践等在 Scrum 中就存在的工作，更需要关注整个组织系统、架构，开发实践以及深入沟通和引导各部门之间的合作。

一个 Scrum Master 不仅可以服务于多个团队，而且 Scrum Master 在过程中可以更深入地思考整个组织系统存在的问题以及解决方式，通过引导团队更好地开发实践与沟通协作，维持一个运转良好的 LeSS 系统。

主人翁意识（Ownership）

在 LeSS 模式下，团队在共享同一个产品愿景，在团队独立为自己的产品产出负责的同时，团队成员对自己的产出会产生足够的主人翁意识。

通过培养团队成员的风险意识和沟通能力，使得管理者可以及时地得到关于项目状况的反馈以及当前计划的风险状况，从而做出相应的应对策略。而团队成员也会更加关注到公司战略的全貌和相关的项目计划。

促进个人不断学习成长

在组件团队到功能团队的转变中，项目团队对成员提出更高的要求。每个团队需要拥有产品交付的所有技能，并在客户需求开发过程中不断学习扩大个人技能领域。在这个过程中，学习能力至关重要。团队个人为了达到要求，会不断地自我学习以跟上团队发展的脚步。

组件团队 vs 功能团队

实践

LeSS 是 Scrum 方法的大型实践扩展，在作者的 LeSS 实践过程中，发现最容易出现问题和最难掌控的环节是在于计划(Planning)环节，为了解决 planning 的难题，我们是怎么做的呢？

• 第一部分：季度计划

  1.共享下个季度产品和团队愿景

  2.团队制定下季度大体目标（功能交付，消减技术债务，用户体验提升等

  3.制定版本发布时间

• 第二部分：迭代计划 Sprint 正式开始之前通过故事点估算与速率得出当前 Sprint 最终能承诺交付的功能

季度计划会议（Quarter planning - Large scaled scrum planning）

季度计划会议原型

作者所在的团队实行的季度计划会议参照的是 LeSS 中的 Sprint Planning 在团队中的实践应用。会议参与者是每个团队的 Lead 和干系人, 各种角色均需要参与（开发，测试， 自动化，Scrum master，产品经理, UX designer）。此会议在下季度开始之前一个月召开。

• 产品负责人介绍下季度产品需求

在会议的初始阶段，产品负责人会向大家介绍下季度产品的愿景，产品的发展方向以及 Epic 层级的需求。

• 团队粗略估算

1.团队（所有参与角色）会对产品 Epic 层级的需求进行粗略的估算。

2.团队对当前产品经理提出的任务进行需求的依赖识别，以及对需求是否能按照产品经理的上线时间要求进行相应的风险识别。

3.团队（所有参与角色）在估算结束之后进行确认，保证所有人对估算的理解以及估算大小保持一致。

依据历史数据对当前的任务估算点数进行大致版本计划，并得出未来一个季度的大版本时间和数目，并标注出时间节点。询问团队对此计划的信心度，若信心度不足则需要进行计划调整。

最后得出产品版本上线时间的初步排期和每一个排期的大致产出。

计划展示（Visualize Plan）

项目团队展示未来一个季度的版本计划与每个版本的产出，并把任务时间表汇总到一个统一的计划表上，并对计划进行展示，说明项目或者功能目前存在的风险。

询问产品经理与干系人是否对每个团队的计划和整体计划满意。如果觉得计划有问题，功能需求上线时间不能满足，或发布时间严重超出预期，则需进行计划调整。

计划调整（Plan Adjustment）

若项目版本计划不满足产品经理的需求或团队信心度过低，则尝试以下方式调整计划：

       1.需求拆分，阶段交付 

       2.项目人员资源协调 （不推荐）

       3.产品经理根据实际情况调整 Roadmap

需要进行一个跟进会议继续对项目计划进行调整。

更新产品计划（Update Roadmap） 

最后根据大家计划的初步结果，更新产品的季度计划表。季度计划表不是团队这个季度的承诺交付列表，而是团队与产品达成一致的下一季度的产品愿景计划(Roadmap)

季迭代计划会议（Sprint planning）

迭代计划会议会在每一个 Sprint 正式开始前进行，目的是通过扑克牌估算和速率计算得出当前 Sprint 最终的计划并做出承诺。

来打牌吧（Poker Estimation） 

 在迭代计划会议中，我们使用敏捷扑克来得出每个用户故事的故事点。并通过历史的团队速率(Velocity)数据与 Sprint 数据得出当前团队在下一个 Sprint 能够交付的故事点大小并做出承诺。

关于打扑克的具体实行方法不在此赘述，作者在网络上搜寻了一些参考资料供大家阅读: http://www.uml.org.cn/softwareprocess/201108264.asp

每日站会 （Daily stand up）

LeSS 是大规模化的 Scrum，因此，Scrum 的 5 个活动也不能落下。每个团队有自己独立的每日站会。

 迭代评审 （Sprint Review）

迭代评审会议每个 Sprint 只有一个且所有团队都需要参加，另外也要确保足够的干系人能够参加并提供反馈，以及进一步调整所需要的信息。

迭代回顾 （Sprint Retrospective） 

 每一个团队有自己独立的迭代回顾会议。

实践中需要注意的问题

时间表严格遵守共享，同步开发测试

在 LeSS 中，我们只有一个产品层面的 Sprint，而不是每个团队有不同的 Sprint。每个团队同时开始和结束一个 Sprint。每个 Sprint 产出一个集成后的完整产品。需要注意每个团队 Sprint 的时间节点需要严格对齐，同步开发，从而使得团队在每一个 Sprint 结束并进行过 Sprint Review 之后，产出同一个潜在可交付软件。

整体回顾会议 (Overall Retrospective)

每个团队需要有自己的回顾会，以回顾在团队内的问题，但是在各自的回顾之后需要定期举行一个整体的回顾来讨论跨团队和系统性的问题，并创建改进试验。这个会议由产品、Scrum Master 们、团队代表和管理者参加。

结语

LeSS 是将 Scrum 的原则，元素尽可能简单够用地使用到多个团队，合作开发一个产品的场景里的一种敏捷实践。