Paul Oldfield: 如何正确理解敏捷?

作为一名植物学的毕业生，Paul 进入计算领域仅仅是希望它能够提供一份有收入的工作。在 18 年的 IT 生涯中，Paul 在不同的项目中担任过许多角色。他常以独立咨询师的身份与 IIB (Information International of Brussels) 组织一起工作。Paul 是使用 UML 进行领域建模的专家，他的贡献主要在于将业务需求转化为系统结构和系统设计方面。InfoQ 的编辑 Kurt Christensen 最近就敏捷开发的问题对 Paul 进行了访问。

InfoQ: 请向读者简单地介绍一下你自己和你在敏捷开发方面的经验。

Paul Oldfield (以下简写为 PO): 我在各种环境都工作过，从“完全敏捷”到“完全不敏捷”。其中包括了近似 FDD 的开发方式以及没有尝试过极限编程和敏捷实践的自组织团队。最近我在进行外包软件开发的咨询工作，这间英国公司对精益开发方法萌生了兴趣并有可能最终得出一些值得注意的成果。

InfoQ: 在你作为一名敏捷开发从业者和敏捷社区领导者的角色经历中，是否见过反对敏捷的情况，如果有，你是如何看待它的？

PO: 我见过许多人，他们一听见敏捷这个词汇就表现出轻蔑的情绪。另一方面，我也见过许多当即对敏捷表现出极大的热情的人。他们其中的大多数都没有真正深入地了解敏捷。这种情况在论坛、blog 中不断发生。

就我所知，大多数的观点，不论正面还是反面，都是道听途说，从我对敏捷的理解来看，只有少数人在进行真正的敏捷实践。很多人自认为他们进行的是敏捷实践。那些有机会与真正理解敏捷的人进行交流的幸运儿更有机会理解敏捷，进行正确的实践，在剩下的人中，可能有一部分能够通过阅读资料，观察，以及依照结果不断调整成为真正的敏捷开发者。

有一些很激烈的反对声音，通常来自于一些声称进行过敏捷实践的人，事实上他们从未实践过真正的敏捷。也有少数人由于观念上的差异反对敏捷。从某种意义上讲，大多数反敏捷的声音正是来自于这些观点。

InfoQ: 所有的这些反对意见在你看来，哪些是值得一提的？

PO: 所有这些反对意见都有一定价值，正因为如此，它们才能传播开来而不是早早被反对掉了，大多数反对的理由之所以自以为站得住脚，是因为他们认为所谓敏捷就是他们所见到和耳闻的那些事情。

InfoQ: 你说“大多数反对的理由之所以自以为站得住脚，是因为他们认为所谓敏捷就是他们所见到和耳闻的那些事情”，这不就成了敏捷方法论的缺陷，我们假设一个团队没有正确的实践敏捷方法，那么这个团队在什么情况下可以得知它们开始真正的“敏捷”？如果敏捷难于正确实践，那么是从业者还是实践本身出了问题？

PO: 依我看来，在软件开发界里没有所谓的“最佳实践”，这个词汇来自制造领域，我将对此进行阐述，可能有些跑题，请读者不要见怪。在制造领域里，我们早期所做的努力是尽可能去除环境中的不确定因素，通过标准化和自动化降低单位成本，从而获利。在开发领域，去除环境中不确定因素的机会是很有限的。尤其是当我们希望进行某些完全创新的工作的时候。

这样，有一种可能是有一个团队正确地使用了某些实践，但是依然没有得到理想的结果。这是由于实践无法普遍适用于所有的情景。再考虑到团队没有正确使用实践的可能性，我们可以预见到很多使敏捷开发偏离轨道的情况。

如果我们将敏捷开发与飞行器作比较，飞行器天生不稳定，但是有良好的反馈系统用于侦测它何时偏离航线，并作出适当的调整。这种在有限的支援中作出适当调整的能力，在我看来正是敏捷与否的评价标准。

回到你刚才的问题：敏捷实践的问题是它们并不普遍适用，虽然通常来讲，它们是非常好的切入点。实践者依然需要“检查并调整”的过程。不幸的是，团队对敏捷实践的调整常常使事情变得更糟；他们通常会选择回到陈旧的，不适合的但是比较熟悉的实践中去。

如果一个团队得到了期望的结果，那么，就那个阶段来讲，他们所作的便是正确的敏捷实践。如果他们能够理解别人的意图并在“检查并调整”之后继续得到期望的结果,，那么他们将处于非常有利的位置，如果他们在借鉴别人的敏捷实践时有困难，我建议他们坚持之前的实践而不要妄为。

InfoQ: 我们假设由于无法将敏捷方法执行下去，某团队敏捷开发的尝试失败了，作为一个团队，问题通常在哪儿？敏捷的哪些方面是团队难于做到的？

PO: 有一些典型的错误。如结对编程并非意味着一个人干活而另外一个人看着，这必须是一个交换思想的过程。这让我想起自己对结对编程第一次尝试。当时我道听途说了不少关于结对编程的东西。我知道在结对的过程中什么时候应该干什么，我掌握更多算法，而我的伙伴对语言层面有更多的了解，这样，我们发现结对编程比单独工作要快得多。我们很快发现每一个人可以作什么，他在哪些地方可能比较薄弱，与初学者结对通常不会有太多想法上的交流，这是我们需要了解的技巧。

很多年以前我就学习了如何进行重构，那时候编译器异常缓慢，我们不得不选择在别人休息的时候进行重新编译 (有时候是整夜) ，我所有的重构都非常大。既没有小步前进也没有重新测试，很多已有的功能在这个过程中被破坏了，但是，进行重编译和修复的代价使我们异常小心，在每次成功编译后都尽可能修复所有的问题。之后，软件开发的流程变为先进行正确的设计，重构应该被避免。在敏捷实践中，流程方面的责任重新回到开发者的身上。我所听到的最常见的错误是认为敏捷开发没有流程，不讲纪律。

对团队做出调整通常很难，进行调整所需的知识通常不很直观，在许多情况下，团队最好继续进行那些看起来不合适的实践，直到他们获得了足够多的知识并有了更深的理解。

InfoQ: 你之前提到人们对于敏捷的负面看法有时是因为观念上的差异。你能对此进行详细阐述吗？ 将那些没有亲自尝试过敏捷开发的人的偏见放在一边，如果有的话，那些合理的观念上的差异是什么？

PO: 我不确定我曾经承认存在合理的观念上的差别，但是我愿意就此发表我的看法。

我常常遇到那些不将制造业和软件开发加以区分的人，他们看到了最佳实践以及高度自动化的生产流程，并希望将其应用在软件开发中。在这里我不会提及他们的名字，我遇到过按照时间和原材料支付工资，利润与人数多少相关的情况，在这里，所谓效率意味着利润的减少，而且客户直到接受不再需要这么多工人的事实才会承认效率的提升。

有时候我会想起刚刚接触到敏捷实践的时候，某些实践挑战着我的世界观，幸运的是，我的处世哲学让我乐意探索这些对我的世界观产生挑战的部分，万一在这些问题上我犯了错误呢，万一别人才是对的呢。每一处挑战开始的时候就像一个新的宗教，但是进行探索就会破除盲目崇信。就我所看到的，大多数的人选择符合其已有观念的意见。他们以近乎宗教的方式接受或者拒绝新的观点。他们或许会进行某些肤浅的推理，但他们认为进行详细论证是在浪费时间。这对敏捷的盲目接受者和诋毁者同样适用。

Emergent Architecture 是最初我认为不符合我世界观的部分。最终我发现其倡议者所建议的正是我在研究项目上 7 年间所做的。在这个项目中， Emergent Architecture 逐渐变为成型的解决方案。当然，与过去相比，敏捷的倡议者提出了更多的规程。应用规程势必会影响灵活性，这些规程之所以有效是因为在现代系统中创新的程度较过去大大降低了。敏捷的倡导者所创造的规程是从完全不同的，非制造业的角度展开的，这样它依然保持着灵活性。 我花了很长的时间才明白没有哪个敏捷实践是可以脱离其他实践单独运作的。在试图了解某一个实践如何指导开发工作之前，我需要对全局有一个清醒的认识。

当然，也有人尝试过敏捷（或者自以为尝试过）并且失败了。强迫这些人赞同他们不理解的东西非常困难，当然，问题总会出现，我从不期待会有一帆风顺的情况，事物总会向熵最大的方向发展。我想这适用于很多负面意见。这些人的意见对于从未尝试过敏捷的人也造成了一定程度的影响。

作者简介：Kurt Christensen 已经有超过 12 年的软件开发经验，他作为教练，教员以及程序员在不同的项目工作过，这些项目大小不等，所服务的公司也规模不一。Kurt 和妻子以及两个孩子现在生活在明尼苏达市保罗街。 译者简介：胡凯是 InfoQ 中文站的志愿者翻译。2006 年加入 ThoughtWorks ，通过在 ThoughtWorks 多个国家和多个项目的敏捷实践，坚定地站在了敏捷阵营中，目前在进行 CruiseControl 相关的敏捷开源项目。他和许多敏捷开发者一样活跃在敏捷中国和 CruiseControl-China 社区中。加入 InfoQ 中文站志愿者翻译队伍，请邮件至 china-editorial@infoq.com 。