敏捷工具有效性大辨论

敏捷宣言中的价值之一就是“个人与交互胜于过程与工具”。从传统的字面意义上看，这一价值暗示着使用软件工具不如使用白板、索引卡片等一些非高科技工具好。敏捷杂志（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在软件开发是协作和创造的合作游戏一文中提到的模型很相似。所以，我们在软件开发中使用工具时，应时刻想到这一点。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！