需要有代替产品backlog的方法吗?

如果不加注意,产品backlog就可能变得很庞大且不易维护。通常的做法是经常回顾backlog,然后剔除掉那些团队永远都不准备做的条目。Neil Killick从其他方面质疑了该方法管理需求的有效性.

据Neil所述:

  • 它阻碍了创新
  • 它可能使得产品的整体愿景打折
  • 它制造了“需求黑洞”
  • 它会产生维护费用(无效的成本)
  • 庞大的列表=高循环次数
  • 让PO(Product Owner,产品负责人)更难理解依赖关系
  • 让PO变成了确定需求顺序和优先级的角色

为什么会说这个方法阻碍了创新,Neil谈到了更多的细节:

基于提前写好的文档开发产品时,也面临相同的问题——在产品实现过程中不会促进产品创新。如果把要做的事情写在了 backlog中,那么人们就会假定它是合理的,就会认为写这个需求的人大概是花时间思考过为什么要把它排在backlog中。所以,产品负责人和团队就 会产生一种倾向,他们就会想照着这个产品“它应该的样子”来构建这款产品,照这样做也不会把事情搞砸。

许多公司会提前计划好4个、5个、6个甚至更多个迭代,并且在各个迭代中排列好要做的“用户故事”,完全忽略了如何做创新。

Todd Charron强调,当产品backlog开始没法管理时,并不是说得去找一款更复杂的敏捷产品管理工具。他重点提到:

你需要的不是更好的backlog管理工具,而是一份内容更少的backlog。

Roman Pichler谈到了产品backlog的动态特性,认为应该把产品backlog当作一个学习工具,而不是僵化、一成不变的东西。

因此,我们应该假设产品backlog有待验证,并需要通过客户和用户的反馈来细化。

RomanRoman还提供了一些工具用来代替产品backlog,其中有一款工具叫product canvas。你在处理产品backlog时,注意过有类似的问题存在吗?你试过哪些代替它的方法?

查看英文原文:Do we need an alternative to the product backlog?

译者 郭雪品 InfoQ中文站编辑,项目经理。关注项目管理、敏捷、移动互联网,喜欢读书和分享。

This entry was posted in Agile, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s