问题背景

文章讨论了在敏捷开发中，如何有效管理多团队共享一个Backlog（One Backlog with Multi-Teams）的问题。作者指出，需求的变化使得传统的进展估算方式难以准确衡量交付价值。这种情况下，核心问题在于团队是否能够真正满足客户需求，而不是单纯追求交付量或速度。

三种假设的分析

第一种假设：单一Backlog，拉式系统（Pull System）

采用用户故事颗粒度管理Backlog，团队通过拉取需求而非被动指派来完成任务。适用于团队数量较少的场景（如5-6个团队）。这种方式的优点包括：

• 团队能了解需求全貌，识别依赖关系。
• 促进自组织，团队根据优先级自主决策。

缺点在于对团队的自组织能力要求较高，通常更适合初创公司或敏捷成熟度较高的团队。作者参考了LeSS和Spotify的相关方法，但指出Spotify的框架并非完全适用于规模化的敏捷场景。

第二种假设：分级Backlog，推式系统（Push System）

将Backlog管理分为Feature级别和Story级别，产品经理关注对用户有价值的Feature，并规划版本发布。这种方式的优点包括：

• 结构清晰，便于传统与敏捷思维的融合。
• 计划细化到宏观和微观层面，适合规模化敏捷的快速导入。

然而，缺点在于层级过多导致敏捷性降低，限制了团队的自组织能力。作者提到SAFe框架虽备受争议，但在规模化敏捷的采用中仍具广泛影响力。

第三种假设：完全独立的Backlog管理

每个团队独立管理各自领域的Backlog，减少了需求依赖和对齐会议的复杂性。这一方式质疑了One Backlog的适用性，但作者认为其仅是一种悖论，并不完全适合敏捷思想的实践。

作者观点及结论

作者更倾向于第一种假设，认为敏捷思想是超前且可实现的，但存在一定挑战。文章指出，敏捷实践没有统一标准，每家企业需根据自身业务上下文选择合适的方法。敏捷的核心是从"Doing Agile"转向"Being Agile"，即深刻理解并融入敏捷思想。

参考文献

• Scrum.org论坛讨论
• PM Stack Exchange论坛问答
• InfoQ文章