敏捷开发的潮流并不是由敏捷工具来推动的。因为你可以仅使用命令行接口、单元测试工具和需求卡片来展开敏捷开发。但近年来，为了更好地支持敏捷开发，敏捷工具也有了很大的发展。其中部分工具是直接面向新型项目管理方式的。

特别是有些种类的工具已与敏捷开发密不可分。根据Forrester研究公司（Forrester Research）高级分析师Carey Schwaber的研究结果，面向敏捷开发的项目管理工具、持续集成构建工具和自动测试工具已是敏捷开发不可或缺的工具。

她在《敏捷过程研究（The Truth About Agile Processes）》的报告中指出，“敏捷开发团队将投资主要用于其团队所必需的工具，其中最先考虑的是敏捷项目管理工具，然后依次是测试工具、构建管理工具和软件配置管理工具。”

Schwaber还表示，各敏捷团队都有自己的管理方式，因此，他们对项目管理工具也有不同的需求。尽管如此，仍然有些团队仅靠电子表格和WIKI进行管理。不过Schwaber等人也指出，当敏捷成为大型团队开发进行大型项目的主流开发方式时，这些自己临时组织起来的技术将难以满足需求。

敏捷开发催生敏捷工具

敏捷开发在20世纪90年代晚期随极限编程（Extreme Programming，XP）运动而兴起。极限编程主要是关于单元测试、结队编程和简化的需求采集的运用，当然也有人会说极限编程还包括大量的提神饮料。

诸多的项目失败是促使极限编程出现的原因之一，比如无法准时交付产品，或者虽然成功交付却因为产品不符合客户需求而不能投入使用。牵涉诸多预先分析和建模的统一建模语言（UML）和统一开发过程（RUP）的发展也是极限编程形成的原因。

可以认为，2001年的《敏捷宣言（Agile Manifesto）》是对敏捷过程最好的阐释。在某种程度上，敏捷过程将极限编程系统化，为敏捷开发提供了参考标准和价值，并减轻开发人员面对需求变化时的压力。

基本上，这是一个致力于寻找缩短交付间隔，并增加迭代频率方法的敏捷潮流。团队有权限自行设定交付期限。交付可以使用的软件是最为重要的目标，而预先建模和需求采集阶段则要求尽量简单。并且，需求采集并不是在项目早期便结束，而是会在项目开始后很长时间内一直进行的过程。

正因为以上原因，单元测试在敏捷开发中变得尤为重要。这样，在持续集成软件单元时仍然可以迅速分析漏洞。而且，有效的自动构建工具也成为敏捷工具的组成部分。因为持续的迭代开发意味着经常要进行快节奏的集成。授权给开发团队可以开阔项目开发思路，也使增强的项目管理软件在敏捷开发中得以发挥更重要的作用。

Forrester的分析师Schwaber称这种新兴的项目工具为“面向目标的敏捷项目管理工具（purpose-built Agile project management tools）”。她重点提到在这一领域有代表性的敏捷工具开发商：Rally软件开发公司，VersionOne和ThoughtWorks工作室。她还指出，目前已有可用的敏捷模板，比如Conchango公司的Scrum模板便是Microsoft Visual Studio Team System开发平台的杰出插件。

最新敏捷工具一览

2007年，敏捷项目管理工具开发商都忙于新产品的迭代开发以满足其敏捷客户的需求。这些产品支持新的工具插件，增强需求处理功能，并且：

Rally 2007.7版本支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则（notification rules），以及用于Eclipse和CruiseControl.NET的连接器。

TargetProcess 2.6添加了列表即时编辑功能（inline editing in lists）、新迭代规划（iteration planning）功能和Visual Source Safe集成。

VersionOne V1最新版本中增加了第三方开源集成工具Subversion和FitNesse。

著名的IT咨询公司Thoughtworks也开始进入这一领域。2007年10月，公司发布用于敏捷软件开发的Mingle 1.1。虽然在第一个版本发布仅三个月就发布新版本，但公司声称这个版本可以更好地帮助项目团队进行规划、追踪、优先分级和协作。Mingle 1.1中的日期属性有助于对需求、漏洞和任务进行追踪和划分优先级。并且，这个版本扩展了需求卡片（story card）的筛选范围，还增加了对远程Subversion知识共享库的支持。

IBM的Rational工具组有时会受到敏捷拥护者的指责，特别是对其Rational统一开发过程（Rational Unified Process）的指责。因为人们普遍认为它是一个自上而下的过程，这会增加一线开发人员的工作负担。2006年，为传播敏捷方法，敏捷传道者Scott Ambler加入IBM公司。然后，2007年，IBM发布其努力的成果——Jazz开发平台。

设计模式（Design Patterns）领域最有影响力的拥护者，目前也在IBM进行Jazz开发的工程师Erich Gamma说，Jazz延续了IBM Eclipse的成功。最终，这个新软件将提供对定制过程的支持。他说，“在开发Jazz的过程中，我们发现各团队都采用各自的过程，比如不同的开发方式，来处理规则变化。”

目前，Jazz仍然是一个（功能有限的）测试中的技术，但IBM公司已经展示了以Jazz技术为基础开发的主要用来提高团队开发效率的IBM Rational Team Concert协作平台。

敏捷开发加速产品交付

敏捷开发过程是经常变化的。同样，敏捷工具也是可以改变的。DTS公司（Data Transfer Solutions）的高级项目经理Chris Spagnuolo和GIS软件首席架构师Dave Bouwman在团队正式引进敏捷方法之前已经使用了一年半的敏捷方法。他们的敏捷开发正在迅速展开。

引入敏捷方法之前，所有的开发对Spagnuolo和Bouwman来说都意味着冗长的需求列表和大量的预先设计。但随着敏捷方法的到来，这些都不再是让人头痛的问题。他们选择的是基于Scrum技术的敏捷方案，可以流水线化初始阶段的需求采集，可以在整个项目周期中随时增加需求，并可以集中开发按周交付使用的软件版本。

刚开始，他们使用一些临时拼凑起来的、简单的项目管理工具。而现在他们接受了Rally软件开发公司的项目管理工具。

Bouwman和Spagnuolo在公司主要负责空间管理及相关资产管理应用软件的开发。Spanguoloyu说，“以前，我们要预先做大量的需求分析。采用敏捷方法以后，我们更换了工作方式。现在我们在整个项目周期做需求采集，而不仅仅是项目开始时。这样，客户每周都可以对需求进行优先分级。”

Bouwman说，“敏捷开发可以让我们先交付最有用的部分。我们很快便发现了这么做的好处。因为每次你给他们展示一些东西以后，他们的需求都会发生变化，然后我们就能得到一些反馈。这种反馈是双向的。你可以知道增量版本功能是否符合要求，而客户则可以知道你现在在干什么。”

对Spagnuolo来说，敏捷开发还意味着客户也变得“敏捷”。他说，“他们可以经常看到我们交付的软件，需求改变也很灵活。”

Bouwman补充说，“软件是一种比较飘渺的东西，但通过频繁的迭代开发和‘利益相关人’的持续反馈，客户可以获得比较具体的感觉。他们还会告诉你下一步应该怎么做。”

然后他又说道，“虽然也预先做需求分析，但通常并不一定按你想的发展。实时的需求采集要有用得多。”

敏捷工具改善敏捷开发

Spanguolo还提到一个常见问题：索引卡片和即时贴反映的需求有时并不准确。随着项目复杂性提高，仅使用简单的工具开始有点力不从心。他说，“我们开始寻找工具，特别是需求方面的工具”。他们曾经使用一张电子表格追踪用户需求，然后根据需求用另一张电子表格安排各迭代周期的任务。

他说，“开始的时候这个方法还是有效的。但随着敏捷开发复杂度提高，以及参与的开发人员的增加，电子表格已经无法满足我们的需求。单是管理这些表格就要花费太多时间——每周需要大约四到六个小时。”

Spanguolo的团队也曾使用任务卡来组织工作。和需要大量工作的电子表格一样，低技术含量的任务卡同样费时费力。Bouwman说，“整理任务卡是一个艰苦的手工过程。”

后来Spanguolo他们开始使用Rally项目管理软件，团队才真正做到“实时追踪”，按照计划交付成果，并能减轻开发人员的压力。Spanguolo还说，简报页面（reporting dashboard）可以让开发人员更有效地组织任务。其中成功完成的版本以绿色显示，失败的版本以红色显示。

Rally软件是一个核心工具，但是功能很多。Spagnuolo和Bouwman的团队工作于.NET环境下。他们使用MS Build构建工具和CruiseControl.NET持续集成工具。CruiseControl.NET对源码控制工具进行监控，比如上文提到的Subversion。如果有新的变动，它就会启动一个新的构建过程。然后Rally各组件会与这个过程或持续集成引擎相连。

展望敏捷工具前景

目前看来，在良好的知识共享库和智能项目数据管理工具的支持下，围绕构建管理和工作流程的标准过程正在形成中。尽管如此，这些被Burton Group分析师Joe Niski称为“系统开发周期（SDLC）基础结构”的每一步发展都将提高项目开发和项目团队的效率。

Niski认为，关于知识共享库（repository）最关键的一点是“它存储了特定项目的元数据，其中源代码控制库正是我们构建项目所需要的”。作为储存项目管理软件所依赖的知识共享库也存储了构建成果。

当然，作为敏捷过程核心的是用户需求。这些用户需求（user stories）正在取代用例（use cases）成为应用广泛的需求采集方法。并且，在诸多敏捷开发过程中，多页的用户需求已经逐渐被简单的需求记录卡所取代。

新兴的敏捷项目管理工具大都支持以位图或jpeg格式存储这种记录卡。可以预计，这种“敏捷存储”方式也将获得广泛应用。