敏捷社区对使用工具太过敏感

最近， Steve Ropa在 CM Crossroads网站的一篇文章中，质疑一些敏捷人士自相矛盾：他们想让别人接受他们开发的软件，但自己却拒绝使用软件来代替白板、索引卡片和面对面的沟通（或使用软件来增强效果）。

在世纪之交，人们开始采用敏捷开发方法时，首先停用了那些自动化工具。他们这样做最主要的目的是想摆脱项目管理工具，从而专注于面对面沟通。那个时候工作中已经到处是筒仓和自动化流程管理工具，他们想抛弃工具是合理的反应。它让我们开发人员摆脱了形式化的工作，也不用做过多的设计文档。我们只需要索引卡片并在白板上用手画出图表即可。我们要做真正的工作，不让任何工具挡道。

尽管这种想法可以理解，由于敏捷方法正在被更大的组织采纳，我们需要评估这种新劳工运动（Neo-Luddism）是否真的对我们最有益。毕竟，如果连我们自己似乎都不相信开发出的软件，我们为什么要让客户相信呢？

关于这个话题，我们联系Steve作了更深入的交谈：

InfoQ：一些敏捷人士可能反对使用软件工具来增强工作流程和人们之间的交互，但他们是否认为其他人也会信奉：太多的技术，可能会减缓创新，而不会加速创新？ 

Steve：当然。我们都应该接受这个观点：我们需要选择对我们有效的工具，并且要认真挑选。当某个工具对我们没用了，那就继续选择其他工具。我喜欢比作：像木工一样选择工具。有时，我需要台锯，因为它确实对我很有用。其他时候，我只需要使用我信任的手锯就行了。用哪个工具完全取决于我想做什么事。在我看来，最重要的是：绝不要让工具决定我如何工作，这就是关键。假如我们工作的驱动因素是所使用的工具，而不是要交付的软件，那我们就受工具束缚了。

InfoQ：你似乎也在表明：敏捷的可伸缩性依赖于成功采用软件工具和通讯设备。但是，使用这些工具，是否又会把我们带回到以前的处境中：到处是筒仓和自动化工作流程......或者我们已吸取教训，现在这样做将与以往不同？

Steve：这个问题......我并不是真的想说敏捷的可伸缩性需要这些东西。我真正想说的是，这些工具能使可伸缩性变得更容易，而且我们不应该仅因为它们是工具就拒绝使用。要那样说，我将永远不想要自动化工作流程。我密切关注项目管理类工具，确保这些工具的作用是促进沟通，而不是限制沟通。

GearStream的CEO Brad Murphy支持在敏捷软件开发中使用软件工具，他说：

具体来说，在Gear Stream，我们投入大量资金用于在云端实现全自动化的“端到端”的编译/测试/发布工具链......用这个工具链来支持我们自己的观点：高度自动化的敏捷应该是什么样的......我们的模型很灵活，并且可以持续改进和变化——而不是局限于固定的模型，但又不会犯错。我们相信使用自动化工具会使工作更美好。

由于敏捷对使用工具高度敏感，我们也认为敏捷运动对工具创新有（总的来说）负面影响。在Gear Stream，我们非常认可自动化工具的价值。我们正在构建一套完整的管理服务外包模型，它根本无法离开我们当前正开发的高度自动化、完整的集成工具链。

但是坚持使用索引卡片、白板和面对面沟通的敏捷人士，他们强调使用这些工具和技术的好处胜过使用软件工具。关于实物敏捷看板和软件工具哪个更好， Nigel Shaw在2010年写过 一篇文章，在细微处对比了实物看板和虚拟看板，介绍了使用实物看板比之软件工具具有的优点。他列出了一份清单：

• 你一眼就能看出哪个卡片是谁的。
• 你一眼就能知道每张卡片的完整故事。
• 看笔迹你就知道卡片内容是谁写的。
• 重要事项可以用粗体、下划线或用其他方式突出表示。
• 不重要的事项可以写得很小。
• 看卡片的磨损情况你就知道它存在多久了。
• 简单移动一下，你就能按排列、按迭代表示它的优先级。
• 你可以一次移动两张卡片（互换位置）。
• 两个或多个人对着它讨论就足够了，你也可以调整为三到五人。尝试改为对着显示器讨论看一下效果。
• 还可以用其他形式使用白板：可以贴标签、星星，如果白板有磁性，可以贴冰箱贴；如果是软木，可以用大头针订上便签。
• 把两张卡片叠放在一起，你就能将故事合二为一。
• 把一张卡片撕成两片，你就能将故事一分为二。
• 故事卡片可以放在迭代的边界上，只要你们对它表达的意思达成共识即可。
• 你可以即时删除。
• 你可以即时在邻近处增加。
• 你可以取消任意多的删除操作。
• 你可以站在它面前，它会让你精神振奋并给你能量。
• 你可以在它周围空白处添加其它事情。
• 你还能在它边上挂个开瓶器。

关于 “个体和交互胜过流程和工具”的争论在社区可能会继续下去，而使用敏捷计划工具的人，随着敏捷实践逐渐被接纳也会继续增多。