One Backlog with Multi-Teams是不是一个好主意？

摘要

文章讨论了敏捷开发中多团队管理一个产品待办列表（one backlog with multi-teams）的实践，并探讨了三种不同的做法。作者首先指出，需求变化频繁导致one backlog的总量和剩余量难以估量，因此应关注交付给客户的价值和客户满意度。

第一种假设：Story颗粒度的One Backlog

在5-6个团队的情况下，采用one backlog是合理的。每个团队都可以了解需求全貌，依赖关系可以在进入backlog后识别，团队可以自行拉取需求。但这要求团队具有较高的自组织能力。LeSS和Spotify提供了类似的建议和实践，但这些方法并不适合所有组织。

第二种假设：Feature Level的统一Backlog

产品经理关注对用户有绝对价值的feature level发布。团队分拆feature到各自的story level backlog并进行短迭代交付。SAFe提供了多团队规模化的解决方案，好处在于有条理的规划和快速导入，但被批评为过于层级化和限制创新。

第三种假设：每个团队独立管理自己的Backlog

团队根据专精领域维护各自的product backlog，依赖关系通过团队自行对齐。这种方法质疑one backlog的合理性，提出悖论。

作者倾向于第一种假设，认为敏捷思想是可实现的。然而，由于每家公司的产品和运营方式不同，敏捷方法需要结合公司上下文进行分析。敏捷的实践应融入公司文化中，从Doing agile走向Being agile是一条漫长的路。

本文摘要旨在为敏捷实践者提供不同团队管理单一产品待办列表的分析与建议。