在 Azure Boards 中将要求安排到产品计划中
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
在充分地分析客户需求以了解产品应具备的功能后，必须制定一份实现该产品的计划。 或者，对于现有产品，必须找出所缺少的功能并制定一份更改计划。 但要求不会自动告诉你计划。
本文概述了从一组要求开始获取计划的方法。 此方法是可在 Visual Studio 上使用的各种方法之一，应对其进行调整，使其符合你的需求。
可以使用 积压工作 和 项目组合积压工作 来定义和映射要求和功能。
查看要求和功能
此方法中有两类要求：客户需求和功能。 客户要求是通过分析客户想要从产品中获取的内容而得到的要求。 功能是产品计划中与一小部分客户要求相对应的项。 每个功能可能包含多个客户需求片段，这些片段源自用户体验的不同方面和不同功能区域。
客户要求
客户要求通过与预期用户和其他利益干系人进行商讨来确定。
为了帮助分析这些要求，通常会创建情节提要和模型，并将方案分解为较小的步骤，形成树。 可以将建模元素（如用例和活动）链接到方案工作项。
有两种类型的客户要求：
方案（也称为用例）用于表示为实现特定目标而在用户和产品之间进行交互的序列。 示例方案可以采用标题“用户购买书籍”。
服务质量要求包括性能、安全性、可用性和其他条件。
可以将这些要求表示为要求类型的工作项，并将“要求类型”字段设置为“方案”或“服务质量”。 有关详细信息，请参阅 开发要求。
应将这些需求工作项链接到系统测试，以便可以确保测试所有需求。 请参阅 “创建测试计划”。
查看积压工作 或打开客户要求查询以列出这些要求工作项。
使用 “要求进度 ”报告监视已满足哪些要求。
功能
功能是产品计划中表示一组任务的项。 制定产品计划时，开发团队代表和利益干系人为迭代分配功能。 有关详细信息，请参阅 计划项目。
将功能输入为需求工作项，并将“需求类型”字段设置为“功能”。
该功能的游戏状态，在用户的术语中，用户可以对产品执行的操作，他们在以前的迭代中无法执行。 计划中没有项目或少量项目，不会提供新的用户值。
例如，以下功能序列可形成一个实现计划：
“购买者可以从列表中挑选书籍，并将其添加到愿望列表中。”
“书籍列表显示价格。 在愿望列表中显示总价格。”
“供应商可以为书籍附加标记。 购买者可以按照标记‘筛选书籍列表。”
请注意，没有任何功能仅涉及用户体验中的一个步骤，并且没有任何功能仅涉及产品体系结构的一个部分。 相反，随着功能的实现，会重新访问多个函数，并使用新的用户值进行扩充。
功能在产品计划期间分配给迭代。 必须将某一功能下的所有任务分配给同一迭代。
功能描述对客户要求的部分实现。 它是客户要求的子集，在有限范围内可能实现每个客户要求。
每个功能都可以链接到一个或多个测试用例，这些用例测试该功能表示的部分需求。 这些测试用例是链接到客户需求的系统测试的一部分。
在完全定义和通过功能的测试之前，功能的状态不能标记为已完成。
每种功能都是一组开发和测试任务。 它是任务树的根目录。 开发任务实现该功能描述的部分需求。 测试任务设计并执行相应的测试用例。
使用“产品要求”查询可列出功能。
查找功能
将要求划分到渐进式功能中是一项创造性任务，它需要开发人员、分析人员和利益干系人的共同参与才能完成。 功能定义了产品的某一部分功能，可以切合实际地独立于周边其他功能独立实施。 因此，一组可行的功能定义和对计划的排序部分取决于系统的体系结构。
为此，产品的计划和初始设计必须同时进行，尤其是在迭代 0 中，在该迭代中，将制定计划的大部分草图。
将方案分解为较小的步骤
若要帮助将需求安排到功能中，将方案分解为多个更小的步骤会很有帮助。
情节提要通常有助于此活动。 情节提要是用于演示方案一系列图片。 UML 活动图有助于显示备选路径，UML 序列图有助于讨论多个参与者之间的交互。 使用这些工具分析方案后，可以将分解的方案输入到团队资源管理器中。 通过此操作可将测试用例链接到方案，并确保满足要求。 有关详细信息，请参阅 UML 活动关系图：指南 和 UML 序列图：指南。
功能 - 在每次迭代中完成的需求
功能是对用户在每次迭代完成后可执行的功能进行汇总的需求。 可以为每次迭代创建多个功能。 将功能输入为要求工作项，并将“要求类型”设置为“功能”。
使用方案到工作项的分配方式帮助你定义功能。 以下的示例功能计划派生自上一节中方案到迭代的分配方式：
迭代 1
- 客户从菜单中选择菜品，将它们添加到订单中，并添加送餐地址。
迭代 2
客户首先显示餐馆列表，然后选择一家餐馆。
客户完成订单后，订单将显示在所选餐馆的屏幕上。
订单上将显示菜品价格和总价。
迭代 3
派送准备好的食物后，餐馆会将订单标记为“完成”。 针对餐馆记录餐饮。
每家餐都馆可以输入和更新其菜单。
客户可以浏览各餐馆的菜单，然后选择某家餐馆。
迭代 4
客户在完成订单后输入付款详细信息。 餐馆将订单标记为“已完成”之后，将在客户提供的卡中扣除相应费用。
为标记为“已完成”的订单向餐馆付款。
迭代 5
- 餐馆可以设置它们的送餐区域。 客户在会话开始时输入邮政编码。 网站仅显示可向当地区域送餐的餐馆。
部分实现的方案
将方案分解为多个小步骤有助于你将某些可在早期实现的步骤与其他可在稍后实现的步骤区分。
但有时可以区分出方案的其他方面。 在本示例中，团队可以在早期迭代中实现用户体验的基本版本，并在稍后进行改进。 因此，你可以添加以下功能：
迭代 6 - 餐馆可以选择其菜单的配色方案和字体，并上传自己的徽标和餐饮图片。
这种类型的功能不会直接从分解成步骤中浮出水面，但它通常出现在情节提要的讨论中。 用户体验功能适用于后续迭代。
输入并检查功能
创建工作项类型为需求的工作项，并将“需求类型”字段设置为“功能”。 将功能标题设置为简短描述。
跟踪需求的功能
可以通过以下方式将功能链接到要求：
将功能工作项链接到其迭代的叶方案要求。 使用相关项链接链接链接，因为叶方案已有父级。
将测试用例工作项链接到其测试的方案和服务质量需求。 在已开发功能时，将功能链接到应通过的部分测试用例。 通过这种方式，测试用例充当功能和客户需求之间的链接。
为每个服务质量功能创建工作项
软件设计中普遍存在服务质量要求。 例如，安全要求与特定开发任务无关。
尽管如此，应为每个服务质量需求创建一个功能工作项，该工作项的子级主要为测试任务，用于确保满足服务质量条件。 这些工作项称为服务质量功能。
某些服务质量功能可以包含开发任务。 在早期迭代中，你可以实现仅处理少数用户作为概念证明的系统版本。 在后续迭代中，可以按照客户需求的规定添加指定目标能力的功能。
查看产品计划
在每次迭代开始时之前，召开产品计划评审会议。 第一个产品规划会议创建计划，以后的会议会根据以前的迭代对其进行评审。 有关详细信息，请参阅 “规划项目”。
在产品计划评审过程中，围绕功能与业务利益干系人展开讨论，做好重新设置功能优先级的准备，并将这些功能安排到不同迭代。 会议应包括业务利益干系人和开发团队代表。
会议将讨论功能的开发顺序。 可以通过投影或屏幕共享产品要求查询的 Office Excel 视图，并通过迭代对功能进行排序来完成。
另一种方法是按特定顺序放置功能，然后考虑每次迭代中可以完成的功能数。 例如，开发人员可能会讨论是否应将迭代 2 中的“客户可以显示价格”移至迭代 3，而不在此序列中移动它。 若要将项放入序列，请向电子表格添加名为“级别”的额外的列，并插入表示顺序的整数。 按此列对电子表格排序。 排名不会存储在 Team Foundation Server 中，但可以保存电子表格。 再次打开电子表格时，选择工作项表中的任何单元格，然后在“团队”选项卡上选择“刷新”。
产品计划会考虑功能优先级和开发成本。 优先级由业务利益干系人提供，并辅以开发人员提供的有关风险的某些指南。 成本估计由开发人员提供。 为了准确估计成本，开发团队必须已对产品体系结构开展了某些工作，并且可能需要从早期迭代中汲取一些经验。 为此，应在每次产品计划评审时完善成本估计。
规划迭代
在产品计划评审之后计划迭代。 产品计划确定在迭代结束时将交付的功能。 迭代计划确定为了实现和测试功能团队将进行的工作。
以下活动是迭代计划的一部分：
创建用于开发和测试的任务，并将这些任务作为子级链接到功能要求。
针对要在每个功能中制定的客户需求方面创建测试用例。 测试用例应链接到客户需求，以便可以监视需求的完成度。
也可以将测试用例链接到功能，以便可以跟踪功能和客户需求之间的对应关系。 在链接的测试用例通过之前，请勿标记功能完成。
有关详细信息，请参阅 计划迭代。