Fred Brooks 在 25 年前就曾写到：“不要指望一次成功，无论如何你都要这样。”
敏捷开发，小步快跑，持续迭代，不断改进，产品升级。
在用例需要之前，不要添加数据成员
在代码之前编写测试
过早的优化时万恶之源
不要过度强调代码的通用性
为了降低风险，应采用迭代方式递进开发。每次迭代完成都会发布一个可执行文件。
主题
为什么要以迭代方式开发
迭代式方法的优点
适应变更
降低风险
学习
提高复用性
提高质量
为什么要以迭代方式开发
初始设计就其关键需求而言很有可能是有缺陷的。到后期才发现设计缺陷会导致非常严重的费用超支，在某些情况下甚至会导致项目被取消。
任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。
在瀑布式生命周期中，只有到生命周期的后期才能确知周围是否存在风险。
在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。
迭代式方法的优点
迭代式方法一般要优于线性或瀑布式方法，其中的原因多种多样。
允许变更需求。需求总是会变化，这是事实。给项目带来麻烦的常常主要是需求变化和需求“蠕变”，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。正如 Fred Brooks 25 年前所写的：“不要指望一次成功，无论如何你都要这样”。
逐步集成元素- 集成并不只是简单的“一锤定音”。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。
及早降低风险，因为风险一般只有在集成阶段才能发现或得到处理。展开初期迭代时，您会检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。
有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。如果是非迭代式开发，这些人在初期只能制定计划或培训技能，空等着开始他们的工作。培训需求或对进一步帮助的需求（有可能来自外部）也可在评估复审中尽早提出。
提高复用性，因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
生成性能更强壮的产品，因为在多次迭代中您总是不断地纠正错误。在产品脱离先启阶段后的初期迭代中仍然可以发现缺陷。性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。
容许产品进行战术改变；例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。
迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
有一个客户曾经说过：“使用瀑布式方法，一切看起来都很顺利，直到项目快结束时，有时甚至集成已过半才发现问题。此时所有的东西都变得支离破碎。而使用迭代式方法，问题的本来面目不可能隐藏得很久。”
项目经理常常抵制这种迭代式方法，视其为无穷无尽的“大肆删减”。在 Rational Unified Process 中, 这种交互式方法是很规范的；迭代在数量、持续时间和目标上都是按计划进行。参与者的任务和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代确实会存在返工现象，但返工也是严格按规定进行的。
适应变更
迭代便于您将变更需求考虑进来。需求总是会随着过程而变更。
需求变更一直是给项目制造难题的主要根源，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。Fred Brooks 在 25 年前就曾写到：“不要指望一次成功，无论如何你都要这样。”用户会随着项目进行改变他们的想法。人的本性就是如此。强迫用户去接受他们最初所设想的那种系统，这是完全错误的。他们改变想法是因为环境在发生变化，在此转变过程中，他们对环境和技术有了更多的了解，并且他们还看到了开发各环节之中所生成的中间产品。
迭代为管理层提供了一种用于对产品进行战术变更的方法，例如，同已有的产品进行竞争。
例如：可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。
在过程中允许技术变更。
如果某种技术变化了或成为标准，或是出现了新技术，那么项目可以加以利用。这种情况在平台变更或者底层基础设施变更时最为显而易见。
降低风险
多数风险在过去只能到集成阶段才被处理或发现，相对而言，迭代使您可以及早降低风险。
展开初期迭代时，您会检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。
集成并不只是简单的“一锤定音” - 元素是被逐步集成的。
事实上，在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，，现在分散到六至九个（很难精确计划的）集成部分中，每一部分要集成的元素都比过去少得多。
提高复用性
因为相对于必须预先确定复用性而言，分部分设计和实施时更容易确定公用部分，所以可以提高复用性。
确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
要充分利用市售 (COTS) 产品这个便利条件。
通过数次迭代来选择和集成它们，并核实它们是否适合这个构架。
学习
开发人员有机会在整个生命周期中边做边学，各显其能。
测试员可早些开始测试，技术文档可早些开始编写，其他人也是如此，而不是空等很长时间，只能制定计划和训练技能。在早期迭代的评估复审中，可以发现是否需要进一步培训或外援。
迭代流程自身也可在进行过程中得到改进和精炼。
一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
提高质量
因为错误经过数次迭代已得到纠正，所以这样生成的构架将更强壮。
在早期迭代中，随着产品逐步成熟，可以及早地发现缺陷。可以及时发现并减少性能上的瓶颈，而不是在交付前夕才发现它们。
这样生成的是一个经过全面测试的产品。
关键功能因而有机会在数次迭代中经历多次测试。测试本身和所有测试软件将有时间来完善，而不只是依赖于项目几近尾声时的一次性测试。