如何跨多个团队扩展敏捷开发？

Question

如何跨多个团队扩展敏捷开发？

Accepted Answer

跨多个团队扩展敏捷开发意味着协调**许多团队在一个产品上工作**，而不重新引入笨重的自上而下的控制。核心挑战是在保持团队自主性和快速反馈的同时，让团队在共同目标上保持一致并管理依赖关系。有多个框架以不同的方式来解决这个问题。

## 主要方法

| 框架 | 理念 | 权衡 |
|-----------|------|----------|
| SAFe | 分层结构、敏捷发布火车、PI 规划 | 强对齐；可能感觉笨重/规定性强 |
| LeSS | 以最少额外流程扩展 Scrum | 轻量级；需要真正的组织变革 |
| Spotify 模型 | Squad、tribe、chapter、guild | 文化模式，而非现成框架 |

```text
COMMON GOALS WHEN SCALING
- align teams on a shared product vision/roadmap
- make cross-team dependencies visible and managed
- keep each team as autonomous as possible
- preserve fast feedback despite added coordination
```

## 具体例子

一个平台上的八个团队采用季度大房间规划会，以在目标上保持一致并发现依赖关系，同时每个团队保持自己的 Sprint 节奏和 backlog。

## 常见陷阱

- 将"Spotify 模型"作为严格的蓝图复制——它是一个快照，不是产品。
- 为了组织结构图选择 SAFe，同时忽视所需的文化变革。
- 增加过多协调，导致团队失去自主性和速度。

## 为什么这很重要

糟糕的扩展会重新引入敏捷原本要消除的官僚作风，摧毁了证明这一变革合理的速度。

正确的框架取决于背景；关键是将协调开销与团队之间的实际依赖程度相匹配。

SAFe	分层结构、敏捷发布火车、PI 规划	强对齐；可能感觉笨重/规定性强
LeSS	以最少额外流程扩展 Scrum	轻量级；需要真正的组织变革
Spotify 模型	Squad、tribe、chapter、guild	文化模式，而非现成框架