最佳方案-迭代式.docx

最佳方案：迭代式开发2008年08月11日 星期一 10:16原文地址：:9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm:9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm#Why%20Develop%20Iteratively最佳方案：迭代式开发为了降低风险，应采用迭代方式递进开发。每次迭代完成都会发布一个可执行文件。主题:9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm为什么要以迭代方式开发 :9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm迭代式方法的优点 :9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm适应变更 :9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm降低风险 :9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm学习 :9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm提高复用性 :9081/doc/RationalUnifiedProcess.zh_cn/manuals/intro/im_bp1.htm提高质量 为什么要以迭代方式开发 初始设计就其关键需求而言很有可能是有缺陷的。到后期才发现设计缺陷会导致非常严重的费用超支，在某些情况下甚至会导致项目被取消。任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。在瀑布式生命周期中，只有到生命周期的后期才能确知周围是否存在风险。在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。迭代式方法的优点 迭代式方法一般要优于线性或瀑布式方法，其中的原因多种多样。允许变更需求。需求总是会变化，这是事实。给项目带来麻烦的常常主要是需求变化和需求“蠕变”，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。正如 Fred Brooks 25 年前所写的：“不要指望一次成功，无论如何你都要这样”。 逐步集成元素 - 集成并不只是简单的“一锤定音”。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。 及早降低风险，因为风险一般只有在集成阶段才能发现或得到处理。展开初期迭代时，您会检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。 有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。如果是非迭代式开发，这些人在初期只能制定计划或培训技能，空等着开始他们的工作。培训需求或对进一步帮助的需求（有可能来自外部）也可在评估复审中尽早提出。 提高复用性，因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。 生成性能更强壮的产品，因为在多次迭代中您总是不断地纠正错误。在产品脱离先启阶段后的初期迭代中仍然可以发现缺陷。性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。 容许产品进行战术改变；例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。 迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。 有一个客户曾经说过：“使用瀑布式方法，一切看起来都很顺利，直到项目快结束时，有时甚至集成已过半才发现问题。此时所有的东西都变得支离破碎。而使用迭代式方法，问题的本来面目不可能隐藏得很久。”