生成和管理产品积压工作

项目
06/09/2015

作者：Mitch Lacey。所有者，Mitch Lacey & Associates，Inc，一家专门从事 Agile 和 Scrum 的采用和改进的咨询公司。

2012 年 1 月

在本文中，Mitch Lacey 解释了产品积压工作 (backlog) 的重要性，描述了适当的积压工作 (backlog) 的组成，并提供了一些创建和维护积压工作 (backlog) 的最佳做法。

应用于

应用程序生命周期管理；Team Foundation Server (TFS)

本文内容：

简介
产品积压工作 (backlog)
- 用户情景
- 估计
- 优先级
动态产品积压工作 (backlog)
- 梳理

产品积压工作 (backlog) 是按优先级排列的完成项目所需的所有特性和功能的列表。在 TFS 中，您可以使用工作项管理您的产品积压工作。您选择的工作项类型将根据用于创建团队项目的过程模板而有所不同。若要了解有关过程模板和它们支持的工作项类型的详细信息，请参阅使用团队项目内容，选择过程指南。

适当的产品积压工作 (backlog) 是所有正常运行的 Agile 团队的核心并都具有以下特性：

优先确保团队首先生成最重要的功能。
它由团队估计，以向产品所有者提供明确信息，使其能够回答诸如“这些情景将于何时完成？”之类的问题
它包含完成项目所需的所有工作。
它是一个动态文档，不断变更和演化以反映项目的当前现实。

适当的产品积压工作 (backlog) 并不能自动确保软件良好。但是，缺少适当的产品积压工作 (backlog) 通常会导致不符合客户和利益干系人要求的不完整软件。

管理产品积压工作 (backlog) 是全职工作。简单的技术可以帮助将非常艰巨且耗时的过程更改为交互的迭代过程，从而使团队成员、客户和利益干系人均可有效参与。因此，掌握扎实的技术来帮助你生成产品积压工作 (backlog)、为其设置优先级并进行维护非常重要。

产品积压工作 (backlog)

产品积压工作 (backlog) 是按优先级排列的、完成项目所需的所有特性和功能的动态总列表。产品积压工作 (backlog) 通常包括要求用户情景（例如，要求）、Bug、研究任务（峰值）和工程改进。在抽象单位（通常称为情景点）中估计这些项。

产品积压工作 (backlog) 包含项目将要求的所有工作，并随时间不断发展。因此，它们不仅包含产品的新功能，还包含 Bug 修复和研究 - 任何需要团队花费时间的操作。该团队将进行的所有工作都必须来自产品积压工作 (backlog)：它是进入项目的主要通道。如果产品积压工作 (backlog) 包含所有的工作，则产品所有者、团队和管理人员将能够更清楚地了解剩余的工作，并减少紧急意外的发生。

在任何项目开始时，拥有一个好的列表，该列表包含准备好进行估计并按优先级排列的干净且明确定义的产品积压工作 (backlog) 项，是不太可能的。相反，你可能会有一堆情景说明卡而且可能有一个或两个功能规范。作为产品所有者，你的工作是，通过某种顺序排序来消除此混乱，以便团队可以开始估计积压工作 (backlog)。

用户情景

第一步是将所有的想法和说明转换为用户情景，来表达最终用户所需的功能（软件应该做什么），而不是实现详细信息（如何创建满足这些要求的软件）。每个用户情景的标题都应遵循“As a <user>, I want <functionality> so that <reason>.”的格式。

故事卡示例

类似于产品积压工作 (backlog) 本身，每个用户情景将随时间发展。在项目过程中，你的团队将优先考虑并估计这些情景，向它们添加详细信息，并将它们分解为较小的情景或将其全部删除。实现那些放入冲刺 (sprint) 中的情景并将它们发送给你的客户。

若要读取有关用户情景的详细信息，请参考创建积压工作 (backlog)和使用 PowerPoint 撰写用户创意的情节提要。

在将所有的想法和说明转换为用户情景后，即可进行估计和设置优先级。

估计

根据定义，估计是不精确的。但是，借助时间、实践和整个团队的参与，你可以更好地创建相对准确的估计。第一步是集合团队，以提供对产品积压工作 (backlog) 项的估计。当团队估计每个情景时，他们借助抽象的度量单位（称为情景点）来估计情景的相对大小。

估计是必需的，这有两个原因：

它们可以帮助回答“我们什么时候会完成？”这个问题
它们可以帮助产品所有者确定每个项的优先级。

估计可以使产品所有者和团队了解特定情景的成本，从而帮助产品所有者设置情景之间的相对优先级。项目的估计越大，在时间和资源方面，实现它的开销就越大。因此，如果项目的成本很高，则在产品所有者意愿清单上这个原本排名很高的项目可能会降低优先级。

团队可以使用 Planning Poker、Big Wall 或其他技术来估计在情景点方面的工作。有关估计技术和情景点速成课的详细信息，请参阅估计和梳理和估计积压工作。

在团队估计完所有的情景后，即可设置优先级。

优先级

将设置所有产品积压工作 (backlog) 在业务价值和风险方面的优先级。产品所有者将积压工作 (backlog) 上的每个项与其他项进行比较，以确定其相对优先级。为此，产品所有者将考虑每个项的大小、其对业务的价值，以及任何关联的风险。然后，按优先级的递减顺序对项进行排序。高优先级的项显示在产品积压工作 (backlog) 的顶部或顶部附近，而低优先级的项位于底部或靠近底部。团队从最高优先级的项中为即将开始的冲刺 (sprint) 选择工作，以便首先完成最重要的项。

积压工作 (backlog) 中的每个项并非都大小相同。有些项可以在一个冲刺 (sprint) 中完成，但其他项可能非常大，以至于团队不能完全确定所涉及的操作或将需要多长时间来实现它们。没关系。当项靠近积压工作 (backlog) 的顶部时，团队会使它们变得更小且更集中，以便每个人更好地了解它们将在即将开始的冲刺 (sprint) 中解决的工作。

与估计一样，设置初始产品积压工作 (backlog) 的优先级可能会极其困难。如何有效平衡相互竞争的利益干系人的要求，同时考虑最终产品、风险和成本？幸运的是，存在多种技术使此任务变得更容易，其中包括革新方法和相对权重。有关这些和其他技术的详细信息，请参阅优先级和梳理和估计积压工作。

无论你选择何种优先级技术，都必须按顺序排列工作，以确保团队生成的功能可以为业务、利益干系人和客户提供最大价值。如果不设置工作优先级，在资源和计划更改时，交付低优先级（而非高优先级）的用户情景和交付不完整的用户情景的风险将增加。

（有关积压工作 (backlog) 项的性质的详细信息，请参阅创建积压工作 (backlog)和处理项目组合积压工作 (backlog)）。

动态产品积压工作 (backlog)

到目前为止我所描述的内容侧重于，从无到某个估计的并按优先级排列的产品积压工作 (backlog)。与要求文档不同，产品积压工作 (backlog) 并不是在项目开始时创建，然后便束之高阁。相反，产品积压工作 (backlog) 不断发展，并根据项目的现实进行展开和收缩。有些产品积压工作 (backlog) 项将变得无关且需要移除。其他项将冒泡到表面上，并需要将其分解为较小的情景。当其他要求出现时，将添加、估计新的用户情景并为其设置优先级。

尽管团队和利益干系人参与了创建和管理产品积压工作 (backlog)，但由产品所有者对其负最终责任。产品所有者必须确保积压工作 (backlog) 干净、按优先级排列并且是最新的，以便客户和团队清楚地了解项目发布的工作计划。即使在项目全面展开后，产品所有者仍然有很多工作要做，以保持产品积压工作 (backlog) 正常运行：

添加新的情景并设置其优先级
鉴于团队对情景有较好的了解，可以让他们估计新的情景并重新估计旧的情景。
与团队一起查看即将到来的用户情景以按需分解项。
会见客户和利益干系人以查看并添加要求

任何人均可在任何时候将项目添加到产品积压工作 (backlog)，但只有产品所有者可以设置它们的优先级。并且也只有产品所有者可以将优先级分配给情景。在添加情景时，团队的所有其他成员和利益干系人应将优先级保留为空白，即使他们使用的电子工具提示它们输入该信息时也是如此。

在添加情景时，产品所有者将基于他对情景的理解对其优先级进行初步评估。他将与该情景的创建者进行讨论以更好地理解它，并进而使其能够回答来自团队的问题。在每个冲刺 (sprint) 期间的预定时间，产品所有者将与团队会面以讨论新的情景并协作估计它们，以便他可以更准确地设置它们相对于积压工作 (backlog) 中其他情景的优先级。这个过程称为梳理积压工作 (backlog)。

梳理

如前所述，产品积压工作 (backlog) 梳理必须定期发生。

在 Scrum 中，团队应该在梳理活动中的每个冲刺 (sprint) 上花费 5％ - 15％的时间。该团队必须了解哪些情景即将发生和更改，以便他们可以分解任何优先级上升的大型情景，估计已创建的任何情景，并为即将到来的情景做一些紧急设计和规划。若要确保进行此操作，该产品所有者和团队应在每个冲刺 (sprint) 的计划会议期间，在冲刺 (sprint) 时留出一些时间来一起梳理积压工作 (backlog)。若要阅读有关冲刺 (sprint) 计划的详细信息，请参阅冲刺 (sprint) 计划和冲刺。

在为期两周的冲刺 (sprint) 期间，我希望在第二周召开此会议。这给予产品所有者足够的时间与客户和利益干系人进行有意义的对话、了解业务中的更改，并阐明用户情景和新的或优先级上升的情景。在冲刺 (sprint) 期间，这也是开始预计即将到来的冲刺 (sprint) 的合理时间。你可以决定何时召开会议。重要的是在冲刺 (sprint) 期间留出足够的时间来完成梳理活动。

在典型的梳理会议期间，产品所有者将演示新增内容、更改的内容和他对接下来的几个冲刺 (sprint) 的计划。除了估计新的情景并分解必须尽快完成的情景之外，在此会议期间，团队需要时间来检查系统的当前架构并规划或设计即将到来的功能。在此过程期间，情景估计经常更改，并且在将较大的情景分解为较小的情景后往往会出现新的情景。

此过程看起来简单，但也需要费些力气。若要使事情顺利进行，产品所有者必须准备好回答问题。如果产品所有者正在规划下一个冲刺 (sprint) 中要完成的情景，但不能提供团队进行良好估计所需的明确信息，冲突便会随之发生。如果这在冲刺 (sprint) 计划会议期间发生，则 Scrum 主管应指导产品所有者，告知其应该从客户和利益干系人处将什么样的信息带给团队。

每次梳理会议结束时，产品所有者应将更改发布给利益干系人和客户，以便每个人都可以查看新的内容、即将发生的事情，以及更新的发布计划。

好的产品积压工作 (backlog) 有助于确保你构建的软件拥有在你与客户和利益干系人的对话中标识的，并在你的用户情景中定义的最重要功能。你需要定期针对每个冲刺 (sprint) 主动联系利益干系人/用户组和团队。

建立好的积压工作 (backlog) 并不能确保好的系统，但缺少好的积压工作 (backlog) 多数情况下会导致你拥有的系统不符合客户要求。换言之，未能将积压工作 (backlog) 保持为最新在多数情况下会导致项目失败。

产品所有者是全职工作，而积压工作 (backlog) 是他们的责任。请认真对待这份工作。保持产品积压工作 (backlog) 的良好状态，你的客户会感谢你。