什么使工具敏捷起来?

作者 Amr Elssamadisy 译者 郑柯 发布于 2007年10月11日

领域

架构 & 设计,

过程 & 实践,

语言 & 开发

主题

.NET ,

Java ,

编程 ,

敏捷 ,

软件测试

标签

测试 ,

计划

“个体与交互胜过过程与工具 ”是《敏捷宣言》的第一条价值观。不过，工具好象成了大多数敏捷团队的重要组成部分。那么在什么情况下工具可以起到帮助作用，又在什么情况下会对（敏捷）软件开发形成障碍呢？

Chris Woodell列出了一系列.net敏捷工具，并对它们分别进行了简要介绍。该列表包括的工具有NUnit、Nant和NCover。象其他人一样，Kirt Knoerschild也写了一篇支持敏捷实践的工具的文章，其中包括许多Java版的工具，比如JUnit、Ant以及CuriseControl等。

在这两篇评论中，有些工具显然是非常适合“敏捷”的，而无论我们采用什么样的开发方法，其他工具都会帮助我们开发优秀的软件。两篇文章都没有提到诸如VersionOne、Rally和Mingle这些项目管理工具，而它们是完全针对敏捷开发团队的，然而，它们也引起了不少争议。Ben Hughes提出了一个问题：自动化的敏捷工具是不是太冷冰冰了？Rally公司的Ryan Martens和Ron Jeffries对计划工具（是否缺乏）的价值进行了争论。

在敏捷社区中，我们所使用的工具可以分为以下几类：

• 对软件开发有帮助作用的工具，而不关心开发过程。诸如源代码控制和缺陷跟踪工具都属于此类工具，他们不一定能够让一个团队变得更“敏捷”或是更“不敏捷”。
• 直接支持敏捷实践的工具，与敏捷宣言的价值观和原则保持一致。诸如xUnit和持续集成服务器等都属于此类工具。
• 支持敏捷实践，但是针对敏捷宣言中的一项或几项原则做出了折中的选择。这类工具包括减少了人员互动过程的规划工具，以及自动产生测试代码的工具，使用它们会减少应伴随着测试先行开发进行的思考过程。

您发现哪些工具对于敏捷开发来说是必不可少的吗？您是否用过阻碍优秀实践和/或沟通的工具？如果用过的话，你用了哪些折衷方案解决这类问题呢？

查看英文原文：What Makes a Tool Agile

---

译者简介：郑柯，目前任职《程序员》杂志社高级编辑，有志于在中国的软件开发业界推广Agile的理念和方法论，笃信以人为本，关注Ruby，关注敏捷，关注人。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。

译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。

• 更早的 >