产品待办列表

产品待办列表对应的英文是product backlog，也有翻译为“产品待办事项列表”，是指为开发完善产品而待办的事项列表。

在Scrum Guide中，产品待办列表是一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。产品待办事项列表永远是不完全的，最初的版本只列出最初始的和众所周知的需求。产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的，它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在，产品待办事项列表就存在。

产品待办列表里有什么？

产品待办列表的另外一个翻译产品待办事项列表显示产品待办列表里应当包含待办事项。待办事项包括所有的特性、功能、需求、改进方法和修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。常见的待办事项是以用户故事形式来表达的，也有将原始需求、客户需求、需求用例等作为待办事项存放到产品待办列表

如何维护产品待办列表？

在Scrum Guide中，产品待办列表通常以价值、风险、优先级和必须性排序。排在顶部的产品待办列表条目需要立即进行开发。排序越高，产品待办列表条目越紧急，就越需要仔细斟酌，并且对其价值的意见越一致。排序越高的产品待办列表条目比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低，细节信息越少。开发团队在接下来的Sprint 中将要进行开发的产品待办事项列表条目是细粒度的，已经被分解过，因此，任何一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完成”的产品待办列表条目被认为是“准备好的”或者“可执行的”，能在 Sprint 计划会议中被选择。随着产品的使用、价值的获取以及市场的反馈，产品待办列表变成了更大、更详尽的列表。因为需求永远不会停止改变，所以产品待办列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办列表的变化。

若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办列表只能有一个。那么这就需要使用对产品待办列表条目进行分组的属性。“产品待办列表优化（2013年前英文原文是grooming,Scrum Guide2013版改为refinement）”是增添细节、估算和排序条目的举动。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表优化的时候，条目会被评审和修改。然而，产品负责人可以随时更新产品待办事项列表条目或酌情决定。

单列表的产品待办列表有什么困难？

从以上文字可以推断，Scrum Guide所说的产品待办列表是一个列表，通过不断维护，排在顶部的待办事项得到了分析，并拆分到足够小的粒度，以便在一个迭代冲刺中进行开发。这样做法有如下的两大不利之处：

1. 早先的一个待办事项可能分解成多个待办事项，其关联信息难以维护
2. 早先收集的信息在优化和细化过程中可能在多次传递后失真

树形的产品待办列表更具表现力,人们为了克服单列表的不足，采用了树形的产品待办列表，常见形态如下：

     1原始需求或者史诗故事A
                   1.1用户故事或者用例A1
                   1.2用户故事或者用例A2
     2原始需求或者史诗故事B
                   2.1用户故事或者用例B1
                   2.2用户故事或者用例B1
                       2.2.1 更细的用户故事B11
                       2.2.2 更细的用户故事B12

这样，原始的信息和关联关系都得到了维护。

另外一种方式是有关联关系的双列表，第一级列表是原始需求或者是史诗故事，或者是概要需求；第二级列表是用户故事，或者需求用例,第二级列表中的条目必须对应到第一级中的条目。显然的，带有关联对应关系的双列表也可以转换成树形结构。现在不少工具可以帮助展现不同的形态以方便各人的习惯。

长期运维的产品待办列表

对于业主方而言，往往需要长期的运维某产品，那么，在长期运维中，对于已经完成的待办事项如何处理？ 常见有如下做法：

• 从产品待办列表中移除，但是不能真的扔掉，为了产品的长期运维，将其转移组织到反映产品最新需求的文档中，常见用wiki作为载体
• 保留在产品待办列表中，以备查询，不再修改
• 保留在产品待办列表中，进行状态和版本管理

第1种做法遇到原功能修改增强升级时，需要先从需求文档中检索到最新情况，然后根据最新情况撰写待办事项进入到产品待办列表；当此待办事项做完之后，再从产品待办列表中再搬移更新回到需求文档。

第2种做法遇到原功能修改增强升级时，可查询到原来如何，新建待办事项来处理，跟踪新的待办事项。

第3种做法无须进行转移，利用条目化管理工具能方便的管理其状态、版本以及关联关系。 当已经完成的事项需要修改增强升级时，只需检索到原条目，然后进行修改，将其发布目标版本设为最新目标的版本。较之第1种方法，无需搬移，而随着工具的发展，第2种做法渐渐成为多数的选择，在这种情况下，产品待办列表的字面意思就不再恰当，也许改名为产品需求列表更为合适，或者说产品待办列表是产品需求列表的一部分，对产品需求列表设立一个过滤器，查询未完成的待办事项就得到了“产品待办列表”。

外部链接

• 产品待办事项梳理 - 捷伴行Agile （页面存档备份，存于互联网档案馆）