使用 Product backlog 是一种浪费行为吗?

  • Geoffrey Wiseman
  • 郑柯

2007 年 10 月 22 日

话题:敏捷文化 & 方法

规划要开发的特性是软件开发的一个重要组成部分,特别是针对软件开发产品来说。绝大多数开发方法和流程都提供一些方式,来管理和规划这些特性,使得相关业务人员和开发人员都知道“接下来要做什么”。在 Scrum 过程中,期望开发但尚未实现的特性列表被称为backlog(或 product backlog[译注:未完成的产品特性列表])。这本应是轻量级的,但使用它是否仍然是一种浪费行为呢?

在常规的瀑布式开发过程中,所期望的特性列表会被迅速转变为一整套臃肿的用例集合、概括的和详细的需求规范说明,以及诸如此类的、无穷无尽的文档,这些文档不仅冗余臃肿,而且会很快过时,迅速被人们抛于脑后。

为了强调“交付可以工作的软件胜过求全责备的文档”,大部分敏捷流程试图减少开发之前投入功能文档编写的工作量,特别是在这些功能特性的内涵与优先 级有发生变化的趋势之时。然而,即使相对功能规范说明来说,product backlog 已经是轻量级的方案,但使用它是否仍然是一种浪费行为呢?当厌恶浪费精益软件开发人员与 scrum 爱好者进行互相交流时,这个问题必然会浮出水面:使用 Backlog 是一种浪费行为吗?

Alan Shalloway 直接指出:backlog 可以被视为库存

投入到 product backlog 的工作就是库存。这就是浪费。但可能需要这样做来缓解和管控风险。这与敏捷方法并不一致。我们会分析马上就要被构建的故事,而 backlog 的剩余部分应该尽量少地涉及,这样造成的浪费也就更小。

Mary Poppendieck给出了一些减轻风险的建议

我推荐使用限量的backlog,其中只包含两到三个工作周期的工作量。只要能够保证总是有事情做,而且所做的事 情是目前优先级最高的工作,这样就可以了。有一种发现这种工作队列合适长度的做法:计算队列中已完成工作的年龄——即这些工作被完成之前、所存在的平均时 长,再毫不犹豫地移除那些年龄大于平均年龄数的工作。这些条目会落到队列的最下方,并且很有可能永远不会被完成。另外一种发现队列到底能有多短的方式,就 是无情地缩短这个列表,直到短得不能再短为止。

判断你的 backlog 变得太长或是太详细的速度是否过快,可以通过计算需求“搅拌比率”来完成。需求“搅拌比率”,是指所谓的“需求”从被详细分 解、说明开始,到整个系统被实现的过程中,它们的变化百分比。如果这个比率大于——比如说——10%,那么详细的需求规范就被完成的太早了。

David Starr列举了其他一些可以用来减少 backlog 浪费的方式

  1. 设定一个视野水平线(sight horizon)用来截取 backlog,并移除超过水平线的条目。
  2. 使用基于 FDD(Feature Driven Development,特性驱动开发)的 backlog,其特性与功能的定义,相对于鼠标点击哪个按钮之流的功能来说,水平更高。使用用例来获取需求的方式可以与这种方法有很好的配合。
  3. 对于不允许花费大量时间来划分 backlog 条目的团队,强制推行估算流程。
  4. 使用扑克牌规划(Poker Planning)中的大数字(比如 20,40,100,300 之类)。这通常是团队规划 backlog 时浪费时间最多的领域。业务人员中的产品所有者希望得到高层次的划分,而工程师们则更喜欢将其拆分得越细越好。还是继续吧。

Paul Oldfield 向上面的列表中添加了新的内容

要在功能特性进入到一个迭代或 sprint 之前,将估算结果规模较大的特性拆分为更小的部分,这样你可以更好的对开发工作量进行估算,并且你可以在本次时间段内只开发功能特性中具有更高价值的部分。

Alan 进一步提出:对于冗长的 backlog 条目来说,可能会存在其他的危险——对团队心态上的影响,让他们觉得 backlog 中的全部细节都必须要完成:

现在发生的状况是:我们已经滑入了对项目过程方面的思考,而不是去考虑产品应当如何。我们没有留意是否真的应该就目前的 backlog 继续后续的工作。此处的危险非常隐晦,它有可能使得项目延期完成。它还导致大家忽视了让团队开发更好产品的可能,并因此阻碍了对要开发或改 进的产品的管理。

在管理 product backlog 方面,你是否还见过其他形式的浪费呢?对规划的需要和对持续变化的 backlog 投入过多努力从而造成的浪费,这两者之间你该如何权衡?在InfoQ你可以读到更多相关内容以及其他敏捷的话题。

查看英文原文:Are Product Backlogs Wasteful?
译者简介:郑柯,目前任职《程序员》杂志社高级编辑,有志于在中国的软件开发业界推广 Agile 的理念和方法论,笃信以人为本,关注 Ruby,关注敏捷,关注人。参与 InfoQ 中文站内容建设,请邮件至china-editorial@infoq.com
敏捷文化 & 方法