# 产品待办列表 Product Backlog ## 定义 产品待办事项列表是团队可能为了实现特定结果而进行的新功能,对现有功能的更改,错误修复,基础结构更改或其他活动的列表。 产品待办列表是团队工作的唯一权威来源。这意味着没有完成任何未完成的产品待办列表工作。相反,产品待办事项列表上存在产品待办事项不能保证将其交付。它代表团队提供特定结果而非承诺的选择。 将产品待办列表项目添加到产品待办列表中应该便宜且快速,并且删除产品待办列表项目也应同样容易,因为该产品待办列表项目不会直接导致实现预期结果或使结果有所进展。 产品待办列表项目采用多种格式,其中最常见的是用户案例。使用产品待办事项列表的团队确定他们选择使用的格式,并查看待办事项列表项,以提醒他们可能使用的解决方案的各个方面。 产品待办事项的大小和详细程度各不相同,这在很大程度上取决于团队将在多久之前进行处理。团队即将开展工作的团队规模应小,并包含足够的细节以供团队开始工作。团队可以建立一个准备就绪的定义,以表明他们对想要获得的信息的同意,以便开始处理待办列表的产品。未准备工作的产品待办列表项目可能相当广泛,并且细节很少。 随着团队对结果和确定的解决方案有了更好的了解,产品待办列表中产品待办列表项目的顺序会发生变化。对现有产品待办事项的重新排序,产品待办事项的不断添加和删除以及产品待办事项的不断完善,使产品待办事项具有其动态特性。 一个团队拥有自己的产品待办列表,并可能扮演特定角色– 产品所有者 –主要职责是维护产品待办列表。维护产品待办事项的关键活动包括:确定产品待办事项的优先级,确定应从产品待办事项中删除哪些产品待办事项以及促进产品待办事项的细化。 产品待办列表可能是团队交流他们正在从事的工作以及下一步计划进行工作的有效方法。故事地图和信息发布者可以为团队和利益相关者提供清晰的待办列表情况。 产品待办列表可以使用索引卡或便签以物理形式表示,或者可以电子形式表示,例如文本文件,电子表格或存在的许多待办列表管理工具之一。对于拥有远程成员或收集有关产品待办列表项目的大量补充信息的团队而言,电子板是更好的选择。物理板的优点是可以在围绕产品待办列表的讨论期间使产品待办列表连续可见且具体。 ## 也称为 产品待办列表通常简称为待办列表。此项澄清了术语“产品待办列表”,以避免与sprint待办列表相混淆,后者是一个相关但不同的概念。 某些规模化框架引入了一系列待办列表,以取代产品待办列表。每种待办事项类型都旨在根据复杂的待办事项条目层次结构来包含特定的待办事项条目粒度: - 项目组合待办列表中包含组织正在考虑的不同计划(称为史诗)。 - 该溶液待办列表包含高水平待定项(被称为能力和引擎)代表的溶液的各方面 - 该程序待办列表包含表示溶液的方面待办列表物品(被称为特征)。 - 该团队待办列表包含待办列表的项目(用户故事等),一个团队工作的。 ## 预期收益 产品待办事项将充当占位符,以便将来就实现您期望的结果的选项进行对话。这意味着团队在将其添加到产品待办事项列表之前不必完全充实想法。将产品待办列表项目最初添加到产品待办列表中时,它仅需要具有足够的信息来提醒团队该选项是什么。仅当团队准备开始工作时,才需要完整描述产品待办事项。 产品待办列表的动态性质为团队提供了一种方法,以管理他们对所需结果的了解以及实现该结果的潜在方法。团队开始工作时,产品待办列表不需要完整,因此团队可以从最初的想法开始,并在他们了解更多时添加新的产品待办列表项目。 仅仅因为某些产品待办列表并不意味着必须交付该产品,所以团队就可以删除他们发现对实现预期结果没有帮助的产品待办列表项目。这意味着团队可以避免产生不会增加价值的多余输出,而不会花时间进行真正有价值的更改。 团队可以使用待办列表的产品来避免浪费时间,基于有限的信息来讨论一个选项是否有价值。当出现新想法时,团队可以添加产品待办事项作为提醒,以进一步调查该想法。然后,团队可以与其他项目一起优先考虑该想法,并且如果该想法不能为实现预期结果提供进展,则可以删除产品待办列表项目。 ## 常见陷阱 产品待办列表不应与需求文档混淆。虽然它是产品需求信息的切入点,但与需求文档有一些明显的区别: - 产品待办列表项目是必需的,但不足以描述产品的预期更改。对产品的完整理解来自于有关单个产品待办事项的对话以及团队选择记录有关产品待办事项的补充信息。 - 与需求文档中出现的内容相比,产品待办事项中包含产品待办事项不能保证将其交付。 - 与基线的需求文档和预期在特定点后不会更改的需求文档相反,产品待办列表随着对产品理解的发展而发展。 - 如果团队在确定产品待办列表管理方法之前开始使用电子工具,则该工具可以推动团队的产品待办列表管理方法。团队可能还迷于如何使用该工具,而不是选择最适合他们的过程。 产品待办列表的订单可能太大而无法有效管理。如果团队添加了为解决结果而提出的所有想法,但从未探索过这些想法或删除了无法交付的项目,则会发生这种情况。如果在团队进行工作之前将所有大型产品待办事项分解为较小的产品待办事项,产品待办事项的规模也可能会变得难以管理。 ## 进一步阅读 《Scrum指南》中的产品待办列表