敏捷三大工件之：产品待办列表(PBL)--产品负责人(PO)
一、产品待办列表
1.1 产品迭代列表的生成
【人】产品负责人(PO) <=> 【活动】产品梳理会(Product Backlog Grooming Meeting) <=> 【产物】产品待办列表(Product Backlog)
产品待办列表（Product Backlog，简称PB）动态地包含符合产品路线图（Product Roadmap）策略和愿景的各种排列好优先级的功能和对用户有价值的其他工作（如探索、调研、基础设施、架构、重构、缺陷等）。
开发团队（Dev Team）要完成的任何工作都会体现在产品待办列表中，并由产品负责人（Product Owner，PO）全权负责梳理与维护。
产品待办列表里的工作项，称为产品待办事项（Product Backlog Item，简称PBI），通常情况下，PO会把PBI以用户视角，采用大家熟悉的用户故事（User Story，简称Story）格式进行描述，参看如下：
|
用户故事的编写：一般采用如下方式进行陈述： PO在计划会中会罗列他希望做的一些用户故事，每个用户故事，开发团队的每个人都会评估它的故事点（story point，可以采用故事价值或工时数）。 |
|---|
史诗 & 特性 & 用户故事
用户故事应该足够小，小到一个Sprint内能够完成。在复杂的业务场景中，史诗（Epic）、特性（Feature）、故事（User Story）可以使产品待办事项更加的直观。它们可以建立一种树形的结构：
然而在实践Scrum时，很多团队更习惯把它们替换成史诗（Epic）、特性（Feature）、故事（User Story）、任务（Task）和缺陷（Bug）。
注意：特性Feature 适用于IPD项目。用户故事更适用于Agile敏捷项目。
产品待办列表项来源分类：
- 新功能的开发
- 新功能的想法
- 所有级别和严重程度的缺陷
- 缺陷的修复工作
- 功能的改进
- 范围缩小后的改进
- 来自客户和利益相关者的功能请求
- 设计的变更
- 用户体验的问题
- 技术债务
- 基础设施的变更
1.2 DEEP原则
一个基于敏捷最佳实践的建议是产品待办列表应当符合DEEP原则：
Detailed Appropriately（详略得当的）：把将要在下一个迭代（Sprint）中要完成的Story和其他PBI放置在待办列表的顶部，大小合适且符合INVEST原则（参看关于用户故事一文）的Story可以帮助开发团队从用户的角度来理解需求，同时在交付的过程中按照用户场景进行验收。优先级为中、低的Story，比较大的、细节不清晰的PBI（也称为史诗，Epic），放在列表的中下部，即越高优先级的Story有越具体的内容。
Estimated（已估算的）：在列表里优先级高的Story和其他PBI是基于团队基线初步粗略估算过的，这样开发团队可以更好的在迭代计划会（Sprint Planning Meeting）为迭代待办列表（Sprint Backlog）选出一组Story。通常，优先级高的Story的估算会比优先级低的更准确，一般采用斐波那契数列（Fibonacci Sequence）的故事点估算，如 1，2，3，5，8等。更多估算参看RCMS团队的用户故事实践一文。
Emergent（涌现的）：产品随着时间是不断地演进和完善的，因此产品待办列表是动态的，随着用户的持续反馈，获得的信息和知识也越具体和详细，产品待办列表的PBI会根据实际情况插入、减少并重新调整优先级，而非一成不变。
Prioritized（排列优先级的）：产品待办列表会根据PBI的价值和战略目标，从高到底排序。近期Sprint要开发的PBI优先排序，中远期的可粗略排序。开发团队依据顺序开发，从而使产品尽早实现客户价值。可以参考使用MoSCow等方法排优先级。
摩斯科(MoSCoW)是一种优先级划分的技术，它按照四个优先级划分需求：必须具备（M-Must have）、应该具备（S-Should have）、可以具备（C-Could have）、不会具备（W-Won’t have）｛暂缓(won’t have this time,WHT)、不必(won’t have ever,WHE)｝。
符合DEEP原则的产品待办列表像冰山一样，如下图（图片源自Mike Cohn，产品待办冰山）。在冰山最上面是开发团队在近期的迭代中要实现的高优先级、大小合适、包含足够信息、可被测试的PBI。冰山越往下PBI越大且优先级越低，仅当前有足够的信息时才会被重新评估和排序。
1.3 产品待办列表梳理
产品待办列表梳理 （Product Backlog Refinement，也称Backlog Grooming），是一个反复发生、演变的事件，目的是不断地将产品愿景扩充成产品特性清单或PBI。通过举办定期的梳理会议为开发团队准备好在未来几个Sprint要开发的PBI，同时为PO提供了一个解释列表中优先级高的PBI背后的战略目的的机会，这些对话有助于提高Scrum团队理解的一致性。同时定期的梳理会议也有助于确保需要实现的Story得到优先处理。一个产品待办列表梳理会议主要包括：
会议目标：定义愿景、发现待办事项、拆分大的条目、澄清待办事项。为开发团队进行更为准确的任务拆分和Sprint估算提供依据，为下一次迭代计划会的有效执行做好准备。
会议参与者：PO，需求分析人员（BA），Scrum Master、开发团队成员（包括开发、测试，UI、运维人员等）、QA、其他利益相关者。
会议准备、输入：PO负责和利益相关者负责梳理PBI，通常通过影响地图（Impact Mapping）和用户故事地图（Story Mapping）产出Story列表。
会议时间：1-2小时
会议流程：
- 拆分大的待办事项，创建、优化Story，PO解读Story；
- 确保Story达到团队定义的 “Definition of Ready” ；
- 评估Story大小（也可以放在迭代计划会上进行），并排优先级；
- 评审中远期计划和确保发布计划符合产品路线图。
会议输出：符合DEEP原则的更新后的产品待办列表，无论业务和技术团队都清晰地知道未来几个Sprint要做的PBI。
二、 产品战略实现路径
作为初创公司， 我们需要提升团队几方面的能力：
（1） 产品部： 产品定义、产品架构、基础技术发明、竞品技术分析和评估； 高质量产品持续开发和开发团队的建设；
（2） 市场部： 理解、分析和预测产品和市场，竞品功能分析和评估；
（3） 销售部： 客户画像、竞品功能分析和评估、商务活动取舍。
产品战略 定义了公司愿景的实现路径，而 产品路线图 则是这一战略的执行计划。
产品待办列表 细化了路线图中的每一步，确保每一个需要完成的细节任务都被列出并得到执行。
产品待办列表是实现产品战略的关键组成部分。
三、产品路线图与产品待办列表对比
产品路线图 (Product Roadmap) 和 产品待办列表 (Product Backlog) 是互相支持的，一个决定了战略方向，另一个则提供了实现这些战略的具体行动步骤。 产品待办列表的内容可能会根据路线图的更新而调整，同时， 产品待办列表中的变化也可能反过来影响路线图的内容。
| 产品路线图 | 产品待办列表 | |
| 是什么 | ||
| 是什么 | 战略性产品规划工具 | 实用的任务级列表，列出创建项目所需的一切事项 |
| 包含 | 产品版本或主要版本连同每次发布的关键 特性 | 用户故事和史诗 |
| 面向 | 利益相关者、投资者，甚至客户 | 产品团队和开发团队 |
| 衡量 | 战略目标和指标 | 完成的任务/举措 |
| 时间框架 | 变化多端，从几个月到一年不等 | 产品待办列表– 不定；冲刺待办列表 – 1-2周 |
四、产品路线图、产品待办列表 与 迭代看板·工作项比较
| 从市场行业竞争的角度出发描述的工作 | 从用户使用的角度出发描述的工作 | 从开发者技术实现的角度出发描述的工作 | |
| 时间粒度 | 1-3个月，小于一个季度 | 1个月 | 2周，小于4周 |
| 会议 |
项目定义阶段会议（Project Definition Term meeting） 和版本Release计划会议 |
产品梳理会(Product Backlog Grooming Meeting) |
迭代计划会(Sprint Planning Meeting) |
| 工作(最小)项 | 商业需求文档BRD、市场需求MRD、产品需求PRD、 | 史诗（Epic）、特性（Feature）、故事（User Story） | 任务（Task）和缺陷（Bug） |
| 属性 | 编号 标题 迭代 状态 责任人 优先级 父亲工作项 需求类型 | ||
| 状态：打开、进行中、测试中、已完成 需求类型：功能需求 性能需求 技术需求 安全需求 合规需求 来源： |
来源分类： 新功能的开发 新功能的想法 所有级别和严重程度的缺陷 缺陷的修复工作 功能的改进 范围缩小后的改进 来自客户和利益相关者的功能请求 设计的变更 用户体验的问题 技术债务 基础设施的变更 |
浙公网安备 33010602011771号