规模化敏捷是什么
当一个产品需要多个团队协同交付时，单团队 Scrum 的对齐机制不够用，于是出现规模化框架。SAFe 用分层结构与固定计划节奏解决对齐，LeSS 主张用更少的流程、让多团队共享一个产品待办与迭代。选型取决于组织规模、系统耦合度与现有文化。
两种主流框架
| SAFe | 分层结构：团队层 / 项目群层 / 组合层，按固定节奏对齐与同步 |
|---|---|
| LeSS | 多个团队共享一个产品待办与一个迭代，强调规则少、去中心 |
| 共同点 | 跨团队对齐、迭代节奏、端到端价值流、依赖显式管理 |
| 选择依据 | 团队数量、系统耦合度、既有管理结构与承受变革的能力 |
典型使用场景
- 多团队做一个产品，跨团队依赖频繁导致交付延期
- 业务要求给出季度级可预期路线，需要跨团队统一节奏
- 组织刚完成部门重组，需要一套对齐机制替代原有汇报流程
- 同产品多团队各自迭代，集成长期靠临时会议解决
- 供应链或监管要求交付过程可追溯、节奏可预测
选型前的自问清单
选型前的自问清单
有多少团队需要协同？五个以内通常先补依赖管理即可
产品是一个系统还是多个松耦合系统？
组织能承受多少新角色与会议？
当前痛点是优先级对齐，还是交付能力不足？
管理层愿意改变考核方式吗？
# 若痛点是本地交付速度，先解决工程实践而非引入框架两种框架对照
| 维度 | SAFe | LeSS |
|---|---|---|
| 结构 | 多层：团队、项目群、组合 | 扁平：多团队共享一个产品待办 |
| 节奏 | 固定计划周期与同步活动 | 沿用单迭代节奏，规则更少 |
| 引入成本 | 角色与仪式较多，培训投入大 | 流程轻，但对自组织要求更高 |
| 主要风险 | 流程膨胀、形式化 | 对齐不足、协调靠自觉 |
规模化框架本身不产出交付能力：工程实践（自动化测试、持续集成、小批量发布）没跟上时，增加对齐会议只会把延期暴露得更早。