如果有一种方法能使你的软件缺陷率降低63%，核心缺陷率降低79%，整体投入减少62%，整个项目开发的时间缩短69%，你会采用这种新的软件开发方法吗?

　　在回答这个问题之前，你可能会问：是什么方法能达到这样的效果?答案是：敏捷开发。你一定会开始质疑：这是真的吗?或者你会说：我们也在用敏捷，但没有以上提到的这么夸张。

　　以上提到的一些数据来自Forrester，一家善于用数字说话的咨询公司。他们对多个采用敏捷开发的项目与传统开发方式进行对比，得出以上数据。而这些项目来自敏捷刚刚开始起步的2002年。

　　不相信敏捷开发能够大幅提高软件生产效率的可能并没接触过敏捷方法;而怀疑以上数据的人可能已经在使用敏捷，但并没有获得让人惊喜的提升。《敏捷宣言》虽然已经走过十年，但在国内，因为技术理念和文化的差异，敏捷开发要发挥出全部威力还有很长的一段路要走。

　　我们在51CTO开发频道用户群做过一个小范围的调查，结果显示，有近三成的开发者表示自己和所属团队正在使用敏捷开发，有七成的网友表示并没有深入了解过敏捷开发。值得注意的是，在使用敏捷开发的团队中有不少人感觉自己在“伪敏捷”：标榜使用敏捷开发的方式进行软件开发，但团队内部依然遵循着传统的开发方式进行项目开发。

　　“伪敏捷”——起步就走歪了

　　任何新事物的深入与发展都需要一个过程，这个过程产生中，推行此项事物的出发点可能是影响新事物发展的重要因素。当51CTO记者将上述调查转述给ThoughtWorks CEO郭晓先生时他认为：实际上伪敏捷首先有一个目的，为什么要伪敏捷，谁需要让他做敏捷。

　　目前，国内中小型软件企业在实施敏捷开发过程中，往往是迫于压力。两种常见的情况是迫于客户的压力和迫于上级领导的压力。

　　比如一些软件企业可能被客户要求使用敏捷开发，更紧密的联系需求，更快的迭代交付。这时候只好打敏捷开发的牌子，实际上开发过程中却很少能正确的理解敏捷开发的思想，仅仅是简单的照搬一些工具来进行项目。

　　第二种可能是软件企业的高层看到了敏捷的好处，也能理解敏捷开发所能带来的价值，希望下面的开发团队也能使用这种方法进行开发。但落实到具体的开发团队中，却因为各种原因没有很好的执行下去，最终成了只是为了完成领导的任务而敏捷。

　　事实上，“伪敏捷”的产生最根本的原因是国内开发者还没有彻底的理解敏捷，认识敏捷。敏捷开发是一种方法，更是一种思想;在实践敏捷开发中，不但要求团队自上而下的“形似”，还要求我们可以充分认识敏捷思想，做到“神似”。

　　要想做到“神似”，我们还有很长的路要走。任何东西都离不开实践，要想很好的理解敏捷开发，也要从实践开始。那么如何从一开始就不走歪路，如何正确的推行敏捷开发?

　　尝试敏捷——从持续集成开始

　　ThoughtWorks CEO郭晓先生建议是可以从持续集成开始实践敏捷。持续集成是敏捷开发中最常用、最普通的做法。它的价值在于在实施过程中可以会暴露出大量的问题，比如项目的架构问题、耦合度问题和团队沟通的问题等。

　　持续集成理念很简单，一个软件不要等最后一天再上线，而是争取团队内部的项目启动第一天就完成上线和集成;这时候会有很多问题暴露出来，等待团队解决。当发现问题，我们就可以去寻找其他适合的敏捷方法进行解决，这样可以更有效的更快的获得敏捷开发的价值。

　　当然，持续集成不是解决问题的灵丹妙药，但却是暴露项目和团队中问题的最佳手段，不同团队在面对和实践敏捷这么大的一个知识体系的时候有不同的方法获取价值。不断的获取价值，会使团队各个成员有更多的动力持续下去。

　　需要时间和实践

　　作为一种开发方法，敏捷开发虽然已有十年的积累，但在国内仍然有很长的一段路要走。很多观念需要接受，很多思想需要体会，很多方法需要实践。

　　记得与敏捷开发专家麦天志先生谈及敏捷开发的发展时他曾提到，一种开发方式的普及是一个积聚的过程，一个好的开发方式是经过不断的实践和验证，并行之有效的。他认为，并不会有一个明显的分界线标志出敏捷开发到了那种普及的程度和境界，至少在目前，敏捷还在不断发展，更多的项目在实践敏捷，观念的普及和成功的案例正在不断扩大。敏捷开发，在路上。