产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。
我们叫它故事（story），有时候也叫做backlog条目。
我们的故事包括这样一些字段：
ID——统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
Name（名称）——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
Importance（重要性）——产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
o 我一直都想避免“优先级”这个说法，因为一般说来优先级1都表示“最高”优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？
Initial estimate（初始估算）——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。
o 问一下你的团队，“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证，可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。
o 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）
How to demo（如何做演示）——它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。
o 如果你在使用TDD（测试驱动开发），那么这段描述就可以作为验收测试的伪码表示。
Notes（注解）——相关信息、解释说明和对其它资料的引用等等。一般都非常简短。
我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。
通常我们会把backlog存放在共享的Excel文档里面（是为了多个用户可以同时编辑它）。虽然正规意义上这个文档应该归产品负责人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打开这个文档，弄清一些事情，或者修改估算值。
基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放到共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会导致锁操作或是合并冲突，这是最简单的方式。
但是基本上其它所有的制品都放在了版本控制仓库中。
额外的故事字段
有时为了便于产品负责人判断优先级别，我们也会在产品backlog中使用一些其它字段。
Track（类别）——当前故事的大致分类，例如“后台系统”或“优化”。这样产品负责人就可以很容易选出所有的“优化”条目，把它们的级别都设得比较低。类似的操作执行起来都很方便。
Components（组件）——通常在Excel文档中用“复选框”实现，例如“数据库，服务器，客户端”。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个故事的实现中会被包含进来。这种做法在多个Scrum团队协作的时候很有用——比如一个后台系统团队和一个客户端团队——他们很容易知道自己应当对哪些故事负责。
Requestor（请求者）——产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
Bug tracking ID（Bug跟踪ID）——如果你有个bug跟踪系统，就像我们用的Jira一样，那么了解一下故事与bug之间的直接联系就会对你很有帮助。
我们如何让产品backlog停留在业务层次上
如果产品负责人有技术相关的背景，那他就可能添加这样一个故事：“给Events表添加索引”。他为啥要这么做？真正的潜在目标也许是“要提高在后台系统中搜索事件表单的响应速度”。
到后面我们可能会发现：索引并不是带来表单速度变慢的瓶颈。也许原因与索引完全不相干。指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。
只要发现这种面向技术的故事，我一般都会问产品负责人“但是为什么呢”这样的问题，一直问下去，直到我们发现内在的目标为止。然后再用真正的目标来改写这个故事（“提高在后台系统中搜索并生成表单的响应速度”）。最开始的技术描述只会作为一个注解存在（“为事件表添加索引可能会解决这个问题”）。
所有评论
加载评论 ...
发表评论