没有主心骨的 Backlog

  • Vikas Hazrati
  • 郑柯

2009 年 2 月 17 日

话题:敏捷方法论语言 & 开发架构文化 & 方法

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

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

我们用了很多时间与客户一起工作。我们努力理解他们的目标、他们的用户,还有待构建系统的主要构成部分。然后我们就会埋头扎入细节——想要构建的功能。我的脑海中浮现出一棵树,主干由驱动系统的目标或是期望得到的好处构建而成,大的枝干就是用户,他们需要系统提供的能力构成了小的分支和枝桠,用户故事也就是最末端的输液,规模很小足以放到开发迭代之中。

当上述工作全部完成,也建立起来对系统的共同理解后,我觉得好像我们把所有的叶子都从树上拔下来了,然后放到一个袋子之中,接下来又把树砍到了。

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

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

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

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

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

我可以与用户、利益相关者或是开发人员从头到尾过一遍故事图,然后可以讲述关于系统用户的故事、他们要做什么。我也可以只查看故事图的上端,只涉及高层的功能。我也可以深入故事图下部,讨论功能细节。

与用户和其他人讨论故事图,可以让我发现被我忽视的地方。这样做的时候,我常用户那里听到“你在这里丢了几个步骤”。

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

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

查看英文原文:Backlog Lacks the Backbone

敏捷方法论语言 & 开发架构文化 & 方法