软件开发迭代模型-敏捷迭代开发

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

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

瀑布开发模式

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

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

瀑布模型的主要问题是：严格的分类导致自由度降低软件开发迭代模型，项目前期做出的承诺难以适应后期需求的变化，成本高。 当需求未知并且在项目过程中可能发生变化时，瀑布方法在很大程度上是不可行的。

迭代模式概念

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

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

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

迭代模式的优点

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

迭代模式适用场合

个人认为迭代开发模式适用于一些需求信息不明确的项目和产品开发。 在实际的产品开发过程中，客户本身并不是很清楚产品的需求。 本案例采用迭代开发，让客户在短时间内满足第一个迭代版本，从而在迭代过程中逐步明确需求。 和清晰度。

迭代模式与敏捷开发的区别

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

迭代模式实践心得

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

第二个感觉就是增量开发。 由于每次迭代都是在迭代开始前计划好的软件开发迭代模型，所以每次迭代都会在上一次迭代的基础上完成相应的功能或者优化一些功能实现。 当然，在迭代过程中，可以增加新的需求，或者修改上一次迭代需求的实现。 增量开发还体现在文档上，文档的每一次迭代也是在上一次迭代的基础上增加和修改的。

迭代模型确实比传统的开发模型（瀑布模型）更先进，尤其是对于需求不是很明确的项目和产品。 对于需求明确的项目和产品，我觉得也很适用。 公司很多产品功能复杂，开发周期长，但又想快速占领市场。 如果采用传统的开发模式，等到产品的所有功能都开发完了再卖，估计黄花菜要凉了。 这让我想起了去年在南京开发新平台产品时的理念。

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

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