【落叶94】“老兵聊测试”之 Scrum 七剑（四）【Produ
文/秋之川
这是《落叶》文集里第 94 片落叶，希望你能喜欢，不为别的，只为这份坚持。
The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it's not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.
为什么先引用 Product Backlog 的原文解释呢？因为很多名词的释义在被翻译成中文之后，要么比较晦涩，要么就有偏差，通过原文能更精准地理解这个 Scrum 里重要的工件之一。
今天我这个老兵来理论结合实践的说说 PB 在 Scrum 里到底有什么用，后续会结合更深入的学习实践继续改进更新。
1、PB 指的就是 Scrum 流程里的产品清单，Product Owner 和团队会基于这个清单得出 Sprint Backlog 和 Sprint Plan，所以你可以把 PB 理解成一个产品需求池和规划路线，PO 对它负责，创建和维护的权限都只有 PO 才有，它也是持续增长的一个清单；
2、PB 通常包含有几项内容：Features，Bugs，Technical word，Knowledge acquisition，下面会分开描述；
3、Bugs：缺陷，通常来自于用户反馈和之前 Sprint 遗留下来的已知问题，这类任务需求比较清晰单一，责任人也相对明确；
4、Technical work：技术类工作，通常来自于开发团队内部，例如代码优化、模块代码重构、自动化脚本更新和性能优化等，这类任务需求比较清晰单一，责任人也相对明确；
5、Knowledge acquisition：知识获取，通常来自于产品交接，新项目所需的知识学习、技术预研等等，根据不同阶段的 Sprint，这类需求的优先级会有不同；
6、Features：功能或特性的需求，一般会用简短的文字进行描述，通常有固定的语法格式，在 Scrum 里称之为 User Story，顾名思义就是从用户的角度来描述用户渴望得到的功能。下面我们来重点说下 User Story，你可以简单地理解 PB 就是由多个 User Story 组成的集合；
7、User Story 的标准格式：As a Role, I want to Do，so that some Reasons. 作为“某种角色”，我想要“做什么”，所以“需要什么”；
8、什么是优秀的 User Story？一个好的用户故事应该包括以下三个要素和六大特性：
三个要素：角色、活动、商业价值，角色和活动要描述清晰，商业价值的作用在于让团队能够很清楚这个 User Story 的价值，同时也能很好地理解真实的用户场景；
六大特性：独立性、可协商性、有价值、可估算性、短小、可测试性
9、产品负责人在编写 User Story 的时候，需要定义好验收标准，也就是 Scrum 里常听到的 DoD （Definition of Done），因为 PO 在做 Sprint 验收的时候，需要一个清晰且唯一的标准，否则会导致 PO 和开发团队在验收问题上的扯皮。
比如：
Sprint 验收的 DoD：代码完成、单元测试完成、功能测试完成、帮助文档完成。
项目发布的 DoD：性能测试完成、安全测试完成、灾难恢复测试完成
10、User Story 和 User Story 之间尽可能地减少依赖关系，同时对于 User Story 常用故事点（Story Point）去评估大小，这里的故事点只是一个相对值，并不是绝对值。通常都是选定一个合适规模的 User Story 作为 1 SP，再将其他用户故事跟它比较，估算出相应的 SP 值。
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
