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

这其实是一个来自同行问我的问题，这个问题个人觉得颇有深度。

对此我还特地考证了一下，Scrum.org有人专门就one backlog with multi-teams的观点进行过一些讨论，那么观点似乎更多倾向在为什么要这么做。因为当我们高层希望从中看到one backlog的进展时，事情总是未必向着我们所想的那样发展，需求总是会有变化的，那么one backlog最后总量是多少，还剩多少的概念，就会被非常的颠覆，因为我们自始至终都很难估量，我们到底离距离有多远，因为变化导致我们只能知道到底我们交付了多少价值给客户，客户是否真正满意了。如果我们的价值交付没有打中客户需要，那么做再多的velocity和governance总量都将是无济于事的。

好了，那么对于为什么这件事，我们暂时讨论到这里，关键是今天我们就事论事，来说一下，如果我今天要这么做了，one backlog with multi-teams，究竟怎么做合适？为此我问了几位朋友，其中有敏捷高成熟度团队的，有过one backlog的经验，也有来自BAT公司的。也趁此机会，了解一下各家对于one backlog with multi-teams怎么看的。

下图为本人构思时画的草图，主要总结为三种假设

第一种假设，都用story颗粒度，one backlog with team

Pull system拉式系统

根据图示，产品经理根据用户的反馈，快速对应于小颗粒的用户故事，如果有大型需求，那么也是与团队共同分析拆解直至成为用户故事。个人觉得在团队不多的情况下，比如5-6个团队以内的，那么我们采用one backlog的方式是合理的。

用此方法有这样一些好处：

1）每个team都可以因此了解整个需求全貌

2）依赖关系能够在进入backlog之后开始识别

3）拉式沟通，team可以决定自己的优先级，自行拉取自己的需求，而不是被指派

也有一些缺点：

对自组织要求略高，也许在初创的公司更适用这样的工作方法

特此考证了一下，下图LeSS也给出过一些类似的建议。当然如果team多到一定数目的时候，LeSS也是建议有下一级的PO管理backlog的。

再来看一个自组织的典型，Spotify中，也有对于多团队合作处理product backlog有一个比较明确的图示。当然这种方式相当的自组织。可以给我们参考与学习。

笔者曾经在一个高度成熟的组织内，也在看见过类似的方式，但是仍旧没有那么的自组织，毕竟与所处的行业也有一定的联系性。Spotify不是一个可以随意仿效的敏捷框架，因为其本身也并不是一个规模化框架。

第二种假设，一个统一backlog属于feature level的，那么多团队共同分析这些feature，打散之后分拆到各个team，各个team又同时拥有自己的story level的product backlog。

产品经理关心什么时候发布版本，并且仅仅是那些对用户有绝对价值的feature level。

Push system推式系统

根据图示，产品经理规划所有需要研发的feature，进行依次的版本计划排序，在各个团队安置次一级PO进行共同的分析拆分feature，在各自team level进行短迭代，快速交付。最终呈现的仍然是feature level的内容给到用户。feature在必要的情况下可以遵循MMF minimum marketable feature的方法。交付最有价值的部分。

那么当feature上线后，各负责feature的PO，可以对此进行small enhancement。

下图便是对此的一个解释，在多团队规模化的情境下，SAFe给出了一定的解决方案

好处是很明显的：

1）十分有条理，对于传统思想与敏捷思想融合的初期，便于快速导入

2）计划有宏观有微观

3）规模化敏捷的快速导入的，有组织有纪律

缺点也是被无数人诟病的

1）这样并不太敏捷，因为计划太具有层级感

2）人物层级太多，限制了很多的思考

3）自组织会有一定距离

虽然SAFe毁誉参半，但是在数据上我们可以看到，仍旧是居高不下的。下图是VersionOne的年度报告，对于规模化敏捷的采用占比中，SAFe还是占有了29%的比率的。

第三种假设，每个team完全独立管理自己的backlog

首先就要对需求进行领域的区分，那么每个拿到各自专精领域的PO，手头会维护自己的product backlog。那么多个团队之间的依赖，完全依靠各自去对齐而不是通过各种对齐的会议。这样的方法，直接就推翻了one backlog的概念，因为管理同一个backlog本身就是复杂繁琐的，那么为什么不在一开始就区分好领域，那么只要在各自领域内，分析需求是不是会更愉快呢？而不是整天在扯那些需求依赖与计划。

当然提出这个假设只是希望提出一个悖论，就是或许这种one backlog的做法根本上是不合适的。

也希望更多的人可以留言，就此进行一下讨论。

在三种假设中，我个人其实更倾向于第一种假设，因为我相信敏捷思想是超前的，是正确的，并且是可实现的。但是也面临不少挑战，在此就不一一列举了。

结论，我们很难给出唯一的标准答案，因为每家的产品定义与运营方式都很不相同，因此不能一概而论，敏捷究竟采取何种方式，也要就企业的上下文进行充分分析才能决定，并且最终应该是融合到企业内部，成为企业自己的文化与工具方法。

Being agile有很长的路要走，Doing agile只是first step。但是每一个practice背后，如果我们都能够融会贯通敏捷的一些思想，并且思考为什么这么做，那么我们其实已经在逐渐走向Being agile了。

聊以此文献给还在敏捷路上的朋友们。

参考引用：

https://www.scrum.org/forum/scrum-forum/27654/one-product-backlog-multiple-teams-multiple-velocities-single-governance

https://pm.stackexchange.com/questions/22666/single-backlog-multiple-teams-how-to-handle-backlog-refinement

https://www.infoq.com/articles/scrum-multiple-teams-frameworks/

‍