敏捷开发基本概念和知识：产品待办事项
产品待办事项是什么
产品待办事项（product backlog）是由一系列不断涌现的、有序的、与产品研发和改进相关的工作内容所形成的清单 (Schwaber 和 Sutherland 2020)。该清单中的内容主要涉及以下几个方面 (Rubin 2012)：
- 有待开发的新特性（feature）；
- 需要对已有特性进行的变更（change）；
- 需要解决的缺陷（defect）；
- 与技术改进（technical improvement）相关的工作1；
- 与知识获取（knowledge acquisition）相关的工作2。
1 例如，将系统数据库升级到最新版本。
2 例如，创建原型并进行测试，以决定选用哪种系统架构。
值得特别一提的是，当产品待办事项的某些内容被安排到一个Scrum冲刺（sprint）中时，这些内容就形成了冲刺待办事项（sprint backlog）；因此，冲刺待办事项可以被视为是产品待办事项的子集。
产品待办事项源自何处
产品待办事项由谁处理
与产品路线图一样，产品待办事项主要由产品负责人（product owner）制定，但也需要其他利益相关人的参与。
产品待办事项的呈现形式
虽然Scrum方法本身并没有作出相关规定，但很多团队常常会采用主题（theme） > 长篇故事（epic）3 > 用户故事（user story）这样由粗到细的逻辑层次来呈现产品待办事项中的内容（特别是直接涉及用户价值实现的内容，例如产品的特性等）。其中，主题用于对多个长篇故事进行分组；长篇故事用于描述那些庞大且无法在一个Scrum冲刺（sprint）中完成的特性（或变更等）；用户故事由长篇故事分解而来，用于描述能够在一个冲刺内完成的最小特性（或变更等）。另外，在冲刺待办事项中，用户故事还会被进一步分解成任务（task）。以下树状图给出了前述逻辑层次的一个示例（不含“任务”）；值得注意的是，在某个特定的时间点，优先级较高的项目（位于图上方）所包含的子项会更多。
3 这里采用了Jira Software中文版对“epic”一词的翻译。
产品待办事项
├── 主题A
│ ├── 长篇故事A.1
│ │ ├── 用户故事A.1.1
│ │ ├── 用户故事A.1.2
│ │ └── 用户故事A.1.3
│ ├── 长篇故事A.2
│ │ ├── 用户故事A.2.1
│ │ └── 用户故事A.2.2
│ └── 长篇故事A.3
│ └── 用户故事A.3.1
├── 主题B
│ ├── 长篇故事B.1
│ └── 长篇故事B.2
└── 主题C这里再对主题、长篇故事、用户故事和任务的表述方式进行介绍，并提供一些实际的参考示例。
主题的表述方式较为简单，只要选取能够概括一组长篇故事共同点的关键词即可。以Scrum联盟（Scrum Alliance）官网开发项目的产品待办事项为例，其中所含的主题包括 “新闻”、“课程及活动”、“常见问题”等等(Cohn 2020)。
长篇故事和用户故事需要反映“谁（who）”、“做什么（what）”以及“为什么做（why）”。人们常常使用由英国Contexra公司某研发团队提出的句式模板来表述故事(McDonald 2015)：作为<用户角色>，我需要（完成什么动作），以便（实现何种目的或价值等）。以下是来自Scrum联盟官网开发项目产品待办事项的“新闻”主题下的几个故事(Cohn 2020)：
- 作为网站访客，我需要在网站主页阅读新闻，以便及时了解敏捷开发领域的动态。
- 作为注册会员，我需要通过RSS订阅网站新闻，以便充分、及时了解有关信息。
- 作为网站编辑，我需要对新闻条目进行优先度排序，以便在网站上突出显示最重要的文章。
值得指出的是，长篇故事和用户故事除了要具备故事内容描述外，往往还需要有各自的验收标准（acceptance criteria）。明确验收标准不仅有助于产品负责人判断用户故事是否被正确地实现，也有助于研发人员理解具体的开发内容。以“作为wiki用户，我需要上传文件以便将其与我的同事分享”这个用户故事为例，其验收标准可以包括(Rubin 2012)：
- 可以上传并加载.txt和.doc文件。
- 可以上传并加载.jpg、.gif和.png文件。
- 可以上传并加载不大于1GB的.mp4文件。
- 能够识别具有数字版权管理（DRM）保护的文件，并拒绝其上传操作。
由用户故事分解而来的任务需要反映“如何做”（how），也即实现用户故事的方法和步骤。虽然目前尚未有得到广泛认可的表达形式，但 Müter 等 (2019) 给出了一些建议可供感兴趣的读者参考。另外，与往往需要多人协作完成的用户故事不同，任务最好能够由一个人在一天之内完成；因此，在制定任务时，可以参考此要求对任务的粒度进行控制。
这里再次强调，Scrum方法本身并没有规定产品待办事项的呈现形式。尽管上面讲到的一些形式（比如用户故事），但并不一定适用于所有情形；Scrum团队有时要根据实际情况自行决定最佳的形式。
产品待办事项的两种重要状态及定义
当某个事项已经具备成熟的开发条件、能够被安排到一个Scrum冲刺中进行实施时，我们就将其视为处于就绪（ready）状态；而就绪的定义（definition of ready）则是用于判断各事项是否处于就绪状态的一系列条件，例如(Rubin 2012)：
- 事项的价值是否已经明确；
- 事项所涉及的细节问题是否已被充分了解（研发团队是否能够准确判断其可不可以完成事项）；
- 事项的依赖是否已经明确，并且是否存在会妨碍该事项完成的外部依赖；
- 完成事项所需的人力是否充足；
- 事项所涉及的工作量是否经过估算、且能够在一个冲刺中完成；
- 事项的验收标准是否已经明确且可测试；
- 如果存在性能要求，那么其标准是否已经明确且可测试；
- Scrum团队是否明白如何在冲刺评审（sprint review）中展示事项的完成结果。
当某个事项已经完成开发、能够带来一个产品增量（product increment）时，我们就将其视为处于完成（done）状态；而完成的定义（definition of done）则是用于判断各事项是否处于完成状态的一系列条件，例如(Rubin 2012)：
- 解决方案已经过审查；
- 代码编写、重构、格式化、注释及检查等工作已经完成；
- 用户文档已经更新；
- 各类测试工作已经完成；
- 不存在已知缺陷；
- 验收标准已经达成；
- 在生产环境中上线。
为产品待办事项制定明确的就绪和完成的定义、并严格按照定义来判断事项所处的状态，将有助于提高团队完成冲刺目标的成功率。
产品待办事项应具备的特点
好的产品待办事项应该具备“DEEP”的特点(Pichler 2010)——详略得当的（Detailed appropriately）、估算过的（Estimated）、涌现式的（Emergent）、排好优先级的（Prioritized）。
详略得当的是指事项优先度越高，其内容应该越详细，以便能够明确紧接下来要做的事情；反之，事项优先度越低，则其内容应该越粗略，以避免浪费时间进行无谓的计划。本文上一节给出的产品待办事项示例树状图就显示出了此特点：例如，由于长篇故事A.1的优先度更高，因此其下所含的用户故事和任务会更多；而长篇故事B.2的优先度非常低，所以其下没有更加详细的内容。
估算过的是指事项有经过工作量的估算。了解事项涉及的工作量有助于决定事项的优先度；同时，如果优先度较高的事项涉及过大的工作量，也将提示产品负责人对该事项进行进一步分解。
涌现式的是指事项处于不断更新的状态之中。只要产品没有停止研发和维护，产品待办事项就可能出现新的内容，而原有内容也可能被修改或删除。这也提示产品负责人要不断梳理产品待办事项。
排好优先级的是指事项应该具有优先度排序；优先度较高的事项应该优先处理。值得注意的是，这并不意味着我们要对所有事项进行排序；但通常来说，至少应对未来一两个版本发布涉及的事项进行优先度排序。
这里需要特别指出，冲刺待办事项并不应该具备“涌现式的”这一特点；冲刺待办事项一旦确定，在冲刺期间就不应该再改变(Rubin 2012)。
产品待办事项的梳理
要得到具备前述“DEEP”特点的产品待办事项，产品负责人必须经常对产品待办事项进行梳理（grooming），并且其他研发团队成员也应该花费（不多于）10%的工作时间帮助产品负责人进行梳理。梳理所涉及的主要工作包括向产品待办事项中添加新的事项、完善和细化原有的事项、删除作废的事项、对事项涉及的工作量进行估算、以及对事项的优先度进行排序(Rubin 2012)。