用了敏捷实践就是敏捷项目吗？

作者 Deborah Hartmann Preuss 译者 李剑 发布于 2007年7月18日

领域

架构 & 设计,

过程 & 实践

主题

方法论 ,

敏捷

标签

反模式 ,

敏捷宣言 ,

评论

采用敏捷方法学的人正在逐渐增多，在最近的调查中显示，XP，Scrum和FDD这些方法被广泛使用，已经达到了前所未有的程度。但其中也有反面教材——如果开发团队只是简单的把敏捷实践拷贝到项目中而不是在实践中逐步掌握，随便把在某处获得成功的实践经验就拿过来用，却不去思考如何进行持续性的改进来让开发过程适应于自己独有的环境，那又如何谈得上敏捷？一个敏捷实践者将其称之为“垂死的千份拷贝（dying the death of a thousand copies）”。

不幸的是，随着敏捷的进一步流行，这种“坏敏捷”就有可能成为一种副作用，有些人也会依据他们自己一些软弱无力的例子总结出一套关于“敏捷软件开发”的理论来。比如在最近的一篇名为Egomania Itself的文章中，Steve Yegge就把他上个月扔下的东西又捡了起来。他用了“敏捷教会”这个词，并把敏捷实践比作了迷信：

……有些人很可能想要用魔法来帮助项目取得进展，而且有很多项目——可能是大多数——都最后成功了。

我敢保证，你要是来跳舞祈雨，连着跳上七八十天，或者更久，大不了一直跳下去，那早晚也能求到雨的。

所以我不是说敏捷不行。它确实行！但它不过是纯粹的迷信而已。

当然，敏捷可以用这种方式来实现，有的时候人们也确实就是这么干的。但这种“基于信仰”的对敏捷实践的应用——我们相信它能工作，我们不需要知道为什么——却忽略了敏捷软件开发中最强大的工具：现实。敏捷是采用基于经验主义的过程来“拥抱变化”的。Jim Highsmith在Agile Project Management一书中描述道：“敏捷项目是探索式的项目，所以它们的成功都是建立在现实反馈的基础上的。”敏捷的计划-实施-检查-调整的短周期也正是旨在增加对项目的理解，以便确保那种低效的过程不会被无限的重复下去。实际上，在特定的场景下，这个计划-实施-检查-调整的周期也会让一个团队清楚的看到，敏捷完全不是他们所需要的那样子。

正如Yegge所说，即使是这样的敏捷也可以工作——但是这条路上还是发生了许多故事：一些团队不得不使用一些不需要或者是根本就不想使用的实践，被固定的 日期、范围和预算捆住手脚，甚至是那些剥夺了开发人员来之不易的工作空间而只是简单地想用更少的投入得到更多的回报的那种领导也会从中作梗。在这种情况 下，就算能造出可以工作的软件，同时也造出了一些满怀愤懑的开发人员——有时候他们也就把自己给毁掉了。这根本无法和敏捷宣言的第一项价值"人重于过程"保持一致。

在Yegge的博客上，大家根据敏捷实践如何才能工作这个话题展开了热烈的讨论。下面是从上万字的讨论中截取的一些片段——很不幸，大多数回帖的人都是匿名的，所以我们只好凭猜测来判断是谁留的言。

Geoff——网名"gilligan"——对Yegge错误的推理提出了质疑，并写道：

有这样一种人，他们完全就是机会主义者，直接跳到敏捷的潮流中大喊“跳进来吧，这里包治百病！”他们不理解什么是开发，也不知道Beck，Cockburn，Jeffries，Fowler或是其他人为什么推荐一些实践，他们甚至都不知道实际的问题是什么！我把这种人称为Agilista。……

当我第一次听说XP的时候，我进行了快速的学习，然后写了篇文章，名为“XP eXposed”。我希望这篇文章能够广为人知，所以就像对家庭作业一样认真对待。但是当我开始实践XP以后，我才知道XP并不像我一开始所认为的那么 蠢。最后我发现这里有很多好东西值得我们学习（对菜鸟来讲），或是回顾（对老手来讲）。我无法完成那篇文章。为啥？因为我明白了把注意力放到一件事情的优 点上要比放到它的缺点上要好。

而jiblet回复说 (仅摘录部分内容):

这些方法学[敏捷及其他种种]是那些有经验的开发人员在不断调整他们自己的开发过程中总结出来的问题是：假如普通的开发人员不理解为什么这些方法学会出现，那么他们就无法从中得到什么。反之，就是无理由的盲目顺从……

Cory Foy 对这种“追根溯源”的做法表示了不满, 他在自己的一篇博客“原则，而非过程”里也讨论过这种思想：

我觉得你应该为XP给你带来的感受而感到羞愧。尽管你的博客写的实在是具有娱乐效果。

因为在我的XP世界中，开发团队所要牢记的最重要的一点就是，这是他们的过程，不是其他任何人的，他们要确保自己能够理解实践背后的原则，之后才能按需剪裁。这是他们自己的责任。

敏捷团队确实应该把敏捷实践和敏捷价值放到一起学习，从而把开发过程真正变成属于自己的东西，进而日趋完善。敏捷宣言中包括4个价值和补充的12项原则。它们不是建议，它们定义了敏捷软件开发，正如Java API定义了实现这些API的应用服务器的行为一样。方法学只是不同的实现和解释而已，所以，随着时间的推移，它会不断发展演化。

这四个价值是：

个体与交互胜过过程与工具
可工作的软件胜过面面俱到的文档
客户协作胜过合同谈判
响应变化胜过遵循计划 ¹

也许现在是时候来讨论一下错误地传授或实践这些基础知识是如何把团队最重要的资产摧毁了的，这些资产包括诚实，创造力，团队成员的守诺以及客户的信任。团队中用到了哪些核心实践无关紧要，但是，只要他们的声音被忽略了，那么他们创造实际价值的能力就会受到打压，也就谈不上真正的敏捷了。

¹ 这是完整的敏捷宣言中有关敏捷价值的一部分，作者们把这些价值也放到了宣言中。它是一篇十分精简的文档，如果你过去一直都没有时间读的话，现在就请点一下链接看看吧。

关于作者

Deborah Hartmann 是一个敏捷实践者，她住在Toronto，在Canada和US工作。她从2006年四月起就一直担任InfoQ.com的敏捷社区编辑。

查看英文原文：Do Agile Practices Make it an Agile Project?

• 更早的 >