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

规划要开发的特性是软件开发的一个重要组成部分，特别是针对软件开发产品来说。绝大多数开发方法和流程都提供一些方式，来管理和规划这些特性，使得相关业务人员和开发人员都知道“接下来要做什么”。在 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 。