本文以 Visual Studio Team System (VSTS) 2010 的预发布版为基础。所有信息均有可能发生变更。
本文将介绍以下内容：
|
本文使用了以下技术： VSTS 2010、VSTS Process for Agile Software Development 1.0 |
目录 “敏捷规划”存在语意矛盾吗？希望您不会这样认为，但在最近于洛杉矶召开的一次专项小组会议中，其中一位与会者指出其组织已从敏捷开发转为采用更为正式的方法。在经过进一步的询问后，她坦承其团队无法再根据其经理的口头要求进行代码修复并立即将修复结果部署到生产中。现在，她不得不使用正式的程序。对她而言，即意味着放弃了敏捷开发。
实际上她对敏捷开发的理解并不准确，但是我非常高兴她的组织能够制订正式的更改流程。敏捷并不是指盲目进行加速或出于速度考虑才选择敏捷的。相反，它是一种符合标准的规划方法并且其中融入了经验数据。
Visual Studio Team System (VSTS) 2010 引入了一些新的特性和功能来帮助敏捷团队进行规划。在本文中，我将向您介绍一些全新的产品积压工作簿、小版本积压工作簿以及一组新报表，它们可以帮助敏捷团队规划和管理版本和小版本。
长期规划
人们总是担心没有精确的长期规划，这已成为推广敏捷方法的主要障碍。在 2008 年度敏捷开发状况调查中，缺乏事先规划是受访组织在采用敏捷方法时最关注的问题。我怀疑对许多人来说，缺乏精确的长期规划就等同于缺乏协同规划。敏捷团队选择多个层级的规划并在瀑布式规划过程中进行期间修正，当然本来就该如此。
Steve McConnell 在软件评估的不确定性圆锥中指出，在项目中过早进行评估可能会得出不准确的结果，偏向高边的错误最高会达到 400%：“在项目早期，待构建软件本质的具体细节、特定需求的细节、解决方案的细节、项目规划、人员构成以及其他项目变数均不确定。这些因素的可变性会导致项目评估的可变性。”
当然，这并不意味着主管人员的管理策略是“我们不知道项目何时能完成，也不知道完成时会是什么样子”。它实际上是想说明团队规划版本的方法以及各版本中所完成工作的范围均存在变数。
.gif)
图 1 产品和小版本积压
版本和小版本规划
对于敏捷团队而言，规划是在以下两个截然不同的层级完成的：版本规划和小版本规划。版本规划是一项高级规划活动，用于帮助敏捷团队查看各种功能或用户案例。积压中的项目随后被依次堆叠、评估并分配给一组小版本。请注意，在此阶段使用的是诸如 T 恤尺寸（小、中、大）等单位来执行评估的。其目的是粗略评估积压中各个项目的成本，而非精确的报价。这也有助于客户根据心目中的大致尺寸来依次堆叠需求。
在 Scrum 中，这组用户案例被存放在一个名为“产品积压”的列表中（请参见图 1）。每个小版本中需要处理的工作范围主要取决于团队进度。版本的定义主要取决于按照客户要求完成一组可靠需求的时间。例如，如果需要四个小版本才能实现第一组功能，则预计在第四个小版本后能形成第一个版本。
小版本规划是一项更为详细的规划活动，它在每个小版本开始之前执行。来自产品积压的高级用户案例将在核查后根据需要拆分成较小的用户案例。此时，团队已准备好将用户案例拆分成较小的案例并定义完成用户案例所需的任务。然后将会以小时为单位评估这些用户案例及相关联的任务。此时，团队可以了解到小版本的范围。
在敏捷团队的工具箱中，除索引卡和便笺外，经常还会发现 Microsoft Office Excel 这一工具。VSTS 2010 引入了两个新的 Excel 工作簿来帮助敏捷团队管理产品积压和小版本积压。但在介绍这两个工作簿之前，让我们先来快速了解一下 VSTS 2010 附带的新 Agile 过程模板。
VSTS 中的过程模板包括工作项类型、查询、报表以及文本指南。在这里工作项是关键实体。工作项可以是用户案例、任务、错误等。首先，在 Team Foundation Server (TFS) 中建立一个团队项目，然后在“New Team Project Wizard”（新建团队项目向导）中选择 VSTS Process for Agile Software Development v1.0 模板。此模板包括以下工作项类型：
- 任务
- 用户案例
- 错误
- 问题
- 测试用例
您可以创建自己的工作项类型或自定义特定的工作项。要了解更多有关工作项自定义的信息，请参阅 Brian Randell 在 2008 年 12 月撰写的有关使用和自定义 TFS 过程模板的文章：“Team System：使用过程模板简化团队项目”。
接下来，我们将深入探讨 Excel 工作簿并了解这些工作项在开发过程中的流动方式以及它们如何帮助用户规划和管理价值流。
VSTS 2010 Excel 工作簿
在“敏捷性工具”一文中，Kent Beck 讨论了敏捷团队中存在的大量转换以及在考虑转换时对工具的需求。基于 Excel 的规划工作簿与 TFS 工作项跟踪的集成有助于最大程度地降低转换开销。通过使产品积压和小版本积压保持同步，可自动将用户案例或任务工作项的状态更新信息捕获到小版本积压中以生成各种报表，许多常见活动要么被淘汰，要么被优化。
在使用 VSTS 2010 来管理产品积压和小版本积压时，建议敏捷团队使用以下流程：
- 使用 VSTS 2010 Agile 模板新建一个团队项目。
- 通过将用户案例添加到产品积压工作簿或通过在 Visual Studio 中添加工作项来构建产品积压。
- 根据各个项目在产品积压中的堆叠顺序，将其分配到某个小版本。默认情况下会创建 Iteration 0、Iteration 1 和 Iteration 2。可使用团队项目设置来创建更多的小版本。
- 设置查询以从特定小版本中提取用户案例、任务及其他工作项，并将其映射到对应的小版本积压工作簿中。
这些工作簿与 TFS 之间的集成是通过查询实现的。图 2 显示了产品积压工作簿的配置。在 Excel 功能区中，在“Team”（团队）选项卡上选择“Work Items”（工作项）组，然后单击“Configure List”（配置列表）。这将打开“Configure List Properties”（配置列表属性）对话框。在这个对话框中，可选择一个 TFS 查询，而此查询的结果正是电子表格中所显示的内容。
.gif)
图 2 Excel 工作簿中的查询
查询是在团队项目中创建的。默认情况下，在建立团队项目时，会创建一个名为 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 中完成。很显然，在开始一个新项目时，首先要从空白工作簿开始构建这些高级用户案例。
.gif)
图 3 产品积压工作簿
这些电子表格上的各列是工作项中的字段，它们依次存储在 TFS 数据存储库中。Excel 和 TFS 之间的集成会使 Excel 中增加一个“Team”（团队）功能区（请参见图 4），利用其中的菜单项可将积压中的项目发布到 TFS 中、可利用 TFS 中更新的工作项来刷新积压，此外还有许多其他功能。
.gif)
图 4 Excel 功能区中的 Team 选项卡
积压中的每一行都被存储为 TFS 中的一个工作项，如图 5 所示。经过这种形式的集成后，使用 Visual Studio 的团队成员现在可从 Visual Studio 自身中更新用户案例和其他工作项。现在，不必在不同工具之间进行切换即可更新用户案例、评估结果或剩余工作的状态。
.gif)
图 5 TFS 中的工作项
容量规划
作为版本规划的一部分，敏捷团队将在电子表格中花费大量时间来新增用户案例、对其进行评估，以及更为重要的，确定它们的优先级。但是，密切关注版本的状态也同样非常重要。产品积压工作簿包括一个容量规划工作簿。通过评估用户案例及其工作所在的小版本，此工作簿可对小版本自身的快速处理提供很大帮助。
容量规划是规划版本时的一项重要活动。它有助于了解可在各个小版本中完成的功能。此计算中的关键数据点是进度。进度是在某个小版本中，团队所完成的工作量。如果恰好有来自先前小版本的数据，则它将是最佳入手点。
.gif)
图 6 使用先前的小版本来计算进度
这通常被称为“根据昨天的天气进行预报”。实际上，如果 TFS 数据仓库可用，则容量规划电子表格可从其中提取历史数据。如图 6 所示，我可以选择 Iteration 1 作为从中获取历史数据的小版本，并可以键入开始日期、结束日期以及团队成员数。在本例中，进度为 816 小时，这意味着团队可以在 Iteration 1 中完成 816 个小时的工作。如果对此数据不满意，团队可以在开始时使用一个估计值，而在规划未来的小版本时使用第一个小版本的进度。
在容量规划电子表格中，可指定小版本的日期范围、团队成员的数量以及小版本期间的任何中断情况（如节假日）。通过将此数据与用户案例评估和进度相结合，可创建一个能够大体给出小版本工作负荷的图表。如果发现评估的工作超过了预期的容量限制，则您可能会希望在不同的小版本之间移动用户案例以得到一个合理的分配。
在我的示例中，我并未在 Iteration 2 中规划任何工作。我可以将积压中的一些剩余用户案例添加到 Iteration 2 中。现在，容量图表将如图 7 所示。这是一种非常不错的情形——评估工作并没有超出容量限制。
.gif)
图 7 为小版本 Iteration 2 分配了工作的容量图表
项目启动后，也可以使用产品积压工作簿来了解各种用户案例的整体状态。但是，通过“剩余工时和进度”、“剩余工作”和“案例进展”等报表可以了解更为详细的信息。这些报表均包括在 Agile 模板中，可在团队项目的 Report 文件夹中找到。我将在本文的稍后部分介绍这些报表。
小版本积压工作簿
小版本是敏捷团队的一项关键活动。经常使用 Scrum 的敏捷团队非常熟悉它，将其称为“冲刺”。小版本的持续时间通常各不相同。对于使用极限编程的团队，小版本的周期为一到两周；而使用 Scrum 的团队通常有为期四周的冲刺。
小版本规划有助于定义特定小版本的范围。在小版本规划会议期间，团队通常会分析针对特定小版本分配的用户案例、收集详细的需求信息、添加相关联的任务以及评估完成每项任务所需的时间。在此会议中，产品拥有者以及团队其余成员将根据以下因素来确定用户案例的优先级：依赖关系、成本评估、详细需求以及特定案例的重要性不如当初预期的可能证据。
首先，我们来看一下 DinnerNow 团队项目中的小版本积压。在团队项目中的 Shared Documents 文件夹下包含名为 Iteration 0、Iteration 1 和 Iteration 2 的文件夹。在其中的每个小版本文件夹中，您都会看到小版本积压。每个小版本积压工作簿都会连接到一个特定查询，它只针对该特定小版本用户案例和任务。
如果添加了其他工作项类型（如功能、主题或事迹），则需要将其添加到此查询中，以便可以在列表中提取出这些额外工作项。DinnerNow 团队项目中已有多个任务被作为子项添加到 Iteration 2 的用户案例中。但通常情况下，作为小版本规划会议的一部分，团队会添加这些任务并对其进行评估以得到一个满意的 Iteration 2 小版本规划。图 8 显示了小版本积压。
.gif)
图 8 包含子任务的小版本积压
TFS 现在支持分层工作项，这将允许您创建父/子树。在本例中，以下新任务被作为子任务添加到用户案例“用户应该能够通过手机使用 DinnerNow”中：
- 确定 UI 的哪些部分用于手机
- 针对 UI 使用卡堆栈体系结构
- 识别大多数大众化手机
- 减少下订单时所需的按键次数
此时，团队已做好了进行任务分配的准备。每个团队成员在选择工作量时需要考虑的因素包括该小版本的团队成员容量、领域专门技术以及团队成员加入团队的时间长短。
小版本积压工作簿还包含一些附加表单，可帮助在规划和执行时处理其他方面的问题。容量规划工作簿类似于产品积压工作簿中的工作簿。可使用此工作簿来了解团队的容量。
在规划期间以及小版本自身执行期间，负载平衡工作簿将派上用场。当出现有关某个特定用户案例的最新信息时、当发现针对某个任务的技术依赖关系时或者当某个团队成员变为不可用时，敏捷团队将在整个小版本过程中持续进行规划以执行期间修正。这些具体情况要求更新任务分配，而这正是负载平衡工作簿发挥作用的地方。
另一有趣的工作簿是用于进度跟踪的工作簿。熟悉板球运动的人们都知道术语“当前得分率”和“所需得分率”。这两个统计数据可以准确给出某个团队在比赛中的表现。通常情况下，如果所需得分率高于当前得分率，则击球团队必须加快速度才能避免失败。另一方面，如果当前得分率高于所需得分率，则表明击球团队形势不错。
在熟悉板球的读者邀请我打球之前，我想说的是其他统计数据（如出局人数和剩余轮数）对于全面了解比赛情况而言也都非常重要。在敏捷项目中也同样如此。进度跟踪表可让您快速了解在某个小版本中完成用户案例的当前团队进度和所需进度。就像板球一样，其他统计数据（如剩余天数）对于全面了解您在小版本中的进展情况也十分重要。例如，如果当前进度赶不上所需进度，则团队可能不得不缩小范围。再次重申，关键在于要让客户了解这种状况并对团队进行必要的调整。
报表
当然，您不必成为一位狂热的板球迷也可以开始利用 VSTS 2010 来管理项目。您可以借助各种报表来监视项目的进展情况（如剩余工时和剩余工作）。
图 9 显示了 Iteration 1 的剩余工时报表。剩余工时报表显示出已完成工作的小时数、剩余工作的小时数以及进度。从图表中的剩余小时数可以看出，团队并未完成分配给此小版本的所有任务。
.gif)
图 9 剩余工时图表
趋势线也显示了这一状态。正如图表所显示的，实际趋势线表明在 Iteration 1 中，按照此团队的速度将无法准时完成工作。在此小版本过程中，团队可监视剩余工时并进行必要的期间修正，也可以让客户了解到发布计划可能会受到影响。
剩余工作报表也非常有用。如图 10 所示，团队在完成工作的过程中始终保持稳定的进度。在此小版本过程中，未向积压添加任何额外工作，这是一个好迹象。在接近小版本终点的时候，团队的进度也逐渐放缓，并导致未能完成任务。
.gif)
图 10 剩余工作
正如您看到的，VSTS 2010 的敏捷规划工具和工作簿为团队提供了一个 Excel 前端，此外还提供了从版本规划到小版本规划以及从测试执行到编译质量等过程中捕获和挖掘数据的集成数据存储库。这为规划和管理敏捷项目的经理和团队中的开发和测试人员提供了一个极好的工具——使得他们可以协同工作、评估进度、必要时进行更改以及管理整个项目。此集成消除了敏捷团队在收集数据和生成报表时需要执行的许多手动和单调的活动。
如需更加倚重数学原理的不同方法来实现高级规划，请参考 James McCaffrey 博士撰写的有关此问题的测试运行专栏。
Ajoy Krishnamoorthy 是 Microsoft 模式和实施方案小组的产品规划主管。在此之前，Ajoy 是 Microsoft Visual Studio Team System 的高级产品经理。其间 Ajoy 负责产品管理、战略和市场营销。他在曾担任过的多个职务（包括开发人员、架构师和技术项目经理）方面拥有超过 10 年的咨询经验。您可以浏览其博客，网址为：blogs.msdn.com/ajoyk。