敏捷宣言中的价值之一就是“个人与交互胜于过程与工具”。从传统的字面意义上看，这一价值暗示着使用软件工具不如使用白板、索引卡片等一些非高科技工具好。敏捷杂志（Agile Journal）的四月期刊中重新审视了工具与敏捷开发的关系。这些文章内容的差异也反映出了当前社区对其不同的看法。
Ron Jeffries（敏捷宣言作者之一）和 Rally Software 的 Ryan Martens 进行了关于软件开发中工具的有效性的争论。关于软件开发中工具有效性的辩论。他们都同意那些提供构建、重构和持续集成的 IDE 是比较好的工具，但在团队共同使用的工具上有分歧。Ron 指出，他反对使用这些集成工具，因为它们更多地阻碍了沟通：
我使用工具看过很多团队的计划或跟踪过他们的迭代。过程好象总是这样的：ScrumMaster 或相当于 ScrumMaster 的人（译者注：一般是项目经理）把计划（或迭代内容）投在屏幕上，然后一个一个地问：“你做完什么了？你正在做什么？你打算下一步做什么？”等等类似的问题。基本上，这个过程可以叫做汇报过程，而不是对话过程。所以与讨论相比，这个过程不适于沟通。团队的每个成员都在轮班回答领导提出的问题。
Ryan 回应道，有一定规模的团队就需要工具，因为此时白板和索引卡片无法发挥作用：
敏捷应用的生命周期管理 **(AALM)** 工具正在成为综合性的“快速”工具，但是主要还是为了帮助扩大团队，帮助大团队进行管理上的同步。为了与其相一致，迭代团队使用这些工具来反映团队的工作进展状态，如任务、故事、测试以及缺陷状态。为了减少各迭代团队所承担的协作负担，AALM 工具就使得团队在既使用白板卡片又使用工具时的协作变得容易许多，而白板自己无法担当这样的角色。
这期杂志的另一些文章阐述了这一辩论的另一个方面。John Scumniotales 说时代在变化，敏捷方法和过程现在也要大面积被迫使用这些工具。如果我们想成功，没有别的选择。Dave Hoehn 在 Renaissance of Paper 一文中，使用了另一种方法，并倾向于低技术含量的解决办法。因为这些工具的自然外观弥补了软件开发的不真实性（译者注：或不可触摸性）。而 Jim Reuhlin 认为，使敏捷团队有效的原因是团队级的协作——衡量工具有效性的标准应该根据它们是否提高了协作效率。
所有文章都围绕着有效协作这一主题，即工具是阻碍还是促进了交流与协作？这一点上与 Alistair Cockburn 在软件开发是协作和创造的合作游戏一文中提到的模型很相似。所以，我们在软件开发中使用工具时，应时刻想到这一点。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论