Kent Beck谈敏捷开发的应用和价值观

    Kent Beck做了许多与敏捷软件开发相关的幕后工作，其中包括JUnit测试框架和极限编程。Kent还是在面向对象编程中应用设计模式的先驱。InfoQ的Kurt Christensen最近采访了Kent，并询问了一些关于敏捷软件开发现状和未来定位的问题。

    InfoQ: 您目前的工作是什么？

    Kent Beck (KB): 前不久我刚完成《Implementation Patterns》一书，该书介绍了如何通过代码进行沟通。它将在2007年第一季度上市。现在我正在开发JUnit的新版本。与此同时，在我现在参与的许多项目中，我将很多时间花在利用付费客户端进行远程结对编程上。

    InfoQ: 当一个敏捷团队工作时，有时透明化的流程会暴露出机构中的问题，而这些问题随后又被归咎于敏捷开发流程。在整个行业中，我们开始遇到这种情况了吗？敏捷开发会使行业的缺点逐步暴露，从而在各方面招致一些与敏捷开发对抗的反对意见吗？

    KB: 我所见过的大多数反对意见来自于程序员个人而非机构或整个行业，这些程序员通常不愿向机构中的其他成员负责。我想，这些针对行业的反对意见，反对的不过是敏捷开发这个词的含糊使用，而不是任何特定的流程。

    客户看起来并不在意更少的缺陷和更可预测的时间表，以及程序员们是否愿意沟通和贯彻他们的承诺。当客户开始期望这些，而程序员们却不打算这么做时，问题就产生了。用敏捷开发标榜自己，却不去遵循敏捷开发的价值观和原则，最终将导致程序员与客户间糟糕的关系。

    InfoQ: 作为一个社区，我非常担忧这种情况，当敏捷开发起作用时，我们夸耀自己，而敏捷开发行不通时，我们彼此踢着皮球并且说这样做不“正确”。如果敏捷开发更像是价值观而非规范或特定的习惯，那么一个机构如何才能知道何时他们真的在进行敏捷开发呢？如何才算正确地进行敏捷开发呢？

    KB: 你描述了人们对结果不满意时的反应，但你忽略了人们从中学习到经验的机会。我想，因为我们怕难为情，我们已经错过了许多分享和学习的机会。

    有时我们会想，“假如我是一个完美的程序员，这个项目应该就会非常成功了。如果项目不是轻松完成，那我就算失败了。”这种心态或多或少地影响了我们的行为。

    而且确实，当你承认失败时，敏捷开发社区中的人们会斥责你的失败。在避免这种令人胆战心惊的结果的同时，我们与那些有用的心得失之交臂。

    成功的项目需要许多因素以及彼此的同心协力，一个人无论多聪明或者多么卓越，项目的成败都不可能由他一个人的技术能力和意志力决定。无论如何，沟通、团队建设、时间安排、与公司其它部门协作、甚至编码窍门等，这些东西都是我们可以从失败的项目中学到并应用于未来项目中的。如果我们愿意分享心得（而不是我们的失败感），那么作为一个社区，我们还可以做得更多。

    敏捷开发一词的含糊性会成为一个障碍。问“我们做得正确吗？”（或更可能的情况——告诉别人“你做得不正确！”），这个问题并没有什么价值。“我们在学习所有我们能学到的吗？”和“我们需要改变自己来最大限度地迎合公司的目标吗？”这两个问题更有意义。如果敏捷开发成为一种意识，那么我们并不真的需要衡量正确与否的尺度了。你工作时有敏捷开发的意识吗？你尝试过从多个角度看问题吗？你会突破桎梏去思考吗？你会参与到团队交流中，共同向一个有价值的目标去努力吗？你会以坦荡诚实的胸怀和负责任的态度向你们共同的目标努力吗？你参与的流程如何在组织中起作用，其意义远比一个敏捷开发专家对流程的思考要重要。

    InfoQ: 在您帮助机构向敏捷化方向成长的经验中，这些问题有一些明显的规律吗？为什么机构通常总是无法正确地开展敏捷开发呢？

    KB: 通常的情况包括我们缺少沟通，团队和成员彼此孤立，办公室里没有交流，某个人有团队所需的特长却没人愿意与之合作，或者无法表达清楚他们最近的工作对公司的价值等。

    机构层面的失败往往是由在流程定制和融会贯通方面的无能为力导致的。尝试直接将别人的模式照搬到你的组织并不会起到太好的作用。这样做将遗漏上一个成功案例中的太多重要细节，同时也会忽略你公司的特殊情况。生搬硬套的敏捷开发流程并不敏捷。基于敏捷开发原理的流程其价值在于，你能够将原理应用在针对你的情况的特定流程上，而且一个额外的好处就是你能够以此心得来改变你的组织。这才是“定制”。

    从个人角度来看，我认为最大的问题是——程序员压力太大。我曾经做过一次“放松工作(Ease at Work)”的讨论，你可以在Google Video搜索中找到视频。除非程序员能够保持一个清晰的自我认识，否则关于后续技术改进的探索将在很长的时间里一无所获。我确信这里同样存在一些属于机构的大问题，但问题的根源在这里。

    InfoQ: 在向机构介绍敏捷开发时，您会首先展示实例，然后借此来说明它的价值，或者恰恰相反？又或者在一开始就同时举例和说明价值？当您打算尝试去改变一个机构的价值体系时，您会选择哪种方式呢？

    KB: 我首先从人们已有的正面经验切入（这种方式被称为肯定式探询），并了解这些经验如何应用于现有情况。这将引发三个层面的讨论——价值观、原则和习惯。

    改变一个机构的价值体系需要强有力的支持，这种支持往往来源于机构中希望变革的高层。我倾向于尝试去引导这些机构发生改变，但这一般不起作用。相反地，我先与他们共事并按照他们的方式做好工作，当我通过这种方式首先表达了我对他们的尊重之后，效果才是最好的。这样做，我仍旧保留了我的价值观，原则和习惯。随着时间的推移，我们彼此取长补短。

    InfoQ: Scrum社区借其认证过程（译者注：Scrum社区是澳大利亚的一个关于敏捷开发的技术社区，它要求用户展示自己后，才向用户提供帐号。）在创立一个品牌。您认为这种方式有助于使敏捷开发在大机构中如鱼得水吗？通过这种方式推行敏捷开发是好是坏呢？

    KB: 我认为这种方式使得专家们要对自己的技术和成果负责。传统的认证过程不过是做个测试，提供一篇论文，我不认为这样的认证过程能有什么用。另一方面，其它的专业领域也存在有意义的认证过程。如果你是持证的内科医生，这意味着你通过了相应的认证。尽管这个与计算机中的认证相差甚远。认证的主考官都是专家，它的过程耗费很多时间和金钱，需要大量的研究和一次在实践中的示范来展示对知识的精确掌握。

    尤其在大机构里，认清名字能够帮助你找对办公室的门，但它仍旧有着照本宣科的问题。如果这被认为是可接受的方式，它就会开始被使用。而一旦办公室发生了一些必需的重大调整，那么这种方式将失去可信度，名字的价值也就不存在了。

    InfoQ: Martin Fowler前不久写了一篇名为“语义传播(Semantic Diffusion)”的文章，在文中他描述了“敏捷”这个术语的变化。当“敏捷”成为另一个口号时，敏捷开发会有什么改变吗？有没有办法来避免这种情况，从而保持理念和语言的生命力呢？

    KB: 当敏捷变成口号以后，人们会寻找最简单的办法来判断何谓敏捷开发。这个语义传播的隐喻的问题在于，意义会随时间弱化的观点忽略了那些明确并且成功的使用术语的情况，这些例子不断出现并保持着术语的原有含义。我一直都在关注这样一种情况，“敏捷”属于一个吸引眼球的词，那些一点都不理解它内涵的人也可能会使用它。谁不愿意被认为是在做敏捷开发呢？敏捷开发这几个字说起来轻松；有价值的思想往往附带着诸多的责任。这就是我们探讨“负责任开发”的原因。在英语中，责任有附带着负担、要求或者义务的含义。有价值的思想意味着许多东西，但同时它并不是那么轻松自由的。

    当你将思想公之于众时，别人如何利用它是你无法控制的。我能做的仅仅是尽全力去保留思想的火种，诚实地报道社区中发生的一切。

    InfoQ: 自您完成《Extreme Programming Explained》（中文版《解析极限编程：拥抱变化》）第二版至今，您有没有发现可以被加入到第三版中的新的价值观，原则或习惯呢？

    KB: 关于XP，我并没有什么新的体会。但我在工作中发现一些对做决策有帮助的原则。

    我已经开始参考一些并没有列入第二版的原则了，这其中包括问责性和透明度。我探讨了这两大出自于测试驱动开发的原则，对它们加以明确并随即验证。最终，我发现这些能够降低流程损耗的原则非常有用。

    随着实践的逐步深入，我不久前使用的最重要的东西就是追踪和分析软件的真实使用状况。目前在我参与的一个项目中，我们实现了对用途的追踪，这好比在黑暗的房间中点亮所有的灯光，那些用户切实使用的功能将一目了然。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14639675/viewspace-567136/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14639675/viewspace-567136/