软件开发模式2：迭代开发模式介绍

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

总结来看，该项目每个迭代时间约一个月左右，每个迭代过程跟传统开发是一样的：需求—>详细设计—>编码—>测试—>输出。那么，到底什么是迭代开发模式呢？它又有什么样的特点和适用场景呢？

瀑布开发模式

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

瀑布软件开发模式，由W.W.Royce在1970年最初提出的软件开发模型，它是一种老旧的计算机软件开发方法。这种开发模式将整个软件开发过程分为四个阶段：需求分析、设计、开发、测试。每一个开发阶段都要求做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

瀑布模式主要的问题是：它的严格分级导致自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

迭代模式概念

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

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

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

迭代模式优点

1. 降低风险；
2. 得到早期用户反馈；
3. 持续的测试和集成；
4. 使用变更；
5. 提高复用性。

迭代模式适用场合

个人认为，迭代开发模式适合于一些需求信息不明确的项目和产品开发中。在实际开发产品过程中，客户本身对产品需求都不是很明确，在这种情况下，采用迭代开发，让客户可以短时间与第一个迭代版本见面，从而在迭代过程中，让需要逐步明确和清晰。

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

虽然参与过迭代式项目开发，但没有实际参与过敏捷开发。所以这里只谈谈个人的理解。

• 敏捷开发也有迭代过程，但是与迭代开发模式相比，敏捷开发的迭代周期更短，往往是1—2两周，而迭代模式中，迭代周期较长，一般为1个月，也就是4周，甚至更长；
• 敏捷开发强调“敏捷”，它强调团队的交流与沟通，而文档并不是最重要的；迭代模式中每个迭代都需要有详细的文档；

迭代模式实践感受

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

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

迭代模式确实比传统开发模式（瀑布模式）先进，尤其对需求不是很明确的项目和产品。对于需求很明确的项目和产品，个人认为也很适用。公司的很多产品，功能复杂，开发周期长，但又想迅速占领市场。如果使用传统开发模式，等产品所有功能开发完成后再拿出去卖，估计黄花菜都凉了。这不经让我想起了去年在南京开发新平台产品时所持有的观念。

那时，产品很多功能尚未开发完成，甚至连一个像样完整的测试都没有实施，而领导却说10月份要出货。当时，个人认为，对于一个产品，应当按照：需求—>详细设计—>编码—>测试—>输出—>小批量试产—>大批量生产这样的流程进行开发生产并进入市场，所以对领导这种行为（产品开发方式）确实不是很理解。

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