随着业务的发展，以及用户对软件系统的理解加深，新的需求会不断涌现；在日复一日使用过程中，一些在验收测试中没有发现的缺陷也会浮现出来；随着业务数据量的增加，系统对性能的要求也会比最初构建是提高。这些都提出了维护 的要求。

传统维护方法的困境

按照传统开发方法，维护阶段最多只是对系统做一些小修小补，而且维护团队的技术能力通常远低于最初的开发团队，所以如果涉及到较大范围的调整和新 增功能，在维护阶段一般都无法进行，只有放入下一期项目来做。即使客户本身有IT部门或者IT团队，由于缺乏对系统的充分了解，他们也很难在维护阶段提供 大的帮助。很多开发团队尝试通过提供更多的文档来把知识传递给客户的IT人员，但事实证明：

1. 单纯通过文档很难真正理解一个系统
2. 文档的维护工作量很大，而缺乏维护、与真实系统不同步的文档会给阅读者造成更大的困扰

敏捷维护解决方案

敏捷方法采用迭代式开发，将整个软件开发过程分解成一个个小的迭代。在每一个迭代中都要经历需求收集、迭代计划、开发、集成和发布等活动，让客户尽快看（一般一个迭代1～2周）到可用的软件。
第一次发布交付的是一个包含功能中最小可用集合的系统，然后再周期性的增量发布，来不断交付新的功能。特别是在大型的项目中，这种交付的好处非常突出，对软件价值和团队信心都有非常重要的好处。也使得敏捷项目，基本没有延期交付的压力。在全部的开发过程中，根据客户对需求优先级的排序，首先实现重要需求。同时每一个迭代，客户还是可以调整需求开发的先后顺序， 包括增加或者修改需求或删减需求。
在每一次发布过程中，最初构架也会根据需求而进行设计。由于敏捷方法最初设计的构架都着眼于将来的增量发布，因此都有很好的扩展性。当传统软件开发方法到无法再增加功能而不得不摒弃现有构架的时候，敏捷方法还可以在此基础上不断的扩展。

在迭代开发中，客户如果在完成几个迭代后，发现原有的需求不再需要，就可以将这部分时间用于新的需求开发和需求修改。能将无用功降到最低。同时和客户风险共担，在开发全过程中，能很好的接受客户的需求增加和变更。所以使得很多系统，在一期的时间段和费用预算内，就完成了传统开发中，二期、三期的工作内容。 节省开发投入是显而易见的，更重要的是帮助业务部门把握了市场的先机，创造更多的价值。