需要有代替产品backlog的方法吗？
- - InfoQ cn如果 不加注意，产品backlog就可能变得很庞大且不易维护. 通常的做法是经常回顾backlog，然后剔除掉那些团队永远都不准备做的条目. Neil Killick从其他方面 质疑了该方法管理需求的有效性.. 它可能使得产品的整体愿景打折. 它会产生维护费用（无效的成本）. 让PO（Product Owner，产品负责人）更难理解依赖关系.
需要有代替产品backlog的方法吗？
标签：
需要
产品
backlog
| 发表时间：2012-09-07 00:41 | 作者：
出处：http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117
如果 不加注意，产品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时，注意过有类似的问题存在吗？你试过哪些代替它的方法？
译者 郭雪品 InfoQ中文站编辑，项目经理。关注项目管理、敏捷、移动互联网，喜欢读书和分享。
相关 [需要 产品 backlog] 推荐：
作为产品经理，不应只知道往产品backlog增加新功能
- - 博客园_新闻所谓时间飞逝、日月如梭，暮然回首，猛然发现自己出道伊始也将近十年了. 回顾此前自己曾经担任过的角色，不可谓不繁杂. 曾经做过翻译员、测试、开发、测试主管、项目经理、产品经理，甚至还做过销售，徒步的大街小巷的去拜访潜在客户. 此间我觉得最让自己慨叹的是当年做产品经理的时候的一些得失. 所以这里就打算写下来，与同行们共勉.
Redmine Backlog tracker注意事项
- - CSDN博客研发管理推荐文章最重要的，story和task的tracker不能相同. 否则在taskboard中会将task和story并列显示，尽管它们是父子关系. 因此比较好的做法是，story使用redmine默认的tracker：Support, Bug 和Feature. 而另外创建一些tracker用来跟踪task.
java socket参数详解:BackLog
- - 开源软件 - ITeye博客 java socket参数详解:BackLog. 输入连接指示（对连接的请求）的最大队列长度被设置为 backlog 参数. 如果队列满时收到连接指示，则拒绝该连接. backlog参数必须是大于 0 的正值. 如果传递的值等于或小于 0，则假定为默认值. 经过测试这个队列是按照 FIFO（先进先出）的原则.
Scrum之backlog估算与分解
- - ITeye博客在Scrum中，针对PO提出的backlog进行估算与分解是Scrum master常见的工作，简单总结了下一些概念和方法：. 1.关注backlog的创建者和来源，优先级，以及发布时间. 2.对每个backlog进行成本，复杂度，风险，功能点. 3.针对backlog在计划会议上进行任务分解，把每个backlog分解为多个task,团队成员根据相应分工与特长估算工时和认领：.
Scrum 学习篇 -- Backlog之浅析 （一）
- - ITeye博客本文所说的Backlog是Scrum中的一个专用名词，大约意思是待办的工作事项. Backlog里面放的是需要实现的所有任务，包括功能性的和非功能性的任务，换句话说，就是咱们已经把客户的需求提炼出来并且已经完成了设计的部分，现在这些已经完成设计的用户需求被放在一个地方，持续添加新的进来并且随时可以分配出去进行开发，这个地方就叫做Backlog.
[原]白话SCRUM 之三：sprint backlog
- - 麦哲思科技Sprint Backlog就是任务列表，如果映射到传统的项目管理理论中就是WBS（work breakdown structure)，而且是典型的采用面向交付物的任务分解方法得到的WBS. 比如有一个Product backlog 条目为：. 作为系统的合法用户，可以通过录入账号和密码登录到系统中.
[原]白话SCRUM 之二：product backlog
- - 麦哲思科技 在SCRUM方法中明确要求了3个文档： 1 product backlog. Product backlog 中列举了本项目应该实现的需求，需求采用了用户故事的方式进行描述，用户故事是一句简短的采用用户熟悉的术语表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事.
Scrum 学习篇 -- Backlog之浅析 （三）
- - ITeye博客介绍了上面三个Backlog的重要性，大家应该能感觉到在敏捷中，Backlog的确是非常重要的一个概念. 下面就来具体介绍一下Backlog的几个分类：. 由于不同的公司、不同的专家对Backlog的分类总是有点区别，所以我们就以业界最知名的敏捷开发工具 TechExcel DevSuite中的Backlog来举例子吧，.
Scrum 学习篇 -- Backlog之浅析 （二）
- - ITeye博客 除了优先级外，还有一个设置也是非常重要的，就是对于每个任务，你需要做工作量预估，预估什么呢，预估该任务开发完成所需的时间和人力等，敏捷里把这个预估叫做Story Point，故事点. 故事点这个概念现在争议很多，究竟以怎么样的方式来预估工作量呢. （1） 有人说用小时，但是我们知道能力强的人跟能力弱的人所用的小时数必然是两样的，所以通过小时来得到故事点并且进而得到Velocity数据是不正确的.