世界五大软件开发教父之一的Matin Fowler认为，当前只有敏捷的软件开发模式才能够使IT跟上业务变化的脚步，只有敏捷的开发模式才能使软件实现快速交付的同时又能成为一个高质量、低成本的软件。

　　敏捷开发作为一个新的软件开发模式的新名词，其中蕴涵着无限的商机，同时，也是对中国软件企业的一次严峻的考验。对于起步远远滞后于西方的中国软件业而言，各种提高软件开发速度及降低软件开发成本的方式和措施都是值得探讨与借鉴的。笔者认为敏捷开发模式对于中国的软件企业正是一个行之有效的开发方式。

　　问题缠绕软件开发

　　软件开发过程中问题多多，这不是新发现。早在上世纪60年代，北约(NATO)就提出了软件危机这一概念。在《人月神话》一书中，软件开发则被喻为让众多史前巨兽痛苦挣扎，却无力摆脱的焦油坑。随着需求和应用的日趋深入与复杂化，软件开发的难度和遇到的问题以几何级数形式增长，焦油坑也由此变得更深、更大。

　　复杂程度高、开发周期长、结果无保证，这是软件开发的通病。针对这些问题，人们创造了N种方法，并由此产生了软件工程学。而在实际工作过程中，软件开发的多变性和不可控制性，仍可轻易摧垮项目开始时项目组苦心经营的开发体系和方法，无论是业界公认的需求、变更、人员流动，还是各种看起来并不起眼的小事件。

　　以人为本的敏捷开发

　　敏捷开发(Agile Software Development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，就如同项目管理中将工作任务及工作目标层层分解一样，把软件项目的构建切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

　　通过上面的定义可以看出，敏捷开发其实借鉴了大量软件工程中的方法。是传统软件开发意义上的改善，而非创新。例如在传统的软件开发中，把设计和构建这两个过程分开进行，设计完成之后，再按照设计构建。

　　实际上，由于需求在不断变化，因此在软件开发的过程中，很难把设计和编程完全区分开来。而在敏捷开发中，先搭建一个比较粗的主构建框架，只对用户目前感兴趣的部分详细开发，并很快交付使用，在使用过程中，按用户的需求进行叠盖修正，周而复始，循序渐进的开发软件产品直到完成。

　　正如ThoughtWorks的首席科学家Matin Flower所说：“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，这种非常短的循环，使终端客户可以及时、快速地看到花钱构建的软件是一个什么样的结果。”因此敏捷开发也可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。

　　敏捷开发的特点

　　敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征:

　　敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

　　这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。

　　与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。

　　敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

　　Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。

　　__在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。

　　然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。__　　敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

　　敏捷开发的问题和思考

　　虽然敏捷开发是个行之有效的软件开发模式，但是任何模式和方法的建立都是基于理论的基础，往往和现实的情况存在差异，这样就会对软件企业操作及执行带来很大的困难，甚至是误导。所以，仅仅提出敏捷开发的模式是不够的，对敏捷开发的议题的讨论并没有终结。下面仅就笔者理解基础上提出一些问题的参考。

　　项目内部协调的困难加大

　　敏捷开发要求将大项目分解成为很多小项目，这样虽然易于考察、易于管理和易于控制，但是这样也带来了项目内部各个小项目协调问题。对于各个小项目的执行，人员分配及其他资源分配的冲突及进度的冲突是最主要的冲突，而且这些冲突如果解决不彻底，将会对整个大项目带来难以预测的负面结果。 　　对管理水平的要求提高

　　敏捷开发的问题最后就是管理的问题。这和很多软件企业重技术轻管理的做法是截然相反的，企业的这种心智模式一方面是源自管理人才的缺乏和项目组成员对管理制度的排斥;另一方面则是因为现行规范和管理制度与实际工作中的不合拍。从这一层面而言，敏捷开发对管理水平要求提高对软件企业领导者的观念是一种挑战。

　　对执行力的要求

　　任何理论只有落到实处，才能为企业为社会创造财富。这是永恒不变的道理。敏捷开发模式需要经验丰富、配合良好而又异常稳定的项目组、积极而富有成效的沟通、良好的管理手段和流程、有效的工具与平台，只有满足这些条件我们才能实现敏捷开发模式带给我们的益处。

　　敏捷开发的出现，同样让以人为本还是以过程为本的争论上升到了理论层面。在敏捷开发过程中，人是第一位的，过程是第二位的，所以就个人而言，应该可以从各种不同的过程中找到真正适合自己的过程。这与软件工程理论提倡的先过程后人正好相反，因而被不少人戏称为对工程学原理的叛逆。

　　敏捷方法对需求不确定或常常变更的情形是有效的。但是，没有哪一种开发方法是适用于所有项目开发的，正如上文所说，敏捷方法给传统软件开发带来了一种新的思路和开发模式，但也给企业带来了软件研发项目管理开发过程的整合困难。

　　所以，在实际开发过程中，需要根据实际项目的需要选择合适的开发方法，并尽最大可能发挥人的创造性和潜能，利用不同人的不同特点，充分沟通，这才是在敏捷方法中真正需要学习的。