搜索
VisualStudioTeamSystem2010中的敏捷规划工具本文以VisualStudioTeamSystem(VSTS)2010的预发布版为基础。所有信息均有可能发生变更。本文将介绍以下内容：产品和小版本规划产品积压工作簿容量规划和报表小版本积压工作簿本文使用了以下技术：VSTS2010、VSTSProcessforAgileSoftwareDevelopment1.0目录长期规划版本和小版本规划VSTS2010Excel工作簿产品积压工作簿容量规划小版本积压工作簿报表“敏捷规划”存在语意矛盾吗？希望您不会这样认为，但在最近于洛杉矶召开的一次专项小组会议中，其中一位与会者指出其组织已从敏捷开发转为采用更为正式的方法。在经过进一步的询问后，她坦承其团队无法再根据其经理的口头要求进行代码修复并立即将修复结果部署到生产中。现在，她不得不使用正式的程序。对她而言，即意味着放弃了敏捷开发。实际上她对敏捷开发的理解并不准确，但是我非常高兴她的组织能够制订正式的更改流程。敏捷并不是指盲目进行加速或出于速度考虑才选择敏捷的。相反，它是一种符合标准的规划方法并且其中融入了经验数据。VisualStudioTeamSystem(VSTS)2010引入了一些新的特性和功能来帮助敏捷团队进行规划。在本文中，我将向您介绍一些全新的产品积压工作簿、小版本积压工作簿以及一组新报表，它们可以帮助敏捷团队规划和管理版本和小版本。长期规划人们总是担心没有精确的长期规划，这已成为推广敏捷方法的主要障碍。在2008年度敏捷开发状况调查中，缺乏事先规划是受访组织在采用敏捷方法时最关注的问题。我怀疑对许多人来说，缺乏精确的长期规划就等同于缺乏协同规划。敏捷团队选择多个层级的规划并在瀑布式规划过程中进行期间修正，当然本来就该如此。SteveMcConnell在软件评估的不确定性圆锥中指出，在项目中过早进行评估可能会得出不准确的结果，偏向高边的错误最高会达到400%：“在项目早期，待构建软件本质的具体细节、特定需求的细节、解决方案的细节、项目规划、人员构成以及其他项目变数均不确定。这些因素的可变性会导致项目评估的可变性。”当然，这并不意味着主管人员的管理策略是“我们不知道项目何时能完成，也不知道完成时会是什么样子”。它实际上是想说明团队规划版本的方法以及各版本中所完成工作的范围均存在变数。图1产品和小版本积压版本和小版本规划对于敏捷团队而言，规划是在以下两个截然不同的层级完成的：版本规划和小版本规划。版本规划是一项高级规划活动，用于帮助敏捷团队查看各种功能或用户案例。积压中的项目随后被依次堆叠、评估并分配给一组小版本。请注意，在此阶段使用的是诸如T恤尺寸（小、中、大）等单位来执行评估的。其目的是粗略评估积压中各个项目的成本，而非精确的报价。这也有助于客户根据心目中的大致尺寸来依次堆叠需求。在Scrum中，这组用户案例被存放在一个名为“产品积压”的列表中（请参见图1）。每个小版本中需要处理的工作范围主要取决于团队进度。版本的定义主要取决于按照客户要求完成一组可靠需求的时间。例如，如果需要四个小版本才能实现第一组功能，则预计在第四个小版本后能形成第一个版本。小版本规划是一项更为详细的规划活动，它在每个小版本开始之前执行。来自产品积压的高级用户案例将在核查后根据需要拆分成较小的用户案例。此时，团队已准备好将用户案例拆分成较小的案例并定义完成用户案例所需的任务。然后将会以小时为单位评估这些用户案例及相关联的任务。此时，团队可以了解到小版本的范围。在敏捷团队的工具箱中，除索引卡和便笺外，经常还会发现MicrosoftOfficeExcel这一工具。VSTS2010引入了两个新的Excel工作簿来帮助敏捷团队管理产品积压和小版本积压。但在介绍这两个工作簿之前，让我们先来快速了解一下VSTS2010附带的新Agile过程模板。VSTS中的过程模板包括工作项类型、查询、报表以及文本指南。在这里工作项是关键实体。工作项可以是用户案例、任务、错误等。首先，在TeamFoundationServer(TFS)中建立一个团队项目，然后在“NewTeamProjectWizard”（新建团队项目向导）中选择VSTSProcessforAgileSoftwareDevelopmentv1.0模板。此模板包括以下工作项类型：任务用户案例错误问题测试用例您可以创建自己的工作项类型或自定义特定的工作项。要了解更多有关工作项自定义的信息，请参阅BrianRandell在2008年12月撰写的有关使用和自定义TFS过程模板的文章：“TeamSystem：使用过程模板简化团队项目”。接下来，我们将深入探讨Excel工作簿并了解这些工作项在开发过程中的流动方式以及它们如何帮助用户规划和管理价值流。VSTS2010Excel工作簿在“敏捷性工具”一文中，KentBeck讨论了敏捷团队中存在的大量转换以及在考虑转换时对工具的需求。基于Excel的规划工作簿与TFS工作项跟踪的集成有助于最大程度地降低转换开销。通过使产品积压和小版本积压保持同步，可自动将用户案例或任务工作项的状态更新信息捕获到小版本积压中以生成各种报表，许多常见活动要么被淘汰，要么被优化。在使用VSTS2010来管理产品积压和小版本积压时，建议敏捷团队使用以下流程：使用VSTS2010Agile模板新建一个团队项目。通过将用户案例添加到产品积压工作簿或通过在VisualStudio中添加工作项来构建产品积压。根据各个项目在产品积压中的堆叠顺序，将其分配到某个小版本。默认情况下会创建Iteration0、Iteration1和Iteration2。可使用团队项目设置来创建更多的小版本。设置查询以从特定小版本中提取用户案例、任务及其他工作项，并将其映射到对应的小版本积压工作簿中。这些工作簿与TFS之间的集成是通过查询实现的。图2显示了产品积压工作簿的配置。在Excel功能区中，在“Team”（团队）选项卡上选择“WorkItems”（工作项）组，然后单击“ConfigureList”（配置列表）。这将打开“ConfigureListProperties”（配置列表属性）对话框。在这个对话框中，可选择一个TFS查询，而此查询的结果正是电子表格中所显示的内容。图2Excel工作簿中的查询查询是在团队项目中创建的。默认情况下，在建立团队项目时，会创建一个名为WorkItemsTeamQueriesWorkbookQueries的文件夹。在此文件夹下，您会发现有关产品积压和小版本积压工作簿的默认查询。为了更好地理解工作簿的工作原理，让我们看一看2008年10月发布的VSTS2010和.NETFramework4.0CTP中包含的DinnerNow示例应用程序。（可以在TeamSuite开发人员中心找到最新的CTP下载。）产品积压和小版本积压工作簿均可在团队资源管理器的DinnerNowDocumentsSharedDocuments文件夹中找到。产品积压工作簿产品积压主要用作应用程序中客户所需的需求列表。我听说有些团队在指代一组高级需求时也使用事迹或主题之类的术语。将这组需求收集到一个列表中、确定其优先级并在较高级别评估它们，这些操作可帮助回答此规划阶段的两个重要问题：1.应用程序有哪些需求？2.它的价格是多少？很显然，其答案只能通过评估得出。我曾看到过有的团队在此阶段使用案例分数、T恤尺寸或小时来进行评估。通过回答这些问题，团队可以更好地了解此版本或接下来的几个版本的大致情况以及这些版本的预计完成时间。通常会存在预算或计划限制，如即将进行的广告活动、法律要求或季节性活动等。这有助于规划版本的范围，因为您可以根据此限制来管理版本的范围。如果为版本设置了目标日期，则在发布时间框架内，可通过确定将哪些需求包括在小版本中来管理工作范围。例如，如果规划始于12月而发布日期定在6月，则实际上需要运行四到五个小版本（假定为一个月的小版本）才能完成此工作。如果目标日期比较灵活，则发布计划将取决于完成最低限度的一组需求所需的时间。例如，如果可以在三个小版本内完成最低限度的一组必需功能，则可以设置在三个小版本后出现版本1。如果可在五或六个小版本内完成下一组功能，则设置在这五或六个小版本后出现版本2。图3显示了DinnerNow项目的产品积压工作簿。您看到的是用户案例的积压。在这些用户案例中，其中多个已被分配给特定的小版本，并且某些已在Iteration0和Iteration1中完成。很显然，在开始一个新项目时，首先要从空白工作簿开始构建这些高级用户案例。图3产品积压工作簿这些电子表格上的各列是工作项中的字段，它们依次存储在TFS数据存储库中。Excel和TFS之间的集成会使Excel中增加一个“Team”（团队）功能区（请参见图4），利用其中的菜单项可将积压中的项目发布到TFS中、可利用TFS中更新的工作项来刷新积压，此外还有许多其他功能。图4Excel功能区中的Team选项卡积压中的每一行都被存储为TFS中的一个工作项，如图5所示。经过这种形式的集成后，使用VisualStudio的团队成员现在可从VisualStudio自身中更新用户案例和其他工作项。现在，不必在不同工具之间进行切换即可更新用户案例、评估结果或剩余工作的状态。图5TFS中的工作项容量规划作为版本规划的一部分，敏捷团队将在电子表格中花费大量时间来新增用户案例、对其进行评估，以及更为重要的，确定它们的优先级。但是，密切关注版本的状态也同样非常重要。产品积压工作簿包括一个容量规划工作簿。通过评估用户案例及其工作所在的小版本，此工作簿可对小版本自身的快速处理提供很大帮助。容量规划是规划版本时的一项重要活动。它有助于了解可在各个小版本中完成的功能。此计算中的关键数据点是进度。进度是在某个小版本中，团队所完成的工作量。如果恰好有来自先前小版本的数据，则它将是最佳入手点。图6使用先前的小版本来计算进度这通常被称为“根据昨天的天气进行预报”。实际上，如果TFS数据仓库可用，则容量规划电子表格可从其中提取历史数据。如图6所示，我可以选择Iteration1作为从中获取历史数据的小版本，并可以键入开始日期、结束日期以及团队成员数。在本例中，进度为816小时，这意味着团队可以在Iteration1中完成816个小时的工作。如果对此数据不满意，团队可以在开始时使用一个估计值，而在规划未来的小版本时使用第一个小版本的进度。在容量规划电子表格中，可指定小版本的日期范围、团队成员的数量以及小版本期间的任何中断情况（如节假日）。通过将此数据与用户案例评估和进度相结合，可创建一个能够大体给出小版本工作负荷的图表。如果发现评估的工作超过了预期的容量限制，则您可能会希望在不同的小版本之间移动用户案例以得到一个合理的分配。在我的示例中，我并未在Iteration2中规划任何工作。我可以将积压中的一些剩余用户案例添加到Iteration2中。现在，容量图表将如图7所示。这是一种非常不错的情形——评估工作并没有超出容量限制。图7为小版本Iteration2分配了工作的容量图表项目启动后，也可以使用产品积压工作簿来了解各种用户案例的整体状态。但是，通过“剩余工时和进度”、“剩余工作”和“案例进展”等报表可以了解更为详细的信息。这些报表均包括在Agile模板中，可在团队项目的Report文件夹中找到。我将在本文的稍后部分介绍这些报表。小版本积压工作簿小版本是敏捷团队的一项关键活动。经常使用Scrum的敏捷团队非常熟悉它，将其称为“冲刺”。小版本的持续时间通常各不相同。对于使用极限编程的团队，小版本的周期为一到两周；而使用Scrum的团队通常有为期四周的冲刺。小版本规划有助于定义特定小版本的范围。在小版本规划会议期间，团队通常会分析针对特定小版本分配的用户案例、收集详细的需求信息、添加相关联的任务以及评估完成每项任务所需的时间。在此会议中，产品拥有者以及团队其余成员将根据以下因素来确定用户案例的优先级：依赖关系、成本评估、详细需求以及