扫码阅读
手机扫码阅读

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

68 2024-01-18

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

对此我还特地考证了一下,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/

原文链接: http://mp.weixin.qq.com/s?__biz=MzIyODA3MjE4NQ==&mid=2457485531&idx=1&sn=0be2a759dcc9bf461aee925d6212fea7&chksm=ffd96f4dc8aee65b9c70e285b1f2fbb0320ae015614f848b9b70364949777b977608d535ddb2#rd

审时度势,踏浪而行

29 篇文章
浏览 2309
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线