增量型和迭代型都是典型的“摸着石头过河”，相当于我们日常所说的“先练练手”。

但是这两种类型也有区别。区别就在于提交的交付物不同。可以提交一个版本的，叫迭代型，另外一个就叫增量型。迭代型要求每迭代一次要提交一个版本，通过这次迭代，可以经历项目的几乎所有过程——从需求一直到交付。虽然有的时候可能不是真的交付给用户。

增量型则是要求先做一部分，根据这部分积累的经验再做下一部分。不同部分之间可能在时间上有重叠，所以有的人又形象地称之为“叠生鱼片型”或者“喷泉型”等。

迭代型曾经流行过一段时间，这主要是雅各布森等软件工程领域赫赫有名的三位大师搞的统一开发过程（RUP）的贡献。作者一直认为RUP的产生是对软件工程领域最大的毒害。这种模型首先对软件研发过程用了类似于当年泰勒工厂流水线的那套思维进行了建模。用层次化的方法对软件过程机械地进行切分，之后再把过程分成活动。而活动或者过程再分解成步骤，角色，过程中使用的方法、工具以及输出的文档。这一整套东西提出来之后发布了一套看上去十分完备的文档系统，因为其几乎汇集了所有软件项目过程的方法流程和技术，如下图。

这套方法的最大问题就是在其产生之后，大师们更多地从理论的完备性来阐述这套方法，陷入了理论的自我完善当中而脱离了实际情况。其对所有流程使用了相同的处理方法，虽然其一再强调可以裁剪，但是由于受其建模本身要求完备性的影响，使用起来十分不方便，会让整个项目组套上沉重的枷锁而失去了应用的灵活性。

这种方法可以说影响了2000—2010年近十年的软件工程领域。由于三位大师的名头，加上十分详尽的文档资料，使得很多年间的软件工程类的文章以及培训课程大量复制了里面的资料。同时也就意味着复制了里面的思想，给自己的项目带来了重负。当年一家很有名的软件公司，斥巨资号称要打造中国软件行业最大的航母，要做中国最大的软件工厂，让软件研发从此变成蓝领的工作。该公司照办了这套方法，结果管理人员十分庞大，软件项目搞得一塌糊涂，技术人员疲于应对各种文档的撰写。

事实上，这套方法本身也有其商业目的，那就是Rational公司想通过推广这种方法，来推销它的工具，包括建模、版本控制以及各种辅助开发工具。这家公司后来被IBM收购了，至今仍活跃在软件工程领域，但是已经式微了。主要的创始人雅各布森离开了Rational公司，又在继续着建模之路，提出了SEMAT模型，我们对其效果拭目以待。总体来看，真正使用RUP方法的公司并不多，甚至连收购了这家公司的IBM公司的开发小组也不使用其中的方法。而号称使用了RUP的微软公司实际上也是一直在使用自己公司的一套软件工程方法而已。(www.daowen.com)

好的一面是，迭代型生命周期模型的概念开始深入人心，让项目管理者们有了新的思路应对各种项目困境。另外，建模及其优化已经成为了软件工程领域一个主要的方向。

其实迭代型本身也十分符合心理学的要求，尤其是对于需要长时间才能完成的项目。迭代不仅是从技术和业务上不断地促进项目组变得成熟，降低变更风险，同时也是参与项目人员的一个心理需求。

人为了和系统一致，必须要不断地从系统中也就是周围环境中获得反馈才能保持正常的认知能力和健康心理。而迭代型中，每次提交的版本就是给参与人员的反馈。如果人在项目中长期得不到反馈，看不到一个成果，那项目组人员的注意力就会分散，工作动力就会严重下降。

前面讲过了“感觉剥夺”实验，这个实验证明了人在社会生活中多么需要一个反馈来知道自己工作的效果。关于认知失调，会在后面的章节中更加详细地论述。

知道了这个特点之后，就知道迭代型正好符合了人类本身的心理需求，那就是需要不断地得到反馈。所以，有的时候为了增加团队的动力，我们可能会故意降低版本的要求以便可以及时发布版本，鼓舞士气。为此，有时我们就需要设计多个小版本进行发布，而不是大版本。

如今在“云计算”的影响下，软件产品大多都具有自动检查版本更新的功能。一个不断有新的版本更新的软件产品和一个半年都没有什么新版本的软件产品哪个更有活力，更值得信任呢？不用说，是前者。所以，如果仔细观察你就会发现，许多软件产品的更新实际上没有什么改动，只是变换了一下界面，刺激一下你的注意力而已。