跨多个团队扩展敏捷开发意味着协调许多团队在一个产品上工作,而不重新引入笨重的自上而下的控制。核心挑战是在保持团队自主性和快速反馈的同时,让团队在共同目标上保持一致并管理依赖关系。有多个框架以不同的方式来解决这个问题。
跨多个团队扩展敏捷开发意味着协调许多团队在一个产品上工作,而不重新引入笨重的自上而下的控制。核心挑战是在保持团队自主性和快速反馈的同时,让团队在共同目标上保持一致并管理依赖关系。有多个框架以不同的方式来解决这个问题。
| 框架 | 理念 | 权衡 |
|---|
| SAFe | 分层结构、敏捷发布火车、PI 规划 | 强对齐;可能感觉笨重/规定性强 |
| LeSS | 以最少额外流程扩展 Scrum | 轻量级;需要真正的组织变革 |
| Spotify 模型 | Squad、tribe、chapter、guild | 文化模式,而非现成框架 |
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。
糟糕的扩展会重新引入敏捷原本要消除的官僚作风,摧毁了证明这一变革合理的速度。
正确的框架取决于背景;关键是将协调开销与团队之间的实际依赖程度相匹配。