敏捷开发加速产品交付

　　敏捷开发过程是经常变化的。同样，敏捷工具也是可以改变的。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格式存储这种记录卡。可以预计，这种“敏捷存储”方式也将获得广泛应用。