最近几年，科学技术急速发展。软件的复杂性和CPU处理速度也呈指数增长，而不是线性上升。这种增长率的变化导致的连锁反应，增加了市场的波动，这反过来又要求企业能够快速适应消费者的需求。行动缓慢的庞然大物被普遍认为是缺乏竞争力的，在交付新特性方面也存在更大的风险，这已经是“老生常谈”或是过时的问题了。
这也为敏捷开发方法的兴起做出了贡献，例如极限编程（XP），SCRUM，功能驱动开发等。这些方法都力求降低变更成本，并把风险最小化。这些都是通过实践中的应用来实现的，比如：
- 快速的迭代计划和开发周期，适度权衡并促进最有价值的功能尽快交付。
- 持续性的系统测试，通过在开发过程的早期阶段发现并修复产品缺陷，来保障软件的高质量及稳定性。
- 为参与项目的各个团体引入开放式的沟通渠道，从而保证最终目标一致性。
SCRUM 迭代图
**
**
当然这不同于传统的管理理论，传统方法通常：
- 变更必须通过严格的审批流程进行监管
- 分级的企业组织结构，是建立规则的最佳方式
- 加强管控力度可以提高质量
- 企业组织结构严谨、稳定
- 员工只是企业组织这个“机器”上的一个“齿轮”
- 将问题细分为一个个任务，然后分配资源加以解决
- 项目和风险通过复杂的前期规划（也常被称为大需求），基本是可预见的、可管理的
瀑布过程图
此外，对于那些拥有成熟开发流程的企业组织，往往都是经过较长一段时间的实际经验积累（成功的或失败的）建立起来的。
与传统的管理方法相比，也难怪高管们在实施敏捷方法时会遇到管理不够正式，混乱，无计划性等问题 。某些时候，他们甚至会鼓励工程师们不顾日程安排，按照他们的想法开发来脱离管理。
这是因为大多数敏捷实践都没能够彻底解决软件项目的管理层面；即人、流程及技术。相反，他们往往更加注重编码、测试和功能交付等方法上面。
所以，如果我们想要把敏捷的概念应用到软件项目的管理层面，这也是软件开发变革自然要经过的一步，我们就必须回答以下问题：
- 当应用于传统项目管理方法的时候，什么样的敏捷、精益或简约的原则是有意义的？
- 如何把这些原则真正应用到项目管理中？
- 当将应用敏捷方法应用于传统项目管理时，有什么障碍或有哪些常见问题是需要注意的？
