一个月左右的迭代和输出迭代（最后一次迭代）

今年9月到11月，我参与了一个采用迭代开发模式的研发项目——第四次迭代和输出迭代（最后一次迭代）。 这是第一次体验传统开发模式之外的项目开发方式。

综上所述，这个项目的每次迭代大约需要一个月的时间，每次迭代的流程与传统开发相同：需求->详细设计->编码->测试->输出。 那么，迭代开发模式到底是什么呢？ 它有什么特点和适用场景？

瀑布式开发模型

在介绍迭代开发之前，我们先来说一下传统的开发流程，即所谓的瀑布式软件开发模型。

瀑布式软件开发模型是最初在1970年提出的软件开发模型，是一种古老的计算机软件开发方法。 这种开发模型将整个软件开发过程分为需求分析、设计、开发和测试四个阶段。 每个发展阶段都需要最好的。 尤其是在前期，设计越完美，提交后的成本损失就越少。

瀑布模型的主要问题是：严格的分级导致自由度降低，项目早期做出的承诺使得适应后期需求的变化变得困难且成本高昂。 当需求未知并且在项目过程中可能发生变化时，瀑布方法基本上是不可行的。

迭代模式概念

迭代开发模型，也称为迭代增量开发或迭代进化开发，是一种与传统瀑布式开发相反的软件开发过程。 它弥补了传统开发方式的一些弱点，成功率较高。 和生产力。

在迭代开发模型中，整个开发工作被组织成一系列短的、固定长度（如4周）的小项目，称为一系列迭代。 每次迭代都包括需求分析、设计、实现和测试。 采用这种方式，可以在需求完全确定之前就开始开发工作，一次迭代即可完成系统部分功能或业务逻辑的开发。 然后通过客户反馈细化需求，开始新一轮的迭代。

从上图可以看出，每次迭代都会产生一个可以发布的产品，它是最终产品的子集。

迭代模式的优点

降低风险； 尽早获得用户反馈； 继续测试和集成； 使用变更； 提高可重用性。

迭代模式适用的情况

我个人认为迭代开发模式适合需求信息不明确的项目和产品开发。 在产品开发的实际过程中，客户本身对产品的需求并不是很清楚。 在这种情况下，采用迭代开发的方式，让客户在短时间内满足第一个迭代版本，从而在迭代过程中逐渐明确需求。 和清晰度。

迭代模型和敏捷开发的区别

虽然我参与过迭代项目开发，但我并没有真正参与过敏捷开发。 所以这里我只谈一下我个人的理解。

迭代模式实践经验

参与迭代模型项目的开发后，给我最大的感受就是非常“冗长”。 每次迭代都要写需求文档、设计文档、测试报告等文档。

第二个感觉就是增量开发。 由于每次迭代的工作都是在开始迭代之前就规划好的，因此每次迭代都是在上一次迭代的基础上完成相应的功能或者优化某些功能的实现。 当然，在迭代过程中，可能会增加新的需求，或者修改上一次迭代的需求的实现。 增量开发也反映在文档中。 每次迭代的文档也会在上一次迭代的基础上进行添加和修改。

迭代模型确实比传统的开发模型（瀑布模型）更先进，特别是对于需求不是很明确的项目和产品。 个人认为也适合有明确需求的项目和产品。 公司很多产品功能复杂、开发周期长，但又想快速占领市场。 如果采用传统的开发模式，等到产品的所有功能都开发出来之后再销售，黄花菜很可能就凉了。 这让我想起了去年我在南京开发新平台产品时的理念。

当时产品的很多功能还没有开发出来，甚至还没有进行像样的完整测试，但领导表示10月份就会发货。 当时我个人认为，一个产品的研发、生产、进入市场应该按照以下流程：需求->详细设计->编码->测试->输出->小批量试产->批量生产，所以对于领导者来说这种行为（产品开发方式）实在是不太理解。

经过一年的观察，虽然问题很多（特别是导入生产过程中），但逐渐发现领导者的做法确实适合公司的产品开发，这种以市场为导向的产品开发方式得到了认可。 缺点是项目管理过程中没有明确说明阶段性结果。 如果项目采用迭代开发模式进行软件开发，我想每个参与该项目的开发人员都不会有这么多的抱怨。