Martin Fowler关于敏捷开发的主题演讲

http://tech.sina.com.cn/focus/software_2005/index.shtml

http://tech.sina.com.cn/it/2005-06-02/1427625059.shtml

Martin Fowler：

　　可能Sidney先生把我说得太好了，我有点不敢当了。如果大家感到失望的话，请原谅我。我今天想把主要的精力放在探讨敏捷式开发方面。

　　软件开发行业目前同时存在两种情况，它既是一个非常成功的又是具有很多问题的行业。一方面软件已变成我们在日常生活中不可缺少的部分。有些可能不是非常明显，直至有问题出现的时候才发现。一个非常有名的例子就是几年前有家航空公司的计算机系统有一天不能正常工作，结果造成了很大的混乱和巨大的经济损失。我并不是要仔细分析问题的所在，只是想指出软件在各个行业中扮演的角色越来越重要，互联网的使用已极大地改变了人们的生活、工作方式。在西方，普通客户购买东西的过程中，经常把决策的过程使用在互联网上。所有这些软件所带来的影响，对于三、四十年前的人来说几乎是不可想象的。

　　尽管有成功的方面，但软件开发过程中还是经常会遇到一些问题，很多企业在软件方面花了大量的金钱和经历，但并不是很清楚软件到底能给他们带来什么。一些调查发现世界上很多软件项目其实都失败了，也许这是因为在软件开发过程中，很难定义成功与失败这两个不同的概念。我们在软件界就是注重怎么预见软件开发的不可预知性，我们想象出了各种各样的技术、工具以及流程使得软件开发的过程变得越来越可以控制、预测。这种方法有一个很大的问题就是无法有效评估软件开发过程的有效性。在很多其他的产业界，可以用简单的办法评价过程的进程及有效性，但是对于软件开发过程，很难用一种标准来衡量它的进度和有效性。一个结果就是很难有效判断两种有效的方法哪种更好，使得软件技术、工具以及流程方面的很多讨论都被这种现象所左右。软件开发的过程中有各种问题，并不是新提出的概念。在六十年代末期的时候北约一个软件开发室提出了软件危机的概念，因此他们提出了非常有纪律性的方法即软件工程学，试图从电子工程学、技术工程学提炼出一些东西来用于软件工程学，他们想从中提炼出一种方法，使得软件开发的流程更有预测性。过去三、四年间这种工程学的方法一直为大家普遍使用。但软件业的人在做软件的过程中发现这些方法并没有减少软件开发过程中遇到的问题，对于这种现象有很多解释。近年来有人发现软件工程学里一些基本的假设是不正确的，并使用了一些新的开发方法，我们将其统称为敏捷式开发。

　　敏捷式开发有很多特色，今天我主要集中介绍两方面的特色，我会重点介绍一下它就软件开发文化有什么样的影响。前不久我在我的网页上发表了一篇文章“新方法”解释我对敏捷式开发的看法。下面我介绍一下敏捷式开发与传统开发相比最具特色的两点。

　　敏捷式开发采用适应性方法，而传统的软件工程学采用的是预测性方法。敏捷式开发是以人为主的，而传统的工程学是以过程为主的。我下面详细地介绍这两方面：

　　适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学里，核心的概念就是把设计和构建这两个过程分开进行。最开始一个阶段叫设计阶段，在这个阶段所有跟软件设计相关的重要决定就已做出了，而且以完整的形式描述出来。这项工作通常是由一小部分非常专业的人来做的，而且他们所花的时间和精力在整个项目中占着很小的一部分。这项工作完成以后，这些设计的结果，从建筑学的角度就被“建筑公司”拿去，按照设计的结果一步步构建。在描述清晰的设计图纸的基础上，你就可以据此对构建过程进行详细的规划，并进行成本的预测。但是现在大家对这种过程是否非常适合软件开发行业存在着争议。这里经常会问到一个问题，就是这个过程要花多长时间，对于这个问题有各种不同的回答。在传统的工程学中设计过程在整个项目开发过程中只占10%左右的时间，但是很多软件开发权威机构都认为软件设计过程在整个开发过程中占百分之四、五十的时间，它明显告诉我们这里有些东西是不对的。在软件开发的过程中，我们很难想象，如何真正把设计和编程完全区分过来。软件工程学领域，所有在这里从事工作的人员，都把设计的过程想象成用图表、图象的方式来描述结果的过程。很多人都有这样的经验，没有经过编程而是直接想象出的设计，在进入编程阶段有很多地方是错误的，需要改正。而且从我的观点来看，几乎没办法进行有效的设计。还有一个更重要的问题就是说，软件本身的需求是在变化的。一个项目在开发过程中需求会出现变化，需求的变化从根本上推翻了工程学方法所建立的一个基础。当工程学的人尽量减少或者控制系统将来发生变化的可能，他越这样做问题就越容易出现。既然我们没办法避免变化的发生，那么我们就想找到一种新的方法能够更有效地适应这种变化现象。这也就是敏捷式开发方法所要达到的效果。

　　最开始的时候，软件开发的过程，我们应该想到软件开发和其他的工程学是完全不同的学科。首先我们想象一种叠盖式、循序渐进的软件开发方法。软件的构建过程中是以小量的叠盖过程增加，而在这个过程中软件一直处于可使用状态。我们 ThoughtWorks在软件开发的过程中每两周都会得到一个可以工作的软件。这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。使得客户可以更有效地参与到软件开发的过程中来。这同时也解决了软件开发中非常重要的问题，就是开发人员和终端客户交流的问题。这也使得软件开发本身可以更有效地适应业务本身需求的变化。对于一个发展变化非常快的国家，比如中国这种方法的好处是显而易见的。这个方法从理论上讲并非更简单，需要在实践的过程中学习如何使用叠盖式的开发。这种东西就是当你真正学会如何使用叠盖式开发的时候，才能发现它真正能带来的好处。如果真正在软件开发过程中实现叠盖式的开发，同时需要软件行业本身，以及业务部门本身共同的努力。如果可以实现软件开发部门和业务部门的紧密合作，本身就可以避免西方软件业发展过去所犯下的一些错误。另外一方面敏捷式开发是以人为核心的方法，而不是像过去工程学是以过程为核心的方法。这种现象是过去一些人专门研究软件开发的过程专门有一些实践。经常发现一个现象，软件项目开发的成功最核心的因素是这个软件团队里有非常优秀的人才的协作。这既意味着团队中有非常优秀的个人，又意味着团队中的人能有效地进行协作。这种协作方式通常情况下是跟这些人如何处理他们之间的关系有关而不是采用什么样的过程。工程学当中他们所采用的过程是尽量减少人在这个过程中所扮演的角色。在敏捷式开发中，提出的观点就是人在整个软件开发当中是最重要的因素，至于在这个开发过程中使用什么样的方法是次要的因素。这对于软件开发文化来说意味着什么呢？首先它意味着在提高软件开发效能中最重要的一点就是如何提高个人的能力，其中教育扮演着非常重要的角色。这也同时意味着软件开发团队在这个过程中是被如何对待的。很重要的一件事是如何为软件开发人员提供一个有效的环境，让他们为软件开发行业做出最大的、有效的贡献。而且还要提供这种环境使软件开发人员与终端客户进行有效的交流、合作。

　　我在ThoughtWorks工作发现这种方式可以造就一种特别的企业文化，在西方擅长软件开发的人员往往都是一些怪才，这些人是真正喜欢软件、喜欢编程的。他与其他的人往往有不同的想法和对生活的追求，很多程序开发人员和客户进行交流过程中，遇到的困难真正的核心所在就是文化上的差异。我不知道这种文化上的差异在中国是否也出现，在印度已出现了这种情况。非常重要的一点就是认识到软件开发人员和终端客户之间交流问题的所在。就像刚刚提到的，没有一个真正可以衡量到底不同的软件开发方法哪种好、哪种不好。这就是因为我们不能非常有效的，以一个非常公正的标准来衡量软件开发哪个更有效。包括我在内，从事敏捷开发的人员，会发现在软件开发过程中敏捷开发是非常有效的方法。西方软件业敏捷开发还是非常少数的团队，但其增长速度非常快。

　　我们希望在新的软件开发环境里，这种新的方法可能有更快的增长。如果能在软件开发过程中有效地避免开发客户和开发团队交流的问题，那么你就可以避免很多在西方软件开发中遇到的各种问题，当然同时也会发现一些其他新的问题。

　　我就简单介绍到这里，下面跟各位领导、专家进行讨论。

唉.............
本来是可以亲耳听到的...............

我觉得Martin Fowler到中国来宣传敏捷，从时间上来说，非常及时，也非常重要！在这个中国软件行业的软包型业务急速扩张，规模化生产方式大行其到的时候，我们需要一个足够重量级的大师发出声音，告诉业界，这条路走错了，我们不应该模仿印度模式。

在现场听他讲这些话，听他当面驳斥软件学院的院长，我真是激动到不能行亚。我们在国内宣讲敏捷这么多年，被这么多的人质疑（当然，也有这么多的人赞同），如今终于这敏捷也走进了主流媒体阵地。我们的工作，我们付出的那么多精力，我们吵过的那么多架，都是有意义的。

有没有详细的报道阿？

这里有辩论的详细记录:
http://tech.sina.com.cn/it/2005-06-02/1625625310.shtml

唉呀呀........第一次听到这个词........
以前倒是考虑过这种方式  不过感觉在现在的中国......好像根本不可能实行一样.....这个需要开发人员有相当高的功底了......如果不是非常有经验的话 开发周期根本没有办法控制的........
没想到人家都做了五六年了..............

IT经理世界：敏捷开发是否对做外包的企业有帮助？

　　马丁.福勒：在印度外包是非常普遍的，我们在印度有一个分公司，专门做欧美外包。我们跟其他公司的区别是即使在做外包的过程中也基本使用敏捷式开发。我们在实践中发现敏捷式开发对外包也是非常有效的方法。如果有机会一定要跟我们富兰克. 乔治谈一下，他有一个案例来说明使用敏捷开发与不使用敏捷开发的区别。在跟客户沟通的过程中，我们在开发成本和时间上都比竞争对手少三分之一，我们赢得这个项目，并成功交付。这个公司对外包流程非常熟悉，他觉得我们是否估计错了。因为不是客观的标准，他们用CMM对这个项目进行了重新估算，得到的结论是他确实需要这么多时间和人做这个项目。就是说实践中敏捷式开发比他们估算的方法更快，而且用的人要少一些。

　　记者：现在中国有很多典型的外包企业，拿到的是设计，他要做的就是编码，那么把设计和编码融合在一起的敏捷开发模式如何应用？

　　马丁.福勒：一个最简单的回答，在这种情况下没办法真正使用敏捷开发，因为你对这个项目没有真正的控制权。最重要的一个错误已经犯下了，所以在这个时候你没办法修改过程。虽然这个项目不能真正地使用敏捷开发的方法，但敏捷开发的方法有很多最佳实践，从根本理念上有一些方法，有些是从编程中，比如持续集成，测试驱动开发等等。敏捷式开发跟其他方法不同的在于它不光是一个方法学，还是编程中如何提高质量的具体操作，在极限编程里提出的，这些东西都是可以借鉴的。它跟设计没有什么太大的关系，但你在使用过程中可以真正地提高程序的质量，并非要么是敏捷要么不是敏捷。在实际开发的过程中，你还是可以使用迭代式的方法进行内部的开发，虽然你不能对设计进行大的修改，但是迭代式的方法还是为提高你的质量，加快速度提供很多帮助。

　　原仓周：

　　我国多是中小企业采用的软件多是定制，所以敏捷式开发的确很适合中国。敏捷开发的方法是以人为中心，对人的能力没有一个准确的评价方法，中小企业人员流动非常大，如果把过程放在第二位，当人员发生变动，如何用其他人来顶替？

　　马丁.福勒：

　　我在西方也见到过很多类似的问题，因为敏捷开发是以人为主的过程，这个过程本身就有问题，你怎么找到合适的人，怎么留住合适的人做这样的事。有一个最基本的问题就是问自己为什么这些做得非常有效的人要离开这个地方呢？无论使用什么样的方法和技术，作为一个企业来说如果不能留住人，无论如何是不能成功的。这个过程中最主要的一点不是找到什么样的人，而是找到人员离开的原因，把人员留住才是真正有效的方法。这种现象背后肯定有很多具体原因，而这个原因每个具体项目都不同，所以很难做出很普遍的回答。我经常遇到一个问题，我发现在这个过程中如果把一个人作为随时可替代的单元，通常会加剧人员流动的现状。

我跟马老头是一个意思

　　马丁.福勒：

　　关于交付以后文档的问题敏捷开发要尽量减少这些文档的存在。传统方法交付出的那些文档到底有多大作用？我们ThoughtWorks的一项工作就是给遇到麻烦无法进行下去的项目提供帮助，我们在半途进入项目以后，发现他们制作出的文档实际上对理解这个项目没有什么帮助。大部分的文档不是没有完成就是非常过时无法描述现在项目的状态。实际上在很多时候我们发现很多文档对于不是使用这种文档的人心理上是一种安慰，但有效性并不一定非常高。

太棒了！