敏捷学习～backlog

如何编写产品backlog

产品 backlog 是 Scrum 的核心，也是一切的起源。从根本上说，它
就是一个需求、或故事、或特性等组成的列表，按照重要性的级别
进行了排序。它里面包含的是客户想要的东西，并用客户的术语加
以描述。
backlog一般包含这几个字段

1. ID-----统一标识符，一个自增长数字
2. Name ----- 简短的描述性故事名
3. Importance-----重要性
4. Inisital estimate ---- 团队初步估算工程量（包括story point ，一般大致相当于一个“理想的人天----man day”）
5. How to demo -----它大略描述了这个故事应
   该如何在 sprint 演示上进行示范，本质就是一个简单的测
   试规范。“先这样做，然后那样做，就应该得到……的结
   果 ”。
   o 如果你在使用 TDD（测试驱动开发），那么这段
   描述就可以作为验收测试的伪码表示。
6. Notes — 相关信息、解释说明和对其它资料的引
   用等等。一般都非常简短。
   
   额外的故事字段
   有时为了便于产品负责人判断优先级别，我们也会在产品 backlog
   中使用一些其它字段。
   ƒ Track（类别）——当前故事的大致分类，例如“后台系统”
   或“优化”。这样产品负责人就可以很容易选出所有的“优
   化”条目，把它们的级别都设得比较低。类似的操作执行
   起来都很方便。
   ƒ Components（组件）——通常在 Excel 文档中用“复选框”
   实现，例如“数据库，服务器，客户端”。团队或者产品
   负责人可以在这里进行标识，以明确哪些技术组件在这个
   故事的实现中会被包含进来。这种做法在多个 Scrum 团队
   协作的时候很有用——比如一个后台系统团队和一个客户
   端团队——他们很容易知道自己应当对哪些故事负责。
   ƒ Requestor（请求者）——产品负责人可能需要记录是哪个
   客户或相关干系人最先提出了这项需求，在后续开发过程
   中向他提供反馈。
   ƒ Bug tracking ID（Bug 跟踪 ID）——如果你有个 bug 跟踪
   系统，就像我们用的 Jira 一样，那么了解一下故事与 bug
   之间的直接联系就会对你很有帮助。