（一）什么是增量型项目生命周期

接下来我们继续看看什么是增量型项目生命周期。增量型项目生命周期（以下简称“增量型”）最早被提及，是在1971年，任职于IBM的Harlan Mills提出了一种新的软件开发模型：增量模型。其将一个软件项目分成有序的开发周期，每个周期都重复一系列相同的开发活动，都按照增量的思想完成一些特定功能，向用户交付部分可工作的产品。

如图3-4所示，增量型项目生命周期。

图3-4 增量型项目生命周期

20世纪80年代中期开始，随着瀑布方法的局限性越来越显现，增量模型的应用逐渐提高。早期在《软件工程中基于知识的沟通过程》中有一篇文章就倡导使用增量模型，具体原因是描述为“不存在确定完整的、稳定的需求规格”。

我们来了解下增量型的要点，其架构要能支撑这种增量组件化的开发模式，组件间尽量解耦，相互之间的依赖较少，也可以并行开发，每次增量的结果都可以运行和发布。通过频繁发布来修正已完成的交付结果，再开发新的组件。在最后一次的发布，就是一个完整的产品。

这时陈恭说道，增量型，我们之前也有过类型的经历。当时开发一个零食供应商的云上商场App，他们之前有线下的运营实体店，也有自己的进货渠道，所以他们很清楚自己应该先满足什么需求，但并不清楚整体都要什么。面对这个情况，我们就调整架构模式，先保证将他们已有的线下运营模式搬到线上，先让他们试运行。等到线上运营一段时间后，他们就发现需要会员积分兑换、售后记录评分、进货质量评价等功能。我们再持续增加，一块一块的堆集，最终在试运行结束后，日常运营所需的功能模块都完善了，就形成了最终的完整商场App。

“这个例子非常正确，是典型的增量型的开发模式。”马丁说道。

（二）增量型项目生命周期适用范围

春哥打断马丁：“感觉增量型和迭代型很像。”马丁眼前一亮：这个问题很好，我们就通过增量型的适用范围来了解下它的特点。

马丁继续说，增量型会比较好的适应需求的变化，用户可以持续不断地看到交付结果，并给予反馈，从而降低交付风险。

（1）在项目初期，需求能确定一个大概的框架，可能会有较多细节的调整。

（2）架构比较稳定，交付的产品可以按照组件化进行解耦。

（3）小规模产品，但产品生命周期较长（需要持续运营的）。

（4）开发团队资源有限，需要在短时间内拿出成果。

从适用范围来说，增量型和迭代型有明确的不同，前者是有个雏形，逐步完善，后者是按照模块叠加新的功能。

（三）增量型项目生命周期的痛点

不过增量型的痛点也比较明显，如每个新的增量组件集成到已有的产品结构中时，较难做到既不破坏原来成型的产品，又能较好地融合，这就对架构和开发团队提出了很高的设计要求。 

增量型的思想有自相矛盾的地方，产品的本质是要求保证完整性，需要从整体视角来做设计开发，才能提供给用户一个完整而良好的用户服务和体验。但增量型又指导开发团队把产品解耦成单个组件，每个组件都可以独立于另一个构件。这需要开发团队有足够的技术能力来协调这一矛盾，否则增量开发出来的产品可能并不能令人满意。 

同时，增量型的灵活性是把“双刃剑”，其在适应需求变化的同时，也很容易因为设计的不周全，进而边做边改，过程容易失控，导致最后交付的产品失去整体性。越往后变更越困难，存在成本逐渐上升的风险。

大家说感觉增量型也不是完全适用于当前的“菜多多”项目，我们现在还没有比较成熟的架构体系，也没有梳理出比较清晰的产品功能模块，对于功能之前的关联和耦合都是未知。春哥补充：“对于每个增量都能发布，我们还没有做好准备。”

马丁思考一会儿后，说：“咱们继续说说下一个。”