查询是在团队项目中创建的。默认情况下，在建立团队项目时，会创建一个名为 Work Items\Team Queries\Workbook Queries 的文件夹。在此文件夹下，您会发现有关产品积压和小版本积压工作簿的默认查询。
为了更好地理解工作簿的工作原理，让我们看一看 2008 年 10 月发布的 VSTS 2010 和 .NET Framework 4.0 CTP 中包含的 DinnerNow 示例应用程序。(可以在 Team Suite 开发人员中心找到最新的 CTP 下载。)产品积压和小版本积压工作簿均可在团队资源管理器的 \DinnerNow\Documents\Shared Documents 文件夹中找到。
产品积压工作簿
产品积压主要用作应用程序中客户所需的需求列表。我听说有些团队在指代一组高级需求时也使用事迹或主题之类的术语。将这组需求收集到一个列表中、确定其优先级并在较高级别评估它们，这些操作可帮助回答此规划阶段的两个重要问题：
1. 应用程序有哪些需求?
2. 它的价格是多少?很显然，其答案只能通过评估得出。我曾看到过有的团队在此阶段使用案例分数、T 恤尺寸或小时来进行评估。
通过回答这些问题，团队可以更好地了解此版本或接下来的几个版本的大致情况以及这些版本的预计完成时间。通常会存在预算或计划限制，如即将进行的广告活动、法律要求或季节性活动等。这有助于规划版本的范围，因为您可以根据此限制来管理版本的范围。
如果为版本设置了目标日期，则在发布时间框架内，可通过确定将哪些需求包括在小版本中来管理工作范围。例如，如果规划始于 12 月而发布日期定在 6 月，则实际上需要运行四到五个小版本(假定为一个月的小版本)才能完成此工作。
如果目标日期比较灵活，则发布计划将取决于完成最低限度的一组需求所需的时间。例如，如果可以在三个小版本内完成最低限度的一组必需功能，则可以设置在三个小版本后出现版本 1。如果可在五或六个小版本内完成下一组功能，则设置在这五或六个小版本后出现版本 2。
图 3 显示了 DinnerNow 项目的产品积压工作簿。您看到的是用户案例的积压。在这些用户案例中，其中多个已被分配给特定的小版本，并且某些已在 Iteration 0 和 Iteration 1 中完成。很显然，在开始一个新项目时，首先要从空白工作簿开始构建这些高级用户案例。
图 3 产品积压工作簿
这些电子表格上的各列是工作项中的字段，它们依次存储在 TFS 数据存储库中。Excel 和 TFS 之间的集成会使 Excel 中增加一个“Team”(团队)功能区(请参见图 4)，利用其中的菜单项可将积压中的项目发布到 TFS 中、可利用 TFS 中更新的工作项来刷新积压，此外还有许多其他功能。
图 4 Excel 功能区中的 Team 选项卡
积压中的每一行都被存储为 TFS 中的一个工作项，如图 5 所示。经过这种形式的集成后，使用 Visual Studio 的团队成员现在可从 Visual Studio 自身中更新用户案例和其他工作项。现在，不必在不同工具之间进行切换即可更新用户案例、评估结果或剩余工作的状态。
图 5 TFS 中的工作项
容量规划
作为版本规划的一部分，敏捷团队将在电子表格中花费大量时间来新增用户案例、对其进行评估，以及更为重要的，确定它们的优先级。但是，密切关注版本的状态也同样非常重要。产品积压工作簿包括一个容量规划工作簿。通过评估用户案例及其工作所在的小版本，此工作簿可对小版本自身的快速处理提供很大帮助。
容量规划是规划版本时的一项重要活动。它有助于了解可在各个小版本中完成的功能。此计算中的关键数据点是进度。进度是在某个小版本中，团队所完成的工作量。如果恰好有来自先前小版本的数据，则它将是最佳入手点。
图 6 使用先前的小版本来计算进度
这通常被称为“根据昨天的天气进行预报”。实际上，如果 TFS 数据仓库可用，则容量规划电子表格可从其中提取历史数据。如图 6 所示，我可以选择 Iteration 1 作为从中获取历史数据的小版本，并可以键入开始日期、结束日期以及团队成员数。在本例中，进度为 816 小时，这意味着团队可以在 Iteration 1 中完成 816 个小时的工作。如果对此数据不满意，团队可以在开始时使用一个估计值，而在规划未来的小版本时使用第一个小版本的进度。
文章来源于领测软件测试网 https://www.ltesting.net/
