“软件行业是成功的，但也存在很多问题，”软件教父Martin Fowler在近期一次软件开发研讨会上表示，“而且问题往往在出现时才为人们所重视。”
问题缠绕软件开发
软件开发过程中问题多多，这不是个新发现。早在上世纪60年代，北约（NATO）就提出了软件危机这一概念。在《人月神话》一书中，软件开发则被喻为让众多史前巨兽痛苦挣扎，却无力摆脱的焦油坑。随着需求和应用的日趋深入与复杂化，软件开发的难度和遇到的问题以几何级数形式增长，焦油坑也由此变得更深、更大。
复杂程度高，开发周期长，结果无保证，这是软件开发的通病。针对问题，人们创造了N种方法，并由此产生了软件工程学。而在实际工作过程中，软件开发的多变性和不可控制性，仍可轻易摧垮项目开始时项目组苦心经营的开发体系和方法，无论是业界公认的需求、变更、人员流动，还是各种看起来并不起眼的小事件。
以人为本的敏捷开发
“既然无法阻止变化发生，我们就要找出适应变化的方法。”Fowler并非空手而来，随他登场的还有敏捷开发。
什么是敏捷开发？一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。
改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”
也许是因为时间关系，Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验，拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。
问题与思考
然而，我们不得不面对的现实却是，模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。
大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目，合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增容”的情况下，遇到的问题同样成倍增长。人的重要性被提到了更高的高度，而缺乏有效协调手段，减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时，也相应引发了几乎同样多的问题。
| 
