Visual Studio Team System XXXX 中的敏捷规划工具.docxVIP

Visual Studio Team System 2010 中的敏捷规划工具 本文以 Visual Studio Team System (VSTS) 2010 的预发布版为基础。所有信息均有可能发生变更。 　　本文将介绍以下内容： 　　产品和小版本规划 　　产品积压工作簿 　　容量规划和报表 　　小版本积压工作簿 　　本文使用了以下技术： 　　VSTS 2010、VSTS Process for Agile Software Development 1.0 目录 　　长期规划 　　版本和小版本规划 　　VSTS 2010 Excel 工作簿 　　产品积压工作簿 　　容量规划 　　小版本积压工作簿 　　报表 　　“敏捷规划”存在语意矛盾吗？希望您不会这样认为，但在最近于洛杉矶召开的一次专项小组会议中，其中一位与会者指出其组织已从敏捷开发转为采用更为正式的方法。在经过进一步的询问后，她坦承其团队无法再根据其经理的口头要求进行代码修复并立即将修复结果部署到生产中。现在，她不得不使用正式的程序。对她而言，即意味着放弃了敏捷开发。 　　实际上她对敏捷开发的理解并不准确，但是我非常高兴她的组织能够制订正式的更改流程。敏捷并不是指盲目进行加速或出于速度考虑才选择敏捷的。相反，它是一种符合标准的规划方法并且其中融入了经验数据。 　　Visual Studio Team System (VSTS) 2010 引入了一些新的特性和功能来帮助敏捷团队进行规划。在本文中，我将向您介绍一些全新的产品积压工作簿、小版本积压工作簿以及一组新报表，它们可以帮助敏捷团队规划和管理版本和小版本。 　　长期规划 　　人们总是担心没有精确的长期规划，这已成为推广敏捷方法的主要障碍。在 2008 年度敏捷开发状况调查中，缺乏事先规划是受访组织在采用敏捷方法时最关注的问题。我怀疑对许多人来说，缺乏精确的长期规划就等同于缺乏协同规划。敏捷团队选择多个层级的规划并在瀑布式规划过程中进行期间修正，当然本来就该如此。 Steve McConnell 在软件评估的不确定性圆锥中指出，在项目中过早进行评估可能会得出不准确的结果，偏向高边的错误最高会达到 400%：“在项目早期，待构建软件本质的具体细节、特定需求的细节、解决方案的细节、项目规划、人员构成以及其他项目变数均不确定。这些因素的可变性会导致项目评估的可变性。” 　　当然，这并不意味着主管人员的管理策略是“我们不知道项目何时能完成，也不知道完成时会是什么样子”。它实际上是想说明团队规划版本的方法以及各版本中所完成工作的范围均存在变数。 　　图 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 模板。此模板包括以下工作项类型： 　　任务 　　用户案例 　　错误 　　问题