在容量规划电子表格中，可指定小版本的日期范围、团队成员的数量以及小版本期间的任何中断情况(如节假日)。通过将此数据与用户案例评估和进度相结合，可创建一个能够大体给出小版本工作负荷的图表。如果发现评估的工作超过了预期的容量限制，则您可能会希望在不同的小版本之间移动用户案例以得到一个合理的分配。
在我的示例中，我并未在 Iteration 2 中规划任何工作。我可以将积压中的一些剩余用户案例添加到 Iteration 2 中。现在，容量图表将如图 7 所示。这是一种非常不错的情形——评估工作并没有超出容量限制。
图 7 为小版本 Iteration 2 分配了工作的容量图表
项目启动后，也可以使用产品积压工作簿来了解各种用户案例的整体状态。但是，通过“剩余工时和进度”、“剩余工作”和“案例进展”等报表可以了解更为详细的信息。这些报表均包括在 Agile 模板中，可在团队项目的 Report 文件夹中找到。我将在本文的稍后部分介绍这些报表。
小版本积压工作簿
小版本是敏捷团队的一项关键活动。经常使用 Scrum 的敏捷团队非常熟悉它，将其称为“冲刺”。小版本的持续时间通常各不相同。对于使用极限编程的团队，小版本的周期为一到两周;而使用 Scrum 的团队通常有为期四周的冲刺。
小版本规划有助于定义特定小版本的范围。在小版本规划会议期间，团队通常会分析针对特定小版本分配的用户案例、收集详细的需求信息、添加相关联的任务以及评估完成每项任务所需的时间。在此会议中，产品拥有者以及团队其余成员将根据以下因素来确定用户案例的优先级：依赖关系、成本评估、详细需求以及特定案例的重要性不如当初预期的可能证据。
首先，我们来看一下 DinnerNow 团队项目中的小版本积压。在团队项目中的 Shared Documents 文件夹下包含名为 Iteration 0、Iteration 1 和 Iteration 2 的文件夹。在其中的每个小版本文件夹中，您都会看到小版本积压。每个小版本积压工作簿都会连接到一个特定查询，它只针对该特定小版本用户案例和任务。
如果添加了其他工作项类型(如功能、主题或事迹)，则需要将其添加到此查询中，以便可以在列表中提取出这些额外工作项。DinnerNow 团队项目中已有多个任务被作为子项添加到 Iteration 2 的用户案例中。但通常情况下，作为小版本规划会议的一部分，团队会添加这些任务并对其进行评估以得到一个满意的 Iteration 2 小版本规划。图 8 显示了小版本积压。
图 8 包含子任务的小版本积压
TFS 现在支持分层工作项，这将允许您创建父/子树。在本例中，以下新任务被作为子任务添加到用户案例“用户应该能够通过手机使用 DinnerNow”中：
确定 UI 的哪些部分用于手机
针对 UI 使用卡堆栈体系结构
识别大多数大众化手机
减少下订单时所需的按键次数
此时，团队已做好了进行任务分配的准备。每个团队成员在选择工作量时需要考虑的因素包括该小版本的团队成员容量、领域专门技术以及团队成员加入团队的时间长短。
小版本积压工作簿还包含一些附加表单，可帮助在规划和执行时处理其他方面的问题。容量规划工作簿类似于产品积压工作簿中的工作簿。可使用此工作簿来了解团队的容量。
在规划期间以及小版本自身执行期间，负载平衡工作簿将派上用场。当出现有关某个特定用户案例的最新信息时、当发现针对某个任务的技术依赖关系时或者当某个团队成员变为不可用时，敏捷团队将在整个小版本过程中持续进行规划以执行期间修正。这些具体情况要求更新任务分配，而这正是负载平衡工作簿发挥作用的地方。
另一有趣的工作簿是用于进度跟踪的工作簿。熟悉板球运动的人们都知道术语“当前得分率”和“所需得分率”。这两个统计数据可以准确给出某个团队在比赛中的表现。通常情况下，如果所需得分率高于当前得分率，则击球团队必须加快速度才能避免失败。另一方面，如果当前得分率高于所需得分率，则表明击球团队形势不错。
在熟悉板球的读者邀请我打球之前，我想说的是其他统计数据(如出局人数和剩余轮数)对于全面了解比赛情况而言也都非常重要。在敏捷项目中也同样如此。进度跟踪表可让您快速了解在某个小版本中完成用户案例的当前团队进度和所需进度。就像板球一样，其他统计数据(如剩余天数)对于全面了解您在小版本中的进展情况也十分重要。例如，如果当前进度赶不上所需进度，则团队可能不得不缩小范围。再次重申，关键在于要让客户了解这种状况并对团队进行必要的调整。
文章来源于领测软件测试网 https://www.ltesting.net/
