51CTO向您推荐：Visual Studio 2010应用与开发详解
（图1：瀑布式的软件开发流程，迭代式的软件开发流程和Scrum软件开发流程的示意图）
瀑布式的开发方法风险性较高，而且和敏捷方法比起来，瀑布式的开发方法成本更高，但是效率却更低。如果采用瀑布式的开发方法，在创造任何真正的商业 价值以前，首先需要建立一些文档。换句话说，直到项目结束以前，你都无法创造任何的价值。说什么产品开发是瀑布式的，或者项目预期的时间表在很久以后，这 些都是在混淆视听。推迟创造商业价值的时间点很明显是这种开发方法的一大劣势。
想想80-20法则：80%的产品价值来自于20%的产品功能。从这方面来考虑的话，我们能想到要构建一个只有20%功能的软件产品吗？是的，我们 可以交付一个只有20%功能的“版本1”，以后，我们再交付一个功能略多一些的“版本2”，再以后，我们再交付一个“版本3”。这种方法的好处是开发 20%的功能并不会花费100%的项目时间和预算：我们可以在项目的早期创造更多的价值。
迭代式的瀑布开发方法致力于交付一个sprint的工作，而不是一系列具有商业价值的，可用的小版本。根据我的经验，在这种开发流程中，最常见的问 题是你交付了很多代码，但是一直把它们放到那里，直到最后一分钟才开始测试它们。这样的话，解决一个问题要比预期花费更长的时间，最终，你会错过最后期 限，并且你可能什么也交付不出来。这种开发方法的另外一个常见的弊病是“过度承诺”。如果使用这种分阶段的方式，当一个阶段即将结束的时候，要估算和一个 具体的用户故事/功能相关的总体效果是很困难的。你可能被迫要对每个阶段做出估算（例如：在抛开测试的情况下，单独估算开发的时间）——这没有什么意义， 因为每个阶段都不是独立的，它们是一个有机的整体。例如，如果你通过测试发现了一个问题，你必须要回到开发阶段来处理这个问题。整个团队必须要把注意力集 中在需要交付最终的目标上，而不是把注意力集中在一些独立的阶段上。值得注意的是，在这种环境下，velocity和燃烧图并没有太大的用处——你无法从 早期的警告中获得好处，因为在这个sprint结束以前，你无法知晓自己是否走在正轨上。
Scrum开发方法致力于交付经过全面测试的，独立的，具有一定价值的，但是功能较少的版本。这样的话，我的风险就被分散了——如果一个功能出现了 问题，那么它不会影响到其他的功能。话虽这样说，我们仍然需要规划我们的迭代工作，在每次迭代结束的时候，我们都要发布一个新版本。
让我们看一个具体的例子，如果我们让同一个团队开发两个项目，这两项目的需求相同，项目周期也相同（比如说：都是一年），但是其中一个项目使用瀑布式的开发流程来开发，而另一个项目使用Scrum流程来开发。
假设，你对Scrum和瀑布式的开发流程都很熟悉，如果你观察一下这两个项目在6个月以后的交付情况，那会是一件相当有趣的事情。在6个月以后，使 用瀑布式的开发流程的那个项目也许已经到达了这样一个阶段：需求分析已经全部完成了，设计也完成了，编程已经开始了，并且已经完成一半了。如果我是一个客 户，这个阶段能给我带来多少商业价值呢？这还用考虑吗？
于此同时，Scrum的项目团队给需要完成的任务划分了优先级，在每个sprint（通常每两个月进行4个Scrum周期）以后，都会交付一个可用 的产品。Scrum致力于在小的迭代周期内交付可用的产品，这样不仅可以在项目生命周期中的任意时刻提供最好的商业价值，而且在开发过程中还允许做出变 更，这些变更可以在将来的sprint中处理。