解析“迭代模型”

迭代模型 与 瀑布模型 的不同不仅仅是形式上的，更重要的是它们对项目的关注点差异和对项目理解的差异。理解这点，我们才能灵活运用迭代模型，而非仅仅是利用其形式。

众所周知，瀑布模型的基线（或里程碑）的划分与评审，是基于工件（文档、模型、源代码等）本身的完成情况来执行的。有些开发组织虽然在进行软件开发时号称是按照迭代模型进行的开发，但其实本质上还是瀑布模型，原因有两点：一是其还是基于开发的工件（文档、模型、源代码等）的完成情况作为评价其基线的衡量指标；二是其对迭代的活动要么是走形式的拼凑，要么完全没有明确的迭代活动，只是写出要做出的中间工件（文档、模型、源代码等）。瀑布模型最大特征之一是对工作结果的完成情况作为评价基线，而不管这个工作结果对整个项目状态的影响。比如“需求文档是否完成”、“设计文档是否完成”、“程序代码是否完成”等来衡量基线。瀑布模型认为完成了具体的工件（文档、模型、源代码等），就达到了一个基线或里程碑，通过工件推论项目的成功。这完全违背了项目本身是以满足客户需求为目的和规避风险为条件的准则。

迭代模型完全不同，迭代模型对项目的理解是：以项目涉众的需求为项目目标，以风险来驱动项目发展，以项目要求达到的状态为基线或里程碑，通过把项目最终满足涉众需求应达到的最终状态划分成各个基线（或里程碑）状态。

在迭代模型中，每次迭代不仅仅是对迭代活动的重复（这种重复决不是形式上的），而且迭代要达到的结果——迭代状态，也是经过精心设计的。这里的迭代的结果当然会有具体的工件，但工件的形式本身不是迭代关注的目标，迭代关注的是这些做出来的工件是否有力的支持或说明该迭代过程达到了该迭代状态？如果无法支持或说明不了这个关系，即便做出的工件再怎么漂亮，对项目意义也不大，甚至还会影响项目的进度和成本。所以，我认为迭代模型的关键是迭代过程对迭代后项目达到的状态的关注，而非对迭代过程所产生工件的形式的关注，工件只是对迭代状态说明的一个“证据”或“依据”。

在迭代模型中，风险驱动是其重要的组成部分。每次迭代过程都需要解决一定的风险，这些风险说明了对达到迭代状态的影响，风险的解决也是迭代状态的达到。例如，某个迭代的状态设定为解决10000个用户在2秒钟内成功并发登录，这里就存在这样的技术风险——高并发访问的性能风险。对这个风险的解决也等于达到了这个迭代状态，在达到了这个迭代状态后，自然就产生了登录用例的需求说明文档、登录的设计文档、登录的实现源代码（可能是框架性的）、登录的性能测试报告等。如果按照瀑布模型来做，那么我们只有等到项目的编码后期才知道是否能解决这个性能风险。严格意义上来说，瀑布模型是非风险驱动的。

在迭代模型中，每个迭代的周期是较短的。一般不建议超过3周，常采用2周为一个迭代，小项目往往会采用1周为一个迭代。只有较短的迭代周期，才具有规避失败风险的成本承受力，才能在较短的时间内快速调整项目进度的方向。过长的迭代周期，往往会使迭代失去规避风险的作用。

在迭代模型中，迭代的过程是增量的过程。每次迭代的结果是一个小的渐进，不断迭代累计了这些渐进形成大的渐进，最终完成整个项目的渐进——增量。这里的增量决不是一般意义上的累加，而是为达到迭代状态的积累。需求分析的增量，设计模型的增量，代码的增量等，都不是单纯的增量，都是按照迭代状态目标的方向进行的增量。

迭代模型不是一个软件过程，它存在于许多的软件过程中，如：RUP、FDD、AP(敏捷过程)等。