Product Backlog

Product Backlog

Product Backlog由所有的功能特性，包括业务功能，非业务功能 (技术、架构和工程实践相关) ，提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。

一个完整的Backlog是一个蓝图，可以根据它来把产品改造成为我们期望的样子。

但是在Scrum中，Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的，我们会持续的改变它去确保我们的产品是最合理的，最有竞争力的，最有价值的。

当我们去看产品的Backlog的时候，优先级是一个重要的视角，优先级越高的Backlog需要越清晰，越详细。对于优先级低的Backlog，详细程度会越低，直到几乎我们不能认为它是一个Backlog项 (非常低的优先级，只相当于一个占位符，来用做提醒) 。

评算(Esitimate)

对每个backlog项做估算 (包括成本，复杂度，风险，功能点) 。优先级越高的Backlog估算要越精确，在估算的过程中可能会导致backlog的优先顺序有可能随之发生变化 (对于那些很重要，并且可以快速解决的问题可以先做) 。 我们要经常做估算。

创建者(Creater)

Backlog内容的来源是多样化的. 产品营销部门会分析产生产品的特性和功能点，销售也会有很多反馈可以使产品更具有竞争力或者取悦某些特殊的客户。产品的架构师或者设计人员也会提出一些技术架构方面或者工程实践方面的需求使得产品更加灵活，更具扩展性，可复用性，开发更高效等等。产品实施或者技术支持部门也会有许多产品缺陷的反馈被放入Backlog。

重要程度(Importance)

每个Backlog项都有优先级，这些backlog项按照优先次序排行队列放在Backlog列表中。在评估的过程中

我需要在"什么样的产品特性，技术架构，缺陷的修复才会给产品公司和它的客户带来带来最大的收益？ " 和"什么样的技术架构，工程方法使我们可以更快，更高质量的交付版本"之间做出抉择。不论是对内部技术环境或者外部市场，我们都需要不断筛选和评估什么是最重要的。

版本发布(Release)

规划接下来的几个版本，包括版本的目标，及可能包含的内容。 (我们可能需要在发布内容，开发成本及发布周期之间做出抉择) 。

产品Backlog要按照Release分组，要让开发团队的所有成员都全部的了解总体开发目标，并且确保所有的技术问题都做了充分的考虑并且放入了产品Backlog.

负责人(Product Owner)

我们需要指定一个负责人来管理Backlog。这个人的职责是管理和控制Backlog列表，对于商业产品的开发， Backlog的负责人也许会是产品经理，对于内部项目的开发Backlog的负责人有可能是项目经理或者它指派的人。这个负责人的职责是调整产品Backlog的优先级和工作量估算，同时决定哪些内容包括在Sprint中。这是一个各个相关的组织协作的过程。

优先级(Priority)

只有一个人来进行排序的工作，这个人的职责是确保达成产品的愿景，提高产品投资回报率。这个人的职位一般是产品经理或者产品营销经理。如果任何人需要改变优先级，他们必须说服这个负责人去改变。

可视化(Visualization)

产品的Backlog需要能够让开发团队，利益相关者等相关的人能够很容易的看到它的内容，状态，进展等等。

以下是引用《硝烟中的Scrum和XP-我们如何实施Scrum (Henrik Kniberg著) 》

中讲述他们如何编写Product Backlog:

Product 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 (测试驱动开发) ，那么这段描述就可以作为验收测试的伪码表示。

Product Backlog (示例)

ID Name Imp Est How to demo Notes

1 存款 30 5 登录，打开存款界面，存入10欧元，转到我的账户余额界面，检查我的余额增加了10欧元。 需要UML顺序图。目前不需要考虑加密的问题。

2 查看自己的交易明细 10 8 登录，点击"交易”，存入一笔款项。返回交易页面，看到新的存款显示在页面上。 使用分页技术避免大规模的数据库查询。和查看用户列表的设计相似。

我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。

通常我们会把backlog存放在共享的Excel文档里面 (是为了多个用户可以同时编辑它) 。虽然正规意义上这个文档应该归产品负责人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打开这个文档，弄清一些事情，或者修改估算值。

基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放到共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会导致锁操作或是合并冲突，这是最简单的方式。

但是基本上其它所有的制品都放在了版本控制仓库中。

额外的故事字段

有时为了便于产品负责人判断优先级别，我们也会在产品backlog中使用一些其它字段。

Track (类别) ——当前故事的大致分类，例如"后台系统"或"优化"。这样产品负责人就可以很容易选出所有的"优化"条目，把它们的级别都设得比较低。类似的操作执行起来都很方便。

Components (组件) ——通常在Excel文档中用"复选框"实现，例如"数据库，服务器，客户端"。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个故事的实现中会被包含进来。这种做法在多个Scrum团队协作的时候很有用——比如一个后台系统团队和一个客户端团队——他们很容易知道自己应当对哪些故事负责。
Requestor (请求者) ——产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
Bug tracking ID (Bug跟踪ID) ——如果你有个bug跟踪系统，就像我们用的Jira一样，那么了解一下故事与bug之间的直接联系就会对你很有帮助。

我们如何让产品backlog停留在业务层次上

如果产品负责人有技术相关的背景，那他就可能添加这样一个故事: “给Events表添加索引”。他为啥要这么做？真正的潜在目标也许是"要提高在后台系统中搜索事件表单的响应速度”。

到后面我们可能会发现: 索引并不是带来表单速度变慢的瓶颈。也许原因与索引完全不相干。指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。

只要发现这种面向技术的故事，我一般都会问产品负责人 “但是为什么呢"这样的问题，一直问下去，直到我们发现内在的目标为止。然后再用真正的目标来改写这个故事 (“提高在后台系统中搜索并生成表单的响应速度”) 。最开始的技术描述只会作为一个注解存在 (“为事件表添加索引可能会解决这个问题”) 。