没有主心骨的 Backlog

一段时间以来，Backlog 备受指责。精益理论认为作为库存的 backlog 就是浪费。 Mary Poppendieck 甚至建议：如果其作用不能满足预期，产品backlog 就应该被消除掉。 Jeff Patton 有类似的观点，他认为扁平的 backlog 无法传递系统的高层视图，建议转而使用“故事图（story map）”。

在 Jeff 看来，敏捷团队经常遇到一个问题，就是只见树木不见森林。原因在于故事的安排方式完全将要构建的系统忽略在外。Jeff 给出了一个有趣的类比：

我们用了很多时间与客户一起工作。我们努力理解他们的目标、他们的用户，还有待构建系统的主要构成部分。然后我们就会埋头扎入细节——想要构建的功能。我的脑海中浮现出一棵树，主干由驱动系统的目标或是期望得到的好处构建而成，大的枝干就是用户，他们需要系统提供的能力构成了小的分支和枝桠，用户故事也就是最末端的输液，规模很小足以放到开发迭代之中。 当上述工作全部完成，也建立起来对系统的共同理解后，我觉得好像我们把所有的叶子都从树上拔下来了，然后放到一个袋子之中，接下来又把树砍到了。

我就是这么理解扁平的 backlog——一袋没有根基的、用来作为肥料的树叶。

Jeff 建议使用故事图取代 backlog。一个故事图看起来就像下面这张图：

在故事图的上方，是一些大故事或活动，用户在使用系统时就会接触到它们。活动的顺序就是用户使用系统的顺序。其下的活动是用户任务。这些任务是用户为了完成活动而需要执行的。举例来说：如果管理 email 是一项活动，那么“发送邮件”、“阅读邮件”、“删除邮件”、“标记邮件为垃圾邮件”等等就是用户任务。

Jeff 补充说道，故事图上的活动构成了系统的主干，而任务则是分支。主干不需要排定优先级，因为它是系统运转的基础。然而，故事需要排定优先级。所有的规划都应该基于主干完成，这对如何排定构成分支的用户任务的优先级是有帮助的。

使用故事图的好处在于将宏观图景作为中心主题。除此之外，Jeff 的建议还包括：

我可以与用户、利益相关者或是开发人员从头到尾过一遍故事图，然后可以讲述关于系统用户的故事、他们要做什么。我也可以只查看故事图的上端，只涉及高层的功能。我也可以深入故事图下部，讨论功能细节。 与用户和其他人讨论故事图，可以让我发现被我忽视的地方。这样做的时候，我常用户那里听到“你在这里丢了几个步骤”。

我可以在图上注明哪些是难点、哪些是机会。在跟用户讨论时，常能听到他们说：“系统这个地方的确经常出问题。”

因此，故事图可以帮助团队经常将关注点放在他们正在构建的产品上。它可以帮助团队避免只见树木、不见森林。

查看英文原文： Backlog Lacks the Backbone