敏捷规模化框架概览
规模化敏捷解决多团队围绕同一产品协作的问题。常见路径包括 Scrum of Scrums、SAFe、LeSS、Nexus 等，选择依据是团队数量、产品耦合度与治理需求，而不是框架热度。规模化的难点不是流程模板，而是把跨团队依赖、集成节奏与共同度量真正建立起来。
基本信息
| 适用信号 | 多团队围绕同一产品与价值流协作 |
|---|---|
| 协调重点 | 跨团队依赖、集成节奏与共同度量 |
| 常见误区 | 先套流程模板，后建协作规则 |
| 关键角色 | 整合团队或发布火车工程师、产品负责人层级 |
| 落地前提 | 团队级实践稳定，才有规模化的基础 |
典型使用场景
- 团队从三五个扩展到十几个：需要建立跨团队依赖台账与集成节奏
- 同一产品多模块并行：需要统一的产品待办与发布计划，避免各自为政
- 多团队交付同一系统：需要定期的集成与联调节点，防止集成阶段集中爆发
- 组织级治理要求提高：需要在团队之上增加价值流层级的目标与度量
- 框架效果不佳时：先排查协作规则与依赖管理，而不是更换框架
选型判断要点
选型判断要点
团队数量：3 个以内可用 Scrum of Scrums，超过 5 个考虑 Nexus 或 LeSS
产品耦合度：强耦合单产品倾向 LeSS，多产品组合倾向 SAFe
治理需求：强监管或强组合管理倾向带层级框架的路径
前置条件：团队级迭代与完成定义先稳定，否则放大的是混乱
度量：跨团队统一交付节奏、依赖闭环率与集成频率常见框架对比
| 框架 | 协同粒度 | 核心机制 | 注意事项 |
|---|---|---|---|
| Scrum of Scrums | 多个 Scrum 团队 | 跨团队代表同步依赖与集成 | 代表需有决策权，否则只是传话 |
| SAFe | 产品群与组合层级 | PI 规划与敏捷发布火车 | 流程重量大，需治理支持 |
| LeSS | 单一产品多团队 | 一个产品待办与一个产品负责人 | 要求产品高度统一 |
| Nexus | 三到九个 Scrum 团队 | 整合团队与跨团队整合活动 | 整合团队需专职投入 |
规模化放大的首先是协调成本：团队数量增加后，接口与依赖管理成为主要工作量，而不是编码本身。
团队级迭代还不稳定就上规模化框架，会把未解决的问题固化进流程，改造成本成倍上升。