迭代开发优点

１.它允许需求的变化。

需求的变化和“进一步的蔓延” — 技术和客户驱动的特性的累加 — 一直是项目中导致麻烦、延期交付、令客户不满意和使开发人员泄气的主要原因。为了解决这些问题，使用迭代开发方法的团队应该在项目开发的几周里就关注生成和演示可执行的软件，这样就强制了需求的检查并可以帮助减少需求从而反映系统的本质。

２.集成不是在项目的尾声进行的"大动作"。

将系统的集成留到项目的结尾几乎总是会导致耗时的返工 — 有时这种返工会花费整个项目工作量的百分之四十的时间。为了避免这种返工，每一次迭代都以集成构建系统各部分结束；这样不断的积累将最小化日后的返工。

３.早期的迭代可以暴露风险。

迭代的开发方法可以帮助团队在早期的迭代中减少风险，因为在这些迭代中包括了对所有过程组件的测试。当早期的迭代覆盖了项目的很多方面时 — 工具、购买的软件和团队成员的技能等等 — 团队能够很快的发现被预感的风险是否是真实的，并且能够在问题相对容易并花费很少成本解决时揭示没有被发现的新的风险。

４.对产品的管理能够采取战术性的变化。

迭代开发能够快速的生成可执行的架构（虽然功能有限），这个架构能够为了应对竞争对手的快速版本发布容易的调整产品使之成为”轻量级的“或者“改进的”版本。

５．它使重用更加容易。

识别在迭代中进行的部分设计和实现的公用部分要比在计划期间找出公用部分更加容易。在早期开发中的设计评审允许架构师们发现潜在的可重用的机会，并且利用这个机会为接下来的迭代开发成熟的公用代码。

６．你能够在每一个迭代中发现并更正缺陷。

这会生成健壮的架构和高质量的应用。你甚至能够在早期的迭代中而不是在项目末期的大规模测试阶段发现缺陷。你能够在性能瓶颈没有破坏你的计划之前发现它。

７．它能够更好的利用项目的人员资源。

很多开发组织使用一种管道式的组织方式来匹配他们的瀑布型开发方法：分析人员将被完成的需求发送给设计人员，设计人员将被完成的设计发送给开发编程人员，编程人员再将他们开发的组件发送给集成人员，集成人员将组件集成起来发送给测试人员测试。这种多次的传递不仅容易产生错误而且应用造成误解；这种方式也会使人们感觉他们对最终的产品有很少的责任。迭代开发过程鼓励在项目的各个环节中团队成员参与范围更加宽广的活动，允许团队成员扮演多种角色。项目经理能够更好的利用可得到的项目人员并其可以消除有风险的传递。

８．团队成员能够沿着项目的道路进行学习。

工作在迭代开发的项目中的开发人员在软件开发周期内有很多的机会从他们所范的错误中吸取教训，并能够从一个迭代到另一个迭代的过程中增进他们的技能。通过评估每一个迭代，项目经理能够为团队成员发现培训的机会。相反，工作在瀑布型开发方法中的开发人员典型的被限制在狭窄的技术专长上，并且仅仅有机会从事设计、编码或者测试之一方面的工作。

９．你能够沿着项目的道路改进开发的过程。迭代末尾的评估不仅能够从产品或者计划方面揭示项目的状态；他们也可以帮助项目经理分析在下一个迭代中如何改进项目的组织结构和过程。