熊节：我记得大概是在2001年的时候，我们在《程序员》杂志上做了一次技术专题叫做重构。重构这个思想名词谁提出来，就是今天坐在这里的 Martin Fowler先生。从01年到05年，我们在中国宣传敏捷的思想已经有好几年，现在我们终于有机会可以面对面的听到Martin Fowler原汁原味的讲"敏捷的思想"，现在请掌声欢迎Martin Fowler先生

Martin Fowler：谢谢！我喜欢在台上走来走去，不喜欢站在一个地方。我现在感觉舒服多了，因为Sidney Penney已经把我在ThoughtWorks的地位建立起来，我不用担心以后失业。今天主要是想和大家探讨敏捷式软件开发。

首先我稍微介绍一下这方面的背景。正如我们大家都知道，我们今天所生活的环境越来越依赖于软件这些东西。在整个世界范围，各种业务越来越依赖于软件 进行它日常的运营工作。很多这些工作平常你并不一定能够看得见，但是，如果这里面出现问题的时候是非常明显的一件事情。比如说，最近美国有一家航空公司的 订票系统出现了故障，有一天不能工作，结果自然造成了极大的混乱和很大的财产方面的损失。
现在我们不是说要找出这个软件遇到了什么问题，而是把这 个问题看成软件成功的一个现象，就是它对业务的支持已经到了不可缺少的地步。在更加容易看到的一方面就是国际互联网的这些技术。这种技术使得信息能够在网 络上不断的进行流动，对世界本身造成了很多有益的影响。至少在美国，普通的人即使在本地的商店里买一些什么东西，也要先到网上察看一下有关商品的价格以及 其他的信息。实际上在过去三、四十年里，软件行业是非常成功的一个行业。但同时业务部门对软件也有很多不满的地方，至少我自己一次又一次听到很多的公司谈 到他们非常昂贵的软件失败的案例。所以，我的意见就是软件既是非常成功的，也是失败的一个行业。
对于很多业务方面的人员来说也不是非常清楚，将来 软件到底是走向成功还是走向失败？这个问题并不是一个新的问题。比如说在六十年代末北约组织了一次软件工程学的大会，他们在会议上提出了"软件危机"这个 概念。当时大家的印象，软件已经变得如此的复杂，以至于不能以十分有效的方式来管理。这次会议的后来产生的结果就提出了一种更加有纪律性的软件开发的方 法。这个会议的提出，名词就叫"软件工程学"。这个概念背后的核心就是从传统的工程学里面借鉴一些概念，把它应用到软件开发过程当中来。这个概念背后随之 而来的很多软件开发方面的方法和过程。

这些方法至少在七十年代、八十年代、九十年代变成了大家全部使用的软件开发方法。但是，也是在这段时间，很多的软件从业人员开始怀疑工程学 为基础的方法到底适不适合软件开发。有很多非常成功的软件项目，并没有完全真正的按照软件工程学的方法来进行开发的。与此同时，很多非常失败的软件项目确 实是按照这种方法来进行的。大概在九十年代开始，我们看到很多人开始使用其他一些不同的方法来开发软件，比较有名的方法包括极限编程、SCRUM、 Crystal、FDD等等。虽然这些方法由不同的人、不同的项目来开始开发实施，但是他们之间有很多非常相似的地方。敏捷开发这个概念就是用来描述这一 系列比较新的软件开发方法的。这个词就在2001年在犹它的会议上被选择出来成为描述的词汇。

现在想和大家讨论敏捷开发和软件工程学开发方法的两点最主要不同。第一个最大的不同是，敏捷开发方法以适应性为基础，以计划传统的开发方法 是以预测性为基础。第二个最主要的不同的地方，敏捷开发是以人为基础，以人为核心，计划开发方法是以过程为核心的。我下面仔细的介绍一下这两个不同的方 法。
正像我刚才说过的，以计划驱动的这些方法是以过去的很多传统工程学理面的理念所引导出来的。所有这些传统的工程学，这些分支里面都有一个共同 的特点，就是非常清晰的区别设计和构建这两个不同的过程。以计划驱动的软件开发这些人员通常也喜欢用这种方法来设计驱动软件开发的过程，他们想到的第一个 问题，传统的工程设计图纸在软件行业里是什么样的东西呢？他们认为在软件行业当中，与工程学对应的构建的阶段就是编程。所以，在软件行业就应该先用图象的 方式把整个设计的方案表达出来，然后交给真正编程的人。
我经常喜欢用一个建筑学的例子说这件事情，因为我的夫人就是做这项工作的。比如说如果你想 造一座桥，你开始会把所有造桥的事情都想情况，想到会出现什么问题。这项工作由专门的一系列专门的设计人员来完成的，他们所做的工作，交付的东西是一系列 图纸，以图象为基础描述桥到底怎么建，既包括建好以后桥是什么样子，也包括他们是怎么一步一步把桥建起来的，这些图纸通常会交给另外一个完全不同的公司来 具体的建造这座桥梁。这个设计通常是有足够的细节在里面，这样你可以完全制定一套计划，怎么样一步一步搭建这个桥梁，花多少时间、多少成本、需要什么材料 等等。
现在大家都知道，有很多非常流行的用来图象性的语言来描述设计的，包括Data Flow、Event Driven、UML、事件驱动等等建模语言。我自己在最初开始进行软件开发的时候，我也觉得这种方法非常的有效。而且对于如何构建和改进这些建模方法的 语言，在这方面有很多的心得。这就是为什么我参与了UML方面的工作。但即使我已经对UML语言变得非常熟练的时候，我会发现以计划驱动的软件开发方法还 是有很多的问题。
我想集中讨论有三个最主要的原因，为什么这种方法有点行不通。第一，是一个非常简单的现象。传统的工程学里，设计这个阶段通 常情况下占有整个项目的非常短的时间，比如说只有10％的时间左右。如果你找到任何一本软件工程学的课本，就会发现他们通常是整个设计的40％到50％的 时间，很明显，有些事情在这里面是不对的。第二，在纸上描画出的设计是非常容易的事情。即使在我自己非常擅长在纸上画图形，但是真正的用编程来实现的时候 我发现很多的问题。
当我真正编程实现这个工程的时候，我发现很多的问题在画图设计的时候并没有真正的想到。正是这种发现，这种认识，使很多人开始 来问这样的问题，设计在软件开发过程中所处的时间点到底是对的还是不对的。最后得到的结论是，唯一一个能够准确描述方案的语言不是图象，而是源代码本身。 按照传统工程学的比喻来说，设计的思想是蕴涵在最后真正的建设和部署的阶段。至少我慢慢的认识到，把设计和编程完全分开来是非常严重、非常根本的错误，如 果光设计不编程或者光编程不设计都会产生各种各样的问题。
对我来说，还有一个更主要的原因，按计划驱动的开发方法不成功的原因就是需求本身的变 化。几乎我经历过的项目或者访问过的项目都会有这样一个问题，就是在编程过程中需求还在变化。按计划驱动的开发方法，它花了很多的时间和精力，在需求阶段 尽量把所有的需求确定下来，使他们在开发以后的阶段不会发生变化。但是，在很多其他的软件开发的项目当中，尤其是商业软件，就是我一直从事的商业软件开 发，这种方法几乎是不现实的。在一个项目的早期，很难真正的想象出来到底软件的需求会是什么样的。
即使你在项目的开始阶段能够想象出来项目的需求 是什么样，但是业务本身肯定会变的，在项目需求确定以后还会继续变化，从而导致需求的变化。这种以计划驱动的软件开发方法是整个建立在需求不会更改的基础 之上的。如果这种基础、这种假设是不成立的，整个开发方法都会出现问题。他们的这种方法，我们应该在开始明明白白把软件开发的过程所有可能出现的问题全部 想清楚，这样我们可以完全准确的预测开发过程会有什么样的问题。
敏捷开发的从业人员觉得，如果我们不能够完全避免变化，我们就应该建立一种新的方 法，能够使我们有效的处理将来出现的变化。我们在一个敏捷开发的项目的全过程当中能够很清楚的看到这一点。以计划驱动的开发方法核心就是在早期建立一个计 划，如果一切都没有出现任何问题的话，这个计划就是实际项目当中将会发生的事情。在这种方法里面，计划是在项目开发过程中非常早期建立起来的。在一个敏捷 开发项目当中，计划这些活动是在整个项目的过程从头到尾一直不断的进行的。在敏捷开发里面没有这样的计划，会把将来软件最后的所有的细节全部预测出来，而 这个计划的过程是一个对变化进行反应的过程，就是一个一个的变化会不断的融入到这个计划当中，用来进行真正实现这种方式的核心方法就是把整个项目分割成一 小块一小块的迭代。
这两种完全不同的开发方法的第二个区别就是：以人为核心，还是以过程方法为核心。以计划驱动的核心方法，设计一套这样的方法， 不管什么人，任何人都可以在这套方法中发挥最大的作用。有了这种非常有效的方法以后，这种方法会有很多的角色在里面，这样可以把角色用任何的人放进来拿出 去，只要有人做这个事情就可以保证整个软件项目是成功的。敏捷开发方法对这个问题的看法最好用艾克·卡文的一个观点来解释？他在软件开发的早期是帮助 IBM做关于OO方面的研究工作。他在做这些工作的时候，最主要的任务是访问不同的开发项目，发现成功的项目到底是哪些因素使得这个项目成功。他发现最后 得到的结果非常奇怪，所有的成功的项目他们之间没有一点在过程方面共通的地方。这些项目所共通的唯有一点共通：他们拥有能力非常强、交流非常好的开发团 队。
这个问题的核心在于，以计划驱动的开发方法是以过程驱动整个软件开发的工作。在软件开发的过程当中，其实最核心的部分应该是开发人员本身。但是，以计划驱动这些方法，在这个过程中喜欢把编程人员本身当成计算机来对待，有些人甚至认为软件开发方法也应该像编程一样来对待人。
计 算机和人的区别主要在于，计算机是非常有一致性的，总是不断的以准确的方式来重复同样的工作。但是，人在这个过程中没有持续性，人总是有各种各样的变化， 有时候快，有时候慢，有时候做的好，有时候做的不好。人的优势和计算机的优势是不一样的。这使我们要重新考虑开发方法和编程这两件事情。在敏捷开发社团 里，大家都会觉得，在这个过程中人应该是第一位的，所有的东西都应该围绕着人来做的。一个项目的开发过程的有效性，主要决定于项目的人的能力以及这些人互 相进行合作的有效性。他们使用的开发方法以及他们使用的各种不同的工具，和人比起来是次要一级的因素。
在我们当年写《敏捷开发宣言》的时候，我们 把"人比过程重要"这一点放在第一行上面。我们认为，人和人之间的交互要比方法和工具要重要得多。这其实非常具有讽刺意味，因为我们是一群专门做方法和工 具的一群人。这造成了很重要的一些结果，特别重要的一点，就是说方法是用来适应人的，而不是人来适应方法。作为开发一个团队上面的人本身，他们自己应该来 选择所适合的开发方法。从而就是说，如果真正想建立一个有效的开发团队，最主要不是选择什么方法，而是找到真正合适的、有能力的开发人员，并且使他们能够 有效的相互之间一起合作。以这种方式来选择团队，你所应该注意的开发人员的素质和传统上的以方法为核心的这些人所注重的素质通常是不一样的。
另外 一个结果就是：方法本身并不是固定不变的。一个敏捷开发团队的非常重要的特点就是他们一直在不断的改进他们所使用的方法，直到这个方法非常适合他们自己的 团队为止。一种非常有效的方法，就是在每一次迭代开发完毕以后做一个回顾式的会议，专门讨论在过去迭代过程中开发方法哪些需要改变，哪些需要变化来适应开 发团队本身。这就意味着不光每个开发团队要选择自己的方法，而且它所选择的方法会随着时间的变化不断的改进。
所以，我觉得大家已经看到，在这两种 敏捷开发和计划驱动开发方法之间，他们背后建立的假设和基础完全是不一样的。我并不想说，敏捷开发是对所有的项目来说都是最适合的一种方法。我想我们现在 还是在处于一个探索阶段，弄清楚到底哪些开发方法适于哪些项目。而且应该说敏捷式的开发方法在西方还是属于少数的开发方法。但是，这种方法也是在《敏捷开 发宣言》提出来以后，在最近几年越来越得到很多方面重视的一种方法。比如说在ThoughtWorks我们用敏捷开发方法在项目当中获得了很多的成功。有 效的使用敏捷方法的项目，有些是上百人的大项目，而且项目的团队分布在不的国家和不同的大洲之间。至少对我来说，这是我最喜欢的一种工作方式。
对 我个人来说，我非常有兴趣看到越来越多的对敏捷开发方法的使用，以及它在开发过程中所带来的新的挑战，尤其是敏捷式开发方法对软件开发当中对设计的理解带 来很大的冲击。 在敏捷开发的过程中，一个应用的设计在整个开发过程中是一个不断演变的过程。这也是我们非常有兴趣的帮助设计演变的程序，比如说重构和设计开发。软件开发 当中一个非常有趣的现象是，没有办法绝对的客观来衡量开发方法的有效性。我们唯一能做的就是非常诚恳、非常准确的描述我们自己的经验，使得其他有兴趣的人 做类似的事情。整个敏捷开发社区所做的很多工作，就是在不断的探索敏捷开发的极限在哪里，限度在哪里。我自己非常很高兴能处在整个发现的过程中。 我准备讲的就这些。谢谢！

熊节：我们现在先来向Martin Fowler先生提一点问题，我相信大家也会有很多的问题想要马上请教。不过在大家开始请教之前，我希望把这个机会让给我们CSDN聊天网上的200多的在线用户，看看他们有什么问题。

网友：希望Martin Fowler先生能够解释一下XP、Scrum、Crystal、FDD等等这些敏捷方法之间有什么区别和联系？

Martin Fowler：所有的这些都是在敏捷开发里，大家经常会使用各种不同的方法，在很短的时间里真的没有办法把所有的都介绍一遍，如果你去我的网页叫 Martin Fowler.COM有一篇文章叫《新方法》。在那篇文章里，基本上把我刚才讲的已经总结一遍，而且有很多刚才提到的不同的具体方法当中。

现场提问：很荣幸聆听您的教诲。您刚才说，人在整个软件开发过程中起着决定性的作用。我以前做过开发，现在也做开发，也参加过设计。设计和 开发很容易脱节，Martin Fowler先生说过，设计和开发之间的结合是通过迭代，我想问一个问题，迭代的过程怎样做才更合适一些？

Martin Fowler：首先在你头脑中想象软件是一种什么样的方式。你可以用各种不同的方法来尝试或者描述这种设计本身。比如说你可以用UML的方式在白板上和把 它描述出来，和你的同事讨论这个设计到底是怎么样的。你可以用不同的方法来尝试各种不同的编程，你也可以采用测试的方法来开发这个程序。设计并不只是简单 的画图的过程，要在脑子中想象，怎么样把这个软件做出来，做决定的过程就是设计的过程。只有你真正的尝试的时候，才能够真正的做到你刚才做的决定到底是正 确的还是不正确的，应该做什么样的决定。