2005年6月，来自信息产业部、北京市科委、中国软件行业协会的领导，北大、北邮软件学院的院长们齐聚一堂，和世界五大软件开发教父之一的matin(马丁-福勒)先生一起，就目前西方软件开发领域的新趋势，以及其在中国的应用展开了热烈的讨论。
以下为本次会议文字实录全文：
主持人：
首先感谢大家来参加这次由赛迪集团协助，ThoughtWorks公司主办的软件开发模式研讨会，我是ThoughtWorks公司在中国的副总经理，我是郭晓。今天我们研讨的主题是成熟应用、敏捷开发。我们都知道中国市场是现在世界上变化最快、增长最快的市场。在这种情况下软件市场也有对适应迅速变化的要求。这面临着挑战，开发成本太高，需求变化又频繁，如何在这种情况下提高软件的质量，做不到这点会影响软件业本身的发展，如果大家找到一个很好的办法解决这个问题，无论对用户还是软件企业都是很好的事。今天我们容幸地请到了世界上最有名的五大软件开发专家之一马丁.福勒先生，给我们分享一下西方软件发展趋势。同时邀请到了中国软件协会陈冲理事长、科技部火炬中心软件处李冰副处长、北大软件学院的陈钟院长，北邮软件学院的宋茂强院长、北航软件学院的原仓周博士、中国计算机报的高级副总编郭晓女士，CCID的曹方博士和顾建萍处长。
下面首先请Martin Fowler和Sidney G.Pinney简单介绍一下我们公司。
Sidney G.Pinney：
首先非常感谢大家，今天非常容幸有机会和大家见面。我的名字是Sidney G.Pinney，我是思特沃克中国公司的总经理。主要是两件事，首先我想简单介绍一下ThoughtWorks公司，接下来会介绍一下马丁.福勒过去所做的事情，便于大家的了解。
ThoughtWorks公司成立于1993，公司唯一的目标就是创建具有创新性的、实用的定制软件，同时我们也希望能够成为世界上所有对软件有兴趣的人才最向往的公司之一。我们主要是做三件工作，第一是咨询类，客户主要是全球一千家大公司，给他们做一些架构分析、方法研究等等方面的工作。另外一些主要的工作是帮助其他公司在内部实现敏捷开发的方式，斯坦福大学最近想进行敏捷开发就找到我们公司帮助他们做这件事。最后是我们公司最主要的业务，就是软件开发本身，我们通过敏捷开发的办法可以在最少的时间里，用最小的努力，把最高质量的软件交付给客户。我们今天有幸请到了马丁.福勒先生就我们最主要的题目跟大家探讨一下敏捷开发方面的问题。
虽然我们公司很小，但在世界范围内知名很高，一些世界知名咨询公司经常把我们一些大公司进行比较，我们过去的增长在50%以上，过去两年我们公司增长了两倍。我们公司的总部原来在芝加哥，陆续在澳大利亚、加拿大、英国、印度、中国开设了分公司。我们公司有很多软件开发人员，马丁.福勒先生是我们最优秀的开发人员之一，稍候他也会做主题发言。
大家经常会问我两个问题，我提前回答一下。一是为什么选择进入中国？二是为什么选择现在这个时机。我们认为中国现在正处于软件开发历史上非常有意思的十字路口上。我们公司定位于以全球为基础的高端软件交付公司。我们这种敏捷式的开发方法，对中国现在来说可以非常有效解决现在面临的很多问题，可以以很小的代价快速开发出高质量的软件，这也是我们现在选择中国作为投资方向的原因。中国人非常聪明，目标高远，有开放性的思想，这个时候把我们公司的产品带进来，会有非常好的成果。非常有机会来到这里跟大家交流，希望马丁.福勒先生把敏捷开发这个观点给大家解释一下，看看对中国软件开发有什么好处。
我知道你们今天不是来看我的，而是听马丁.福勒演讲。很容幸我跟马丁.福勒先生有六年的合作时间，很多人都有这个问题，马丁.福勒先生在公司具体做什么工作。可以说马丁.福勒先生给我们公司产生的影响是所有人中最大的，他把很多非常聪明的软件人才吸引到公司，建立了一个合作又充满竞争的环境。
下面我简单介绍一下马丁.福勒先生最近的成果。首先马丁.福勒先生在面向对象技术领域是世界上知名的科学家之一，他是世界上面向对象技术、软件模式、UML架构构件语言、重构以及敏捷式软件开发这几方面大家公认的领导者之一，同时马丁是很多知名IT业杂志的编委。马丁是模式领域的主要科学家，主要研究方向是企业应用及架构方面。在敏捷式开发、极限编程等方面是最具影响力的专家之一，敏捷式开发有一个敏捷开发宣言，他是当时提出这个宣言的几位科学家之一，是敏捷联盟组织的创始者和主持者之一。在很多场合做过各种演讲，各种会议都希望可以请他来做主题演讲。今年晚些时候他会在“面向技术”的大会上做一个主题演讲。
简单介绍一下马丁.福勒出过的书和文章
《分析模式》、与人合著的《计划极限编程》
另外《分析和比较分析面向对象》对面向技术设计理念进行综合总结。
《UML提炼》，是第一本描述UML语言的一本书。
写过《重构》这个技术是马丁.福勒先生提出的，对于软件业尤其是软件开发方面产生了很大的影响。最近写了一本书叫做企业级应用架构模式》。去年被Serve .COM网站把马丁.福勒先生评为“方片尖”，他同时也为微软做了一些工作，是微软架构委员会的成员之一。此类介绍再说几个小时也没有问题，马丁先生在过去几年为我们公司的发展做出了巨大的贡献，今天很容幸请到马丁.福勒先生跟大家交流，包括西方软件开发方面的经验。我们非常容幸可以请到各位、专家领导来到会场，希望可以共同分享我们所想到的西方的经验能对中国带来的好处和影响。
谢谢大家！
Martin Fowler：
可能Sidney先生把我说得太好了，我有点不敢当了。如果大家感到失望的话，请原谅我。我今天想把主要的精力放在探讨敏捷式开发方面。
软件开发行业目前同时存在两种情况，它既是一个非常成功的又是具有很多问题的行业。一方面软件已变成我们在日常生活中不可缺少的部分。有些可能不是非常明显，直至有问题出现的时候才发现。一个非常有名的例子就是几年前有家航空公司的计算机系统有一天不能正常工作，结果造成了很大的混乱和巨大的经济损失。我并不是要仔细分析问题的所在，只是想指出软件在各个行业中扮演的角色越来越重要，互联网的使用已极大地改变了人们的生活、工作方式。在西方，普通客户购买东西的过程中，经常把决策的过程使用在互联网上。所有这些软件所带来的影响，对于三、四十年前的人来说几乎是不可想象的。
尽管有成功的方面，但软件开发过程中还是经常会遇到一些问题，很多企业在软件方面花了大量的金钱和经历，但并不是很清楚软件到底能给他们带来什么。一些调查发现世界上很多软件项目其实都失败了，也许这是因为在软件开发过程中，很难定义成功与失败这两个不同的概念。我们在软件界就是注重怎么预见软件开发的不可预知性，我们想象出了各种各样的技术、工具以及流程使得软件开发的过程变得越来越可以控制、预测。这种方法有一个很大的问题就是无法有效评估软件开发过程的有效性。在很多其他的产业界，可以用简单的办法评价过程的进程及有效性，但是对于软件开发过程，很难用一种标准来衡量它的进度和有效性。一个结果就是很难有效判断两种有效的方法哪种更好，使得软件技术、工具以及流程方面的很多讨论都被这种现象所左右。软件开发的过程中有各种问题，并不是新提出的概念。在六十年代末期的时候北约一个软件开发室提出了软件危机的概念，因此他们提出了非常有纪律性的方法即软件工程学，试图从电子工程学、技术工程学提炼出一些东西来用于软件工程学，他们想从中提炼出一种方法，使得软件开发的流程更有预测性。过去三、四年间这种工程学的方法一直为大家普遍使用。但软件业的人在做软件的过程中发现这些方法并没有减少软件开发过程中遇到的问题，对于这种现象有很多解释。近年来有人发现软件工程学里一些基本的假设是不正确的，并使用了一些新的开发方法，我们将其统称为敏捷式开发。
敏捷式开发有很多特色，今天我主要集中介绍两方面的特色，我会重点介绍一下它就软件开发文化有什么样的影响。前不久我在我的网页上发表了一篇文章“新方法”解释我对敏捷式开发的看法。下面我介绍一下敏捷式开发与传统开发相比最具特色的两点。
敏捷式开发采用适应性方法，而传统的软件工程学采用的是预测性方法。敏捷式开发是以人为主的，而传统的工程学是以过程为主的。我下面详细地介绍这两方面：
适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学里，核心的概念就是把设计和构建这两个过程分开进行。最开始一个阶段叫设计阶段，在这个阶段所有跟软件设计相关的重要决定就已做出了，而且以完整的形式描述出来。这项工作通常是由一小部分非常专业的人来做的，而且他们所花的时间和精力在整个项目中占着很小的一部分。这项工作完成以后，这些设计的结果，从建筑学的角度就被“建筑公司”拿去，按照设计的结果一步步构建。在描述清晰的设计图纸的基础上，你就可以据此对构建过程进行详细的规划，并进行成本的预测。但是现在大家对这种过程是否非常适合软件开发行业存在着争议。这里经常会问到一个问题，就是这个过程要花多长时间，对于这个问题有各种不同的回答。在传统的工程学中设计过程在整个项目开发过程中只占10%左右的时间，但是很多软件开发权威机构都认为软件设计过程在整个开发过程中占百分之四、五十的时间，它明显告诉我们这里有些东西是不对的。在软件开发的过程中，我们很难想象，如何真正把设计和编程完全区分过来。软件工程学领域，所有在这里从事工作的人员，都把设计的过程想象成用图表、图象的方式来描述结果的过程。很多人都有这样的经验，没有经过编程而是直接想象出的设计，在进入编程阶段有很多地方是错误的，需要改正。而且从我的观点来看，几乎没办法进行有效的设计。还有一个更重要的问题就是说，软件本身的需求是在变化的。一个项目在开发过程中需求会出现变化，需求的变化从根本上推翻了工程学方法所建立的一个基础。当工程学的人尽量减少或者控制系统将来发生变化的可能，他越这样做问题就越容易出现。既然我们没办法避免变化的发生，那么我们就想找到一种新的方法能够更有效地适应这种变化现象。这也就是敏捷式开发方法所要达到的效果。
最开始的时候，软件开发的过程，我们应该想到软件开发和其他的工程学是完全不同的学科。首先我们想象一种叠盖式、循序渐进的软件开发方法。软件的构建过程中是以小量的叠盖过程增加，而在这个过程中软件一直处于可使用状态。我们ThoughtWorks在软件开发的过程中每两周都会得到一个可以工作的软件。这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。使得客户可以更有效地参与到软件开发的过程中来。这同时也解决了软件开发中非常重要的问题，就是开发人员和终端客户交流的问题。这也使得软件开发本身可以更有效地适应业务本身需求的变化。对于一个发展变化非常快的国家，比如中国这种方法的好处是显而易见的。这个方法从理论上讲并非更简单，需要在实践的过程中学习如何使用叠盖式的开发。这种东西就是当你真正学会如何使用叠盖式开发的时候，才能发现它真正能带来的好处。如果真正在软件开发过程中实现叠盖式的开发，同时需要软件行业本身，以及业务部门本身共同的努力。如果可以实现软件开发部门和业务部门的紧密合作，本身就可以避免西方软件业发展过去所犯下的一些错误。另外一方面敏捷式开发是以人为核心的方法，而不是像过去工程学是以过程为核心的方法。这种现象是过去一些人专门研究软件开发的过程专门有一些实践。经常发现一个现象，软件项目开发的成功最核心的因素是这个软件团队里有非常优秀的人才的协作。这既意味着团队中有非常优秀的个人，又意味着团队中的人能有效地进行协作。这种协作方式通常情况下是跟这些人如何处理他们之间的关系有关而不是采用什么样的过程。工程学当中他们所采用的过程是尽量减少人在这个过程中所扮演的角色。在敏捷式开发中，提出的观点就是人在整个软件开发当中是最重要的因素，至于在这个开发过程中使用什么样的方法是次要的因素。这对于软件开发文化来说意味着什么呢？首先它意味着在提高软件开发效能中最重要的一点就是如何提高个人的能力，其中教育扮演着非常重要的角色。这也同时意味着软件开发团队在这个过程中是被如何对待的。很重要的一件事是如何为软件开发人员提供一个有效的环境，让他们为软件开发行业做出最大的、有效的贡献。而且还要提供这种环境使软件开发人员与终端客户进行有效的交流、合作。
我在ThoughtWorks工作发现这种方式可以造就一种特别的企业文化，在西方擅长软件开发的人员往往都是一些怪才，这些人是真正喜欢软件、喜欢编程的。他与其他的人往往有不同的想法和对生活的追求，很多程序开发人员和客户进行交流过程中，遇到的困难真正的核心所在就是文化上的差异。我不知道这种文化上的差异在中国是否也出现，在印度已出现了这种情况。非常重要的一点就是认识到软件开发人员和终端客户之间交流问题的所在。就像刚刚提到的，没有一个真正可以衡量到底不同的软件开发方法哪种好、哪种不好。这就是因为我们不能非常有效的，以一个非常公正的标准来衡量软件开发哪个更有效。包括我在内，从事敏捷开发的人员，会发现在软件开发过程中敏捷开发是非常有效的方法。西方软件业敏捷开发还是非常少数的团队，但其增长速度非常快。
我们希望在新的软件开发环境里，这种新的方法可能有更快的增长。如果能在软件开发过程中有效地避免开发客户和开发团队交流的问题，那么你就可以避免很多在西方软件开发中遇到的各种问题，当然同时也会发现一些其他新的问题。
我就简单介绍到这里，下面跟各位领导、专家进行讨论。
(讨论阶段)
陈钟：
马丁做了一个精采的报告。在中国软件发展阶段，引起了全球各行各业的瞩目，包括全球软件业的一些方法，以及软件公司的发明人、创始人、传播人都纷至沓来。在最近不到一年的时间里，包括马丁在内，一些世界级的大师我都有机会见到。今年国际软件工程大会已开了29届，从95年我们就开始参加这个会议，十年间我们讨论的问题，短短的一年内很多大师纷纷来到中国，中国企业级人士也逐步关注、参与进来。大家经常提到高长难问题，软件开发难度高、研制周期长，周期性难保证。现在讲软件工程的时候，大家也面对这个问题，刚刚马丁也提到这样的问题，我们现在有大量成功的案例，也有大量失败的案例，不断出于新需求的发展、出于技术的进步，出于改善陷在改进我们原有的系统。现在软件工程要由手工作坊式变成工业化的方式生产。
马丁刚刚讲敏捷式开发更注重人，这对传统工程学是一种叛逆，从个人角度我是赞同的，但这里又有一些困惑，成功、伟大的软件总是有一个伟大的设计师。可以举出很多的例子，包括应用软件、定制软件开发，很难相信一个没有经验的人可以一下做成。一个成功的软件跟一个优秀的软件设计者是联系在一起的。但软件工程学确实有很多原理要告诉大家，做软件不是很随意的。前面设计上的一点点缺陷，就可能带来今后非常大的损失，有很多被验证过的软件工程的原理。那么到底软件的构造是艺术还是工程？马丁也讲到了人非常重要，教育体系也是非常重要的，那么这个过程中是教大家把它作为艺术看待，还是把它作为工程来看待。希望马丁就这个问题再深入阐述一下他的观点。
马丁.福勒：
首先我同意在软件开发过程中软件设计过程是非常核心的部分，敏捷开发社区当中的所有人都同意这个观点。《敏捷宣言》中有十二个基本点，这个观点是其中之一。有一个最核心的问题，就是到底设计要和编程同时进行。这也是我的观点，也是很多其他人的观点，就是两者是结合在一起的。对设计活动本身有一些不同的观点，比如说敏捷开发人员他们认为设计是不断进行的一项活动，这就使得我本身受到了很多影响。我把注意力放在重构概念上，是因为我认为软件设计是在编程进行到一定程度后然后再进行设计活动，这也是从事敏捷开发人员所关注的一点，想开发出这种技术，让设计概念能够不断演变。在不同的技术中最核心的一点就是测试概念，这是从极限编程中提炼出来的概念。很多从事极限编程人员，发现在实际的操作中概念测试系统开发使得系统的设计可以不断演变，在这个过程中扮演了很重要的角色，这也是我们ThoughtWorks内部开发软件过程中所发现的一点。如果说从哲学的角度上讲，到底软件设计是艺术还是一项工程呢？我很难清晰地说都是或者都不是。我已经参与过很多类似的争论，到底用什么样的比喻来形容软件开发。也许我们要用一种比喻的方式形容软件开发，而把软件开发本身当做一个独立的东西来对待。
陈钟：
马丁在报告中多次提到“变化”，而且他也讲到与其说我们不能够保证他不变，我们应该找到一个方法去适应这个变化。实际上这个变化确实使得我们现在这个世界非常丰富多彩，所以我们希望变化。但是控制变化无论是从工程学还是艺术角度讲都是非常重要的。马丁也提到开发人员跟用户的沟通有很多方面与变化管理相关。我还想问马丁一个哲学问题，世界在变，不同的方法学也在变，到底有什么是不变的，让软件从业人员活得越老位有价值。而不是五年、十年以后，什么东西一变，他就完全没有价值了。让教育系统发挥作用，只要教他一个什么东西，他以后就越来越有价值，薪水也越来越高。
马丁.福勒：
我上个星期在西安做演讲的时候，有一个西安交大的学生就问到一个类似的问题。当时我做了一个类似的回答，对学生来讲，教给他们最重要的东西就是从业生涯中要不断地学习。教给学生怎么真正地掌握这些变化的核心因素所在，使得学生可以有效地根据变化利用新的技术做这些事。我不知道怎样解释，变化是一个绝对的过程，但是这个问题我非常有兴趣，因为我做的所有工作中很重要的一点就是在变化中找到一些部变的东西。我做这件事是出于一种非常自私的原因，因为作为作者，我希望自己写的书可以长时间热销。这也就是我为什么集中精力做一些设计模式方面的工作，把设计当中的一些概念以模式的方式提炼出来，这些模式可以运用于不同的编程语言中。这也就是我为什么也在寻找设计的方法，使得它能够在不同的技术环境下重复使用。比如我个人认为面向对象设计技术在软件界很长时间内将会处于核心位置，测试开发技术也将在很长时间内存在。对学生来说很重要的是让学生经历各种各样不同的技术。比如在敏捷开发过程中，人是第一位的，过程是第二位的，所以作为一个个人来说，应该可以找到各种不同的过程，找到真正适合自己的过程。因为我们没有非常客观的对软件开发有效性进行衡量的标准，只能是遵循软件开发人员认为最有效的方法。比如对学生来说很重要的一项技能，就是快速、有效地测试、评估各种不同的方法，从而找到最适合自己的方法。
陈钟：
我第三个问题是敏捷开发现在还是“少数民族”，尽管在教学中分配了一定的时间向学生介绍这种方法的存在，但尚未形成系统教育。在大家用得不够普遍的情况下，马丁说这个方法非常有效，但对方法度量没有客观标准，你希望更多人采用敏捷开发的方法，要采用什么方式来说明其有效性？把这个方法用好，把软件开发做得很好，与人的关系是很大的。我们知道在传统的软件工程领域中，我们也会注意到一个人生产率的高低跟它的一些素质、背景有很大的关系。敏捷开发方法掌握与否是否也跟个人的个性和生产力有很大的关系？在这种情况下，马丁是什么样的观点？一个人是否适合掌握这种方法，是否适合做软件开发，是否可以通过他的IQ或EQ值告诉他一辈子做软件或者说你不适合你就别做了。
马丁.福勒：
先讨论第一个问题，就是如何说服其他人敏捷开发是一种有效的方法，在软件开发过程中没办法绝对地判断一个方法比另一个方法好，就是因为我们没办法有效测量软件开发本身，只能依赖我这样的人，从我主管的角度来说这个方法好在哪里。我说的东西跟他们经历的经验有类似的地方。有些人可能会对我刚刚说的一些想法有兴趣，想去试试，这就是方法传播的过程。我们看极限编程发展的过程，在最开始的时候是两个人在描述他们的一些心得和经验，有些人看了这些东西发现这些想法有道理，就逐渐尝试他们介绍的东西。当然并非所有尝试的人都成功了，但成功的那些人就会把自己的心得和体验介绍给其他人。这种传播方法乍一听可能很遗憾，如果有一种客观的测量方法当然更好。但我们必须意识到软件开发过程是很独特的，软件并不是唯一一个难以用绝对方式测量的行业，商业、教育业都面临同样的问题。在其他行业即使没有一个客观的衡量标准，人类在这方面也有很大的进步。当然这不及有一个客观、有效的测量方法好，但并不意味着没有一个良好的发展方向。怎么衡量作为一个个人是否适合软件开发，我可以简单介绍一下ThoughtWorks公司是怎么做这件事的。我们将其作为业务衡量中非常重要的过程，我们从不同的角度和层次来衡量个人软件开发的能力。首先就是看他们是怎样编程。我们也通过其他的测试方法测试他们的逻辑能力以及其他方面的能力。还有很重要的一点就是测试、衡量他们与其他同事进行合作的能力。在软件开发行业中，非常重要的能力就是怎样在一个团队中与其他人进行协作。这既意味着与其他技术人员进行合作也意味着与终端客户进行合作。对于新来到这个环境中的人，很难对他做出一个非常正确、客观的评价，就像我们做其他事一样，我们尽最大的努力去做。至少从目前的结果来看，公司里的人大部分是符合软件开发过程的人。我担心的是没有进入到我们公司的其他人其实也可以进行有效的软件开发的。一个非常有意思的现象，计算机专业背景对于软件开发人员来说并不是非常重要的环节。我们公司最高层的开发人员都是其他学科的背景，像郭晓过去在北大学的是化学而不是计算机。最终的衡量方法是看一个人在一个项目上的开发过程是如何进行的。
陈冲：
什么方法对我们的软件开发更便捷？中国应用敏捷开发的时机是否成熟？下一步软件开发会往什么方向走？因为现在软件开发原代码越来越长，质量也难以控制。以前我们控制过程，使其越来越规范，我们现在基本讲的还是软件开发的过程。软件工程是控制人员，但软件开发人员是最难控制的，而且还不能消磨了软件开发人员的创新性，而这两者是相矛盾的，如何协调？
马丁.福勒：
第一个案例请郭晓讲一下。
郭晓：
我们公司之所以做敏捷开发是五、六年前我们公司有一个非常大的项目，给一个租赁公司做一个逻辑软件，我们用传统的方式做了半年的时间，但是客户有很多新的需求，这个项目正处于失败的边缘，如果这个项目做砸了，我们公司也就完了。这个时候我们请到了马丁.福勒先生，用敏捷开发、极限编程来做。当时我们印象里敏捷开发都是在二、三十人的团队实施，我们公司可以说是第一个将敏捷开发用于大团队的开发，我们把文档全部扔掉，采用敏捷开发方式，只用6个月的时间客户就看到一个核心软件。我们公司现在大小有上百个项目，小到二个人的项目，大到几百个人的项目，都是用敏捷开发的方法做的，成功的案例有很多，我们可以挑出一个来做进一步的探讨。
马丁.福勒：
我补充一点，大家手里的资料中有一个CD，里面有一篇文章进行相关的介绍。关于第二个问题，我认为中国没有很大的历史包袱，在很大程度上对敏捷开发是一个优点。一些大的公司存在很多历史性的问题，而在没有很多历史包袱的情况下，采用叠盖式开发是非常容易执行的。各个不同的国家和机构软件开发的历史对其到底能否使用敏捷开发没有什么影响。我看过一个研究报告，其中指出测试驱动开发对于一些经验不多的软件开发人员更为有效，在新的环境中使用新的方法可能更好。比如印度它在CIF方面做得很成功，如果我们不想出一些新的方法就很难超越他们。通过一些新方法不会总是处于跟随状态，而是可能超越过去。关于第三个问题，下一步我们会做哪些工作。首先要认识到如何进行有效的软件开发，事实上在这方面存在众多不同的观点，没有人真正知道或者回答哪个是最有效的方法。我的这些观点是从我过去的经验和个性总结出的一些东西。而且是建立于其他一些从事敏捷开发的人的经验的基础上。我们过去得到的最重要的教训，就是不要把所有的精力都集中于一个方法上。我认为其中最主要的成功因素，就是使各种不同的方法都可以实施，让他们之间互相竞争来实际找到最好的方法。过去很多人是通过其他人的成功应用来找到最适合自己的方法，从外部来看这可能是一个非常混乱的方法。从人类历史来看，竞争、合作同时存在的多元体系通常情况下可以得到最好的结果。中国是一个非常大的国家，有能力尝试各种不同的东西，这对我们来说是一个很好的条件。所以我的建议是在听我说的同时也听一些与我不同的意见。
宋茂强：
去年《软件工程师》介绍过马丁先生的方法，我个人非常感兴趣。我有十多年的软件开发经验，我本人也喜欢使用自己的方法开发软件，而不愿意受死规矩的约束。我觉得敏捷开发是一种比较好的开发方法，敏捷开发可能适合于定制软件，因定制软件客户对需求不明确或者在开始时不够明确，因此敏捷开发比较适用。如果我们开发要求明确的系统软件，敏捷开发可能就不是最优的选择。所以我们的软件企业在选择的时候要根据自己的特点。中国目前定制软件的需求非常大，尤其在信息化进程下，很多人不知道自己要做成什么样，但他又需要信息化，敏捷开发是我们可以参考的方法，不要墨守成规。国内很多企业要通过CIM认证，我有一个看法是看企业本身从事什么样的开发，如果是从事定制软件的开发，那种方式成本太高，而且也很困难。我想提一个建议，这个方法要想让更多人使用，能不能把这种方法带到课堂中，作为课程向学生教授。因为北邮的学生出来之后大量地面临定制软件的开发。
马丁.福勒：
简单回答是的，其他一些大学已经在讲敏捷开发，我们ThoughtWorks本身也在做类似的工作。我们公司在印度有一个分公司，与印度一些大学合作教授敏捷开发的课程，有一位主要教授课程的富兰克.乔治先生现在正在上海。富兰克.乔治也在北卡罗来纳大学教授过类似的课程。除我们公司以外，还有其他一些人在做类似的工作，比如约翰先生在大学里教类似的课程。我的建议是请相关人员跟你谈谈心得。
李冰：
我有一个问题，现在敏捷开发是一种比较新的方法。它有几个比较关键的地方，如果要做好一件事，各方面都要做好，一个方面的失败就可能导致全盘失败，那么使用敏捷开发方法要注意哪些方面？
马丁.福勒：
我认为在敏捷开发的过程中不光是包括敏捷开发，在其他所有软件开发过程中如何有效地与客户进行交流是非常重要的因素。比如敏捷开发中采用叠盖式的方法，就是快速地把软件交给终端客户，让他们不断地看到开发结果。使用这种叠盖式方法最大的优点可以很早地看到项目开发中的风险所在。因为你能够不断地得到可使用的软件，并交给客户使用，这个时候就可以判断软件使用过程中质量如何，有效性如何，是否是客户真正需要的。敏捷开发使用更短的循环方式，提高反馈的效果。在ThoughtWorks我们一般是使用一周到二周的叠盖循环。对于软件交付成功最重要的一点是交到客户手中的软件是否是其所需要的，从而不断得到客户的反馈。
曹方：
我有两个问题，第一在中国软件产业市场中最具有生命力的市场是电信、金融、证券服务、网络游戏。敏捷式开发方法在这些市场占有率非常高的行业中鲜为人知，那么如何解决市场认知、应用？软件技术有一个很重要的发展趋势，就是面向构建的开发方法，面向构建的开发方法和敏捷式的开发方法，交汇点和本质的区别是什么？
马丁.福勒：
无论是敏捷开发使用还是其他方法的发展过程中，很多时候刚开始只能找到少数人愿意尝试。通常情况下他们使用这些方法的原因就是在一些人介绍后他们发现其中的一些道理与他们所想的是一致的。他如果通过这些方法真正解决了所面临的问题，那么他身边的人才会愿意使用这种方法来解决他们所遇到的问题。西方敏捷开发的传播基本是以这种方式实现的。对面向构建的设计来说，最主要的是我们到底怎么看待构建是如何出现的。在构建过程或者服务过程现在有两种最主要的意见。我所见过的第一种方法就是先把基础搭好，然后在这些构建的基础上建立新的应用。第二是收获的方式，就是先把应用搭建起来，从中再提炼出有用的构建。包括我在内很多从事敏捷开发的人都比较倾向于第二种方法。我看到过很多采用构建方式的失败案例，很多构建搭建起来后发现它不能被有效使用，当发生这种事的时候，之前所做的一切都没有意义了。而收获的方式，当你知道它在这种情况下已有效地使用了一次，从而知道以后能否从中提炼出构建以备以后的使用的，即使提炼失败，至少这个项目也是成功的。
宋茂强：
我的学生也做过在使用中提炼构建，这是一个非常好的方法，最近我有一个学生刚写完一个软件。
原仓周：
我国多是中小企业采用的软件多是定制，所以敏捷式开发的确很适合中国。敏捷开发的方法是以人为中心，对人的能力没有一个准确的评价方法，中小企业人员流动非常大，如果把过程放在第二位，当人员发生变动，如何用其他人来顶替？
马丁.福勒：
我在西方也见到过很多类似的问题，因为敏捷开发是以人为主的过程，这个过程本身就有问题，你怎么找到合适的人，怎么留住合适的人做这样的事。有一个最基本的问题就是问自己为什么这些做得非常有效的人要离开这个地方呢？无论使用什么样的方法和技术，作为一个企业来说如果不能留住人，无论如何是不能成功的。这个过程中最主要的一点不是找到什么样的人，而是找到人员离开的原因，把人员留住才是真正有效的方法。这种现象背后肯定有很多具体原因，而这个原因每个具体项目都不同，所以很难做出很普遍的回答。我经常遇到一个问题，我发现在这个过程中如果把一个人作为随时可替代的单元，通常会加剧人员流动的现状。
谢腾翔：
马丁先生今天给我们带来了一些新的知识。在中国从软件工程的角度，在某些程度上已落后于某些国家，与印度来说我们也相对有一个落后，今天我听到你讲了敏捷开发，我想做一个总结，只是个人之见可能不一定对。目前中国企业要开发软件首先是要占据市场，有效地管控其成本和费用，对软件开发企业来讲，这是一个根本。您刚刚讲到敏捷开发与传统的软件工程相比，在快速占领市场和节约成本费用方面能否有一个较大的提高，有一个比较明显的推进作用，那么这个比例跟传统相比能提高多少？中国一些企业也在做敏捷开发，微软的开发模式也是叠盖的，这是敏捷开发最核心的部分。我原来的公司是做开发，现在我们做测试，我觉得中国公司说是遵从软件工程，其实是灵活应用，在某些方面也是遵从了软件开发的理论，我们说软件开发是过程控制，不到一个阶段是不能跨越下一阶段的。我不知道印度的情况如何，中国很多企业在需求变化过程中也是在不断重构，实际上它也是叠盖，我们经常开发一个原型，再不断开发新的功能补充进去。传统软件工程和敏捷开发是否有特别本质的区别？有必要将两者明确地区分开来吗？是否可以说两者是软件工程中不同方法的选择或者改进？
马丁.福勒：
很难有一个定量的衡量，软件开发企业最难的就是衡量过程。工程学和敏捷开发之间的区别，所有的方法学之间都有一个量(度)的区别，虽然是叠盖式方法有很多类似的地方，但工程学和敏捷开发有两个核心的不同点，第一对于变化观点是控制还是接受，第二对于人在这个过程中起到作用的评价。如果从传统开发和敏捷开发有一个过渡的曲线，过渡期间有一个突变的过程，就是对变化的态度和对人的态度，这两点是非常重要的变化。
郭旭：
刚刚讲了很多敏捷开发的优势，我们也确实认识到在中国的环境中对敏捷开发的需求非常大，但它有没有什么缺陷？比如在软件交付之后我们用传统的方法开发软件，里面有很多文档，用户可以接过来。而敏捷开发是以人为核心的，那么如果人员发生变动以后，是否对客户造成影响？
马丁.福勒：
传统来说，任何新出现方法的最大问题就是找不到问题所在，实际上很多缺陷都是在直接使用过程中发现的。比如传统上在几年前，很多人认为敏捷开发有一些缺陷，但近几年发现事实并非如此。比如说过去有些人认为敏捷开发不适用于大项目，而我们公司在大项目上使用这种方法证明这种缺陷是不存在的。我们想可能还需要一段时间进行探索，才能知道敏捷开发的缺陷在哪里。关于交付以后文档的问题敏捷开发要尽量减少这些文档的存在。传统方法交付出的那些文档到底有多大作用？我们ThoughtWorks的一项工作就是给遇到麻烦无法进行下去的项目提供帮助，我们在半途进入项目以后，发现他们制作出的文档实际上对理解这个项目没有什么帮助。大部分的文档不是没有完成就是非常过时无法描述现在项目的状态。实际上在很多时候我们发现很多文档对于不是使用这种文档的人心理上是一种安慰，但有效性并不一定非常高。
以下为媒体问答实录
赛迪网记者：敏捷开发对软件跨平台的移植、升级的需求能否适应？敏捷开发是测试驱动的开发思路，现在还有模型驱动开发思路与之竞争，您作为测试驱动的倡导者，如何看待模型测试思路？
马丁.福勒：对于跨平台的移植来说通常存在两种情况。最核心的一点就是从功能角度讲，移植前后是否一致。我自己经历过很多移植性项目，很多时候虽说只是做一个移植，但功能本身也会做很大的变化。通常情况下，很多时候客户会发现在过去的系统中有些功能是不需要的，而有些功能并不存在。在这种情况下敏捷开发的方式是很适合于功能变化的移植。移植前后所有功能是完全一样的，确实不一定是传统敏捷开发能够真正适应的。一些敏捷开发中的最佳实践也是可以使用的，比如你可以把所有的需求以测试的方式提炼出来。很多项目都是使用这种方式而且非常成功。而且使用这种叠盖式方式，也能够从项目进程的角度看移植进程有多快。如果说这个过程中你只是纯粹重复以前的功能，没有加入新功能的话，确实跟客户交流的方面就不是那么重要了。
记者：您刚刚说面向对象的技术将在未来很长一段时间存在，为什么？
马丁.福勒：首先从我个人以及很多其他人的工作经验，OO是一种非常有效的设计、实施软件的技术。从另一方面，这些新出现的主流语言比如JAVA等等其核心都是使用OO技术。事实上我们在OO技术使用过程中还处于非常原始的阶段。虽然以OO为基础的语言已经不断地出现，而且成为主流编程语言，但在使用这些语言进行编程的时候，很多人还是以面向过程的方式来使用。
IT经理世界：敏捷开发是否对做外包的企业有帮助？
马丁.福勒：在印度外包是非常普遍的，我们在印度有一个分公司，专门做欧美外包。我们跟其他公司的区别是即使在做外包的过程中也基本使用敏捷式开发。我们在实践中发现敏捷式开发对外包也是非常有效的方法。如果有机会一定要跟我们富兰克.乔治谈一下，他有一个案例来说明使用敏捷开发与不使用敏捷开发的区别。在跟客户沟通的过程中，我们在开发成本和时间上都比竞争对手少三分之一，我们赢得这个项目，并成功交付。这个公司对外包流程非常熟悉，他觉得我们是否估计错了。因为不是客观的标准，他们用CIM对这个项目进行了重新估算，得到的结论是他确实需要这么多时间和人做这个项目。就是说实践中敏捷式开发比他们估算的方法更快，而且用的人要少一些。
记者：现在中国有很多典型的外包企业，拿到的是设计，他要做的就是编码，那么把设计和编码融合在一起的敏捷开发模式如何应用？
马丁.福勒：一个最简单的回答，在这种情况下没办法真正使用敏捷开发，因为你对这个项目没有真正的控制权。最重要的一个错误已经犯下了，所以在这个时候你没办法修改过程。虽然这个项目不能真正地使用敏捷开发的方法，但敏捷开发的方法有很多最佳实践，从根本理念上有一些方法，有些是从编程中，比如持续集成，测试驱动开发等等。敏捷式开发跟其他方法不同的在于它不光是一个方法学，还是编程中如何提高质量的具体操作，在极限编程里提出的，这些东西都是可以借鉴的。它跟设计没有什么太大的关系，但你在使用过程中可以真正地提高程序的质量，并非要么是敏捷要么不是敏捷。在实际开发的过程中，你还是可以使用叠盖式的方法进行内部的开发，虽然你不能对设计进行大的修改，但是叠盖式的方法还是为提高你的质量，加快速度提供很多帮助。
主持人：由于时间的关系，我们的媒体提问就到这里，再次感谢马丁.福勒先生做的精采演讲。谢谢大家！