自适应模型是PMBOK第5版最新引进的，PMBOK把普遍流行的敏捷开发方法包含到体系中来了。

这种模型是针对原来的计划、设计、实施、测试、交付这样的流水线的工作模式的各种缺陷而提出的。其鼓励变革，反对机械的文档控制，反对教条的软件工程方法。这种方法的提出对于过去那些饱受项目管理部门折磨的技术人员来讲是一个福音，一经问世便得到了广大技术人员的追捧。所以在敏捷开始的时候，更像是一种程序员的宗教，其被追捧的狂热程度可窥一斑。而一些中小软件开发企业，因为被CMMI等重量级的体系实施的成本、周期和其复杂性所吓倒，从而转向这种轻量级的开发模型。最近几年，敏捷方法已经开始大行其道，好多原来的重量级的大型企业也纷纷引入这种方法。

那么这种方法为什么会得到普遍的认可？这其实也是软件企业一直以来面对的一种困惑，那就是，软件到底可不可以当做一个工程来进行管理？软件工程的提法到底是否合适？软件开发和传统行业最大的区别就是它可以把程序员的思想直接变成固化的代码，从而成为产品的一部分。这种把思想直接转化为人类使用的产品是人类以前除了创作艺术作品之外从来没有过的工作。人的思想如此复杂，难以量化和精确控制。所以连如何来衡量程序员的工作量这个在传统工程领域都称不上困难的事情在软件开发领域却都成了几乎无法完成的事情。从上个世纪50～60年代的软件工程危机开始，研究学者们一直试图通过工程的方法，把软件开发变成一个可以按照计划精确控制的行为。以此观点为中心开辟了软件工程这个学科，提出了许多种解决方案，但是都存在着各种各样的问题。我们熟知的软件产品，例如MS-Office、Visual Studio、Oracle数据库等，几乎没有哪个产品是在计划时间内完成的，延期半年完成都是十分常见的事情。而敏捷方法的提出，第一次从非传统工程的领域来看待这个过程。从软件本身的特点来看待这个问题。这在现在软件逐渐向移动终端转移，讲求碎片化、逐步完善的产品，“永远的测试版”的环境下，便迅速成为了主流开发方法。(www.daowen.com)

这种方法最初鼓吹不要规范教条的文档，不要机械严格的设计，不要板起脸吓人的规矩或者合同，要的是灵活性、用户的体验和良好的用户合作关系。但是如何解决软件中需求变化，程序员经验不丰富，质量难以保证的难题呢？这种方法其实一开始只是提供了几个技术上的解决方案。例如，采用软件重构方法来解决代码需要中途改动的问题，采用测试工具（JUnit）来解决质量问题，采用用户故事卡片来解决需求准确表达问题，采用用户关心的特性点来解决用户体验问题等等，其他还有许多类似的方法。这些方法在技术上已经有了现成的实现框架，例如Martin Fowler写的一本书《企业架构设计模式》堪称经典。受其影响，软件架构师成为了一种时髦职业。关于测试，更是有人提出了测试驱动的开发方法。可以说，这些技术的发展，反过来也深刻地影响了敏捷方法的推广。好多设计模式成为了程序员的常用词汇。例如，工厂模式、面向切片开发（AOP）、反转控制（IOC）等。