抛砖引玉：隐式的Backlog

上周，本站发布了一篇有关使用 Product Backlog 是一种浪费行为的新闻。为了让事情变得更有趣一些，接下来我们会就 Product Backlog 缺失所造成的浪费进行报道。

我曾经和一个正在组织中采用敏捷实践的团队一起工作过。他们是一个服务性质的团队——为组织中的其他团队（不一定是软件团队）开发内部软件。而该团队的主要问题之一则是没办法让所有的股东认可各自所提出的要求的优先级——每一个团队都认为自己的要求是最重要的。另外，股东们还想要所有的需求都得到满足。

这个场景在业内并不少见——一个开发小组有多个客户，每个客户都有自己的优先级。而不幸的是，很多这样的团队都没能成功的创建出一个 backlog，因为把每个客户都放到同一个页面上来太困难了。所以他们制定了内部的优先级，而这还常常会因为某个地方的火情更加严重，或是某一头的客户声音更高一些被打乱。

经过认真讨论以后，该团队意识到实际上每一个团队都有一个 backlog——即使不是显式的。就算是不存在什么物理的可见的 backlog，任务的执行顺序也只会有一种——这也就是说，在每一个项目中（无论敏捷与否）都存在有一个根据执行顺序而决定的隐式的 backlog。

他们决定显式化他们的 backlog 并公开给所有的客户。他们希望这样一来，随着时间的推移，当客户看到团队的执行情况时，他们会更有兴趣参加到这个 backlog 的维护中来。

当然，这个问题还会有其他的解决方式。比如，在Agile 2007 大会上 BBC 小组的报告中提到，他们尝试着用一个产品负责人（Product Owner）来管理多个 backlog。Clinton Keith为此写了一篇很精彩的文章，对问题和他们的解决方案进行了总结。Mike Griffiths 也描述了一个项目管理办公室（Project Management Office，PMO）是如何通过他们的 backlog 来和多个敏捷项目进行交互的。

你是不是也同样因为只创建一个 backlog 过于困难，所以在多个项目之间使用着一个隐式的 backlog？你觉得这是浪费吗？你是怎么解决这种问题的呢？

抛砖引玉：隐式的 Backlog