敏捷开发在西方的应用和对中国软件业影响

　　【IT168 技术文档】

　　在过去四五十年软件发展中，软件应用规模越来越大，过去几千到几万，到现在的上百万，系统开发复杂程度如果不加以控制，肯定比较难以来操作。70年代中期出现了WF，八十年代中心出现CASE，90年代出现具有代表性就是面向对象结构，规则引擎，最近几年这种波浪式的发展状况，又到了一个波峰时候，最近出现一个新的技术，最有代表性的就是软件开发管理方法SOA面向体系服务架构，以及开放性软件等等。

　　要提到敏捷性开发，必须提到CMM，CMM它是通过使用数值分析方法，对软件开发过程进行不断改进，通过使用CMM，很多软件投资开放方法确实得到提高，但是它的成本太高。还有一个就是证书业务，尤其是CMM创始人，最早在美国军方工作，后来被ThoughtWorks合并了，它对政府业务比较深恶痛绝，比较好的初衷被政府严重扭曲了，很多的西方公司最近几年来，已经逐渐开始使用了这种方法，尤其很多的印度IT公司，也就是最快取得CMM认证，取得效益最好的公司，已经开始改变内部开发方法，逐渐开始转到敏捷式开发。

　　敏捷式开发在西方虽然比较新，最近几年来，逐渐成为一项主流的开发技术，有这样一个数据统计，大概80％的财富五百强企业，开发软件过程中，已经使用。有20％的企业全部使用敏捷式开发。比如我们公司十几年来做了上百个项目，所有的软件项目都是用敏捷式开发方法来做，我们的客户有英国石油，IBM、微软也是我们的客户，比如壳牌石油等等。所有的项目我们都是不管多大的项目，都是使用敏捷式的方法来完成的。

　　First公司是把新技术跟商业服务量化，使用敏捷式方法要求IT和业务方面参与者紧密，敏捷开发在质量上有很大提高。从开发成本上降低62％，开发时间要降低69％，它的这些数据都是建立在很多我们公司包括其他公司使用的一些开发方法，这些公司案例的情况。下面我简单把一些相关的案例稍微介绍一下。

　　比如说美国的一家NI保险公司，有一个项目需要分包给其他公司来做，当时一家印度公司，非常有名的印度外包公司，他们使用的方法做出估测以后这个项目大概200万美元，一年工作日时间，最后这个方法是我们敏捷式方法做出来，一共花了八个月时间，整个项目成本110万。如果按照印度的做法投资回报不到4％。这家印度公司很奇怪，派了另外一批人对这个项目进行重新预测，使用他们的方法确实需要200万美元，12个月的时间，于是他们觉得，后来把我们公司的技术人员请到印度公司总部，给他们五六十个高级管理人员做了培训，他们内部开始使用敏捷式开发方法。

　　从质量上来讲，另外一个例子，这是一个施工管理利用，一共有12万五千，一共12个月开发时间，这个项目因为用户验收测试的时候，花了三个月时间，一共发现12个缺陷，投入使用以后出现全部缺陷只有88个，这么小的缺陷率是非常不容易的事情。另外也是一个例子，就是戴尔公司，他们内部也开发了很多项目，它的很多项目和第三方软件公司一起做，几年以后，把所有合作的公司都弄走了，也就只有我们一家公司了，我们公司敏捷式开发方法，远远比其他公司成本低得多。另外一家是英国的APC公司，营业额达到60亿英镑，这个公司不久以前，决定把所有店面里的计算机系统，就是最后客户买的店面多媒体系统全部更换下来，这个量非常大，而且要和很多内部应用程序和外部供应商结合，而且时间很紧。为什么呢？在前期请了一个非常非常大的很有名的软件咨询公司帮他做了这个项目，花了两年的时间还没有做成，还有八个月要上市了，因为我们在美国做了很多的工作，所以他们决定把我们请过去，使用敏捷式的方法，最后八个月时间，就把这个做出来，到现在为止，在最近一两年，他们最后做到了500，所有的包括底下的一切都更换了。这个过程中，这两百人开发团队有一百多人是我们公司员工，另外几十个人是他们自己IT部门内部的员工，通过这个项目的开发，等于是把整个IT部门里完全使用敏捷式开发方法，产品做出来效果非常好，使得这个零售业平均交易额上升，交易成本大大降低，取得非常好的效果。

　　下面我简单介绍敏捷开发到底是一个什么样的东西，原理是什么样的。提到敏捷式开发，大概在60年代的时候，那个时候软件开发没有计划性的，基本上写完了改，谁也不知道什么时候能够写完，1968年召开软件工程会议，那个会议上，软件工程学概念第一次被提出来，传统的工程学概念介绍到应用到软件开发当中来，于是形成软件工程学的概念。传统的工程学把项目分三步四步，先把需求确定下来，进行设定，进行构建，最后投入使用，应用到软件里，就是开始先有分析人员对需求进行分析，然后让客户签字，交给架构师进行设计，这些架构师把整个详细整体设计出来，使用UM2语言或者其他方法再写成文章，再决定下来。再编程，照着文档把程序开发出来，所有这些是不同的人在不同的时间完成。这种工程学的方法，确实使得软件开发计划性很强，因为你知道什么时候谁在做什么事情，过去几十年确实起到很重要的作用。但是也带来一些问题，比如文件开发和传统的建造不一样，因为软件最主要一点客户需求不断变化，工程学的特点，就是在最开始的时候，需要把需求确定下来，但是软件开发不一样，首先尤其是商业软件，客户市场本身是不断变化，客户需求也不断变化，你很难除了客户自己都不知道市场需要什么，过两天市场变了，需求也变了。

　　第二客户本身脑子里不是很清楚想要什么软件，你如果跟他讲也可能讲不清楚，只能真正自己见到这个软件，才会觉得这个东西是我需要的。另外一个这个东西我确实这么想，但是使用起来不是这样的，我想要另外一种方式，这给工程学方法带来很大的困难。从工程学的角度来讲，不管需求的变化还是构建的变化，它的成本随着时间的推移不断增加的。在开始的需求或者分析阶段，对需求和设计做任何改动是非常容易的一件事情，但是如果进行测试或者投入生产的时候再进行改动，成本是非常高的，所以工程学最核心的概念，很多人都讲变化是最可怕的事情，我们所要做的事情就是避免变化。所以工程学是这样，在这个过程中，忽略所有的客户需求变化，等于说把这个需求确定下来以后，就不管客户需求，我按照这个需求一步一步做。任何客户提出任何要求，我都不管。这个结果，并没有避免问题，而只是推迟了问题的发生。最后交付的时候，所有的需求一下子全部明白了。这也就是瀑布的来源，这种方法拿到你交付的东西，其实是我一年以前或者半年以前想要的都是，不是现在想要的东西，所以满意度大家可知。又要对此重新设计，最后客户得到的还是半年或者一年以前想要的东西。敏捷式采取的一种适应性的态度，换句话说，敏捷式开发，作为开发方法不应该想办法避免变化，而是想办法使变化成为轻而易举的事情，最核心一点就是叠带式开发，针对一小部分需求进行测试部署，每一个循环时间非常短也就是两个星期或者更短时间，通过这种叠带的形式，软件从小到大，由很少一点到不断增长扩大，最后形成整个软件过程。而且增长过程是软件不断修改过程，修改在敏捷式开发里不是可怕的事情，而是必须做的一件事情，作为这样一种方式，客户可以对哪些不能开发的优先考虑，某些功能先开发，有些功能后开发，开发到一定程度，可以对项目方向根据市场变化来做出调整。敏捷式开发可以做到这一点，因为不是分成三个或者四个最主要的阶段来做的，而是叠带的方式来做的。