LeSS 是什么
LeSS（Large-Scale Scrum）是规模化敏捷框架中主张「少即是多」的一支：不增加新角色与新产品待办，而是把单团队的 Scrum 规则原样复制到多个团队，让所有团队围绕同一个产品可交付物工作，共享一个产品待办列表与一个产品负责人。团队数量进一步增加、需求领域差异明显时，用 LeSS Huge 按需求领域划分领域团队，每个领域配领域产品负责人，但仍保留整体一致的产品负责人与产品待办。
基本信息
| 基本主张 | 用更少的框架与更多的授权支撑规模化 |
|---|---|
| 核心规则 | 一个产品待办列表、一个产品负责人、一份完成定义 |
| 协调机制 | 跨团队对齐会、整体回顾与共享节奏 |
| 适用前提 | 各团队围绕同一产品可交付物，能合并到一个集成产物中 |
| 深化形态 | LeSS Huge 按需求领域分组，设领域产品负责人 |
典型使用场景
- 单产品团队扩张到多团队，需要避免团队各自维护待办造成整体优化失效
- 多个团队共同交付同一系统，需要用统一完成定义与整体集成标准协调
- 跨团队依赖频繁，需要固定的对齐会与联合回顾机制而不是临时协调
- 产品规模大到单一产品负责人无法覆盖时，评估是否进入按需求领域拆分
- 评估规模化框架选型，比较共享待办与多待办两类做法的适用条件
落地要点
落地要点
共享待办：所有团队从同一个产品待办列表拉取工作，由产品负责人统一排序
完成定义：明确整体可交付的判定标准，避免各团队口径不一
对齐机制：定期跨团队对齐会同步依赖与集成状态，问题当场分派
整体回顾：联合回顾关注系统性问题，而不是各团队自评
授权下放：团队在技术方案与协作方式上自行决策，减少上报层级LeSS 与 LeSS Huge 对比
| 对比项 | LeSS | LeSS Huge |
|---|---|---|
| 产品待办 | 一个，全体共享 | 按需求领域分组管理 |
| 产品负责人 | 一个 | 整体一个，各领域设领域产品负责人 |
| 适用规模 | 少量团队围绕同一产品 | 更多团队且存在明显需求领域划分 |
| 主要风险 | 共享待办名义化，实际各排各的 | 领域划分过细，跨领域依赖无人负责 |
与多产品待办的做法相比，LeSS 更强调共享可交付物与整体优化：它的前提是各团队产出能合并成一个产品，如果各团队交付物本就相对独立，强行共享待办反而增加协调成本。