【IT168 专稿】

    除了命令行接口、单元测试工具和3×5的索引卡片，敏捷软件开发人员通常还会使用其它各种各样的专业工具。根据某网站发布的2008年敏捷趋势调查报告，按“重要级”排列依次是需求管理工具（56%）、Bug追踪工具（51%）、项目管理工具与单元测试工具（各占45%）。此外，常用工具还包括功能测试、持续集成构建、协作、配置管理和文档管理工具等。

    尽管开发团队仍然可以仅靠电子表格方式进行管理。不过，当敏捷成为大型团队开发进行大型项目的主流开发方式时，这些自己临时组织起来的技术将难以胜任。由此带来敏捷工具的广泛采用和快速发展。

    欲善其事 先利其器

    IBM敏捷开发实践负责人Scott Ambler说：“很显然，需求管理是非常重要的。你会发现环境越是规则化，对需求管理的要求就越高。这是近年来软件开发的本质。”

    Ambler还表示：“需求采集是一个让敏捷领域所有人头痛的问题。我们必须克服这个困难。而索引卡片在这方面做的还不够好。”尽管如此，他仍然认为：“我们还得提高需求管理和文档的效率，这也是我们使用敏捷建模的原因。”

    Nari Kannan在加利福尼亚洲普莱森顿Ajira技术公司担任总裁。该公司从事敏捷开发所必须的服务过程管理方案、Bug追踪及自动测试工具的开发。就自动测试来说，他认为：“开发团队每周都要做一些构建，所以不可能每次都填写所有的表格。我们努力使测试标准化，许多新的构建也可以通过自动测试工具完成。”

    他谈到，Bug追踪工具也为Ajira公司节省了不少时间，“Bug追踪是很关键的一环，因为你肯定不想在很短的开发周期内因为处理Bug而浪费太多的时间。”

    Steve Whatmore是位于多伦多市为金融服务业提供商务解决方案的LYNXDev公司的Java设计师。他认为缺陷追踪系统是敏捷开发中不可缺少的关键系统，理想状态下应该在集成开发环境中整合缺陷追踪系统。LYNXDev公司使用Mylyn（任务管理辅助系统）管理Eclipse环境，并集成到CodeBeamer协作平台上。

    Whatmore说：“这样便可以直接在IDE上给开发人员发送解决Bug的任务通知，允许开发人员检查与这个缺陷相关的代码并进行修复。所有操作都直接在IDE环境下进行。”

    自动工具提供便利

    随着敏捷开发的周期越来越短，Whatmore认为自动测试工具也很重要，特别是自动回归测试和单元测试。

    他说：“虽然我们并不是以'测试为主'，但我们确实为应用程序准备了全套的回归测试。我们每天两次的构建都要进行这种回归/自动测试，并为开发团队发送与结果相关的通知。所有的失误都会得到及时处理。并且随着时间的推移，这种处理方式也改变了我们的开发人员的心态，从而不仅使我们的版本构建过程得以顺利进行，应用程序的单元测试中的问题也很少出现了。”

    Whatmore也使用持续集成/构建工具，他说：“这些工具对敏捷开发方式的成功起着很重要的作用，它们使你随时都能得到一个可以运行的系统。我们现在就正在执行一个每天两次的构建版本。这既能保证我们随时都有可以运行的应用程序，也能把这个应用送到质量保证团队。”

    另外，Whatmore还认为源代码控制（SSC）系统是“必不可少”的。这个系统应该能对各种需求提供强力的支持，比如多开发流程、标记、分支等。但是，也要注意，不能把开发过程限制在SCC规范里。

    每日会议强调沟通

    Whatmore认为，“为了保证团队里的每一个人都能及时得到关于开发团队的开发过程/状态最新的消息”，开发例会有着非常关键的作用。他们的团队有一个每天15分钟的开发例会，会议内容包括每个人的工作进度、开发人员可能面对的困难、任何可能影响到团队其他人的应用架构的改动或修改。

    Whatmore说，“这些会议在保持信息沟通方面有着非常重要的价值。”

    Mike Turner是Northstar Analytics公司的总裁，也是《Microsoft Solutions Framework Essentials：Building Success Technology Solutions (Microsoft Press, 2006)》一书的作者，他认为，不管敏捷团队用的是什么工具，每日会议的作用就是交流， 而工具必须根据团队来选择。

    Turner说：“很显然你得有一个开发环境，你得管理代码，你得进行交流——不管是用即时消息的方式，还是使用SharePoint协作平台。”

    但是，工具的选择取决于具体的情况，比如团队是集中式的或是分布式的，团队的支持来源等。“如果你们都在一个办公室工作，那就不需要太多的这种工具。这完全取决于外部团队的情况。”