通过上述咨询顾问深入浅出的讲解，团队也对每个项目生命周期有了更深的了解。不过看大家的表情也知道，一下子讲这么多知识和概念，确实很难完全理解和掌握。现在我们还得请马丁帮我们梳理下，到底该如何选择合适的项目生命周期，四种模式又有何异同。

看着大家的反映，马丁也是一脸无奈：“我就再给大家说一说，先从比较开始。”

（一）开发方法的比较

在PMBOK描述的三种开发方法中，适应型方法可以分为增量型、迭代型、敏捷型。混合型实际上就是预测型和适应型的结合应用，一般是预测型中叠加了适应型。

四种开发方法中：

（1）预测型：传统方法，关键点在于提前进行大量计划工作，然后一次性交付，严格依赖顺序执行，尽量控制和减少变更。

（2）迭代型：多次迭代，一次验证，整体交付。

（3）增量型：将整体划分成小块，多次交付，多次验证。向客户提供各个已完成的交付成果，从而可以立即使用。

（4）敏捷型：引入敏捷方法论，既有迭代又有增量，通过频繁交付+回顾的方式持续提升质量，积极响应变更。

四种管理模式比较如表3-2所示。

表3-2四种管理模式比较

（二）四种模式的区别

咨询顾问扶了扶眼镜，语重心长地总结着。终于等到了大家翘首以盼的结论：以上说了那么多的概念、知识点，又是比较又是融合。目的就是让大家入木三分、知己知彼。简单来说，以价值交付理念和IT技术专业化两个维度，即只考虑市场和客户带来的“业务变化性”和IT技术自身存在的限制“技术复杂性”。我们建立一个“一目了然”的选择方法。

我们总结一个“选择象限”法，虽然不会很精准，但可以给大家提供一个引导和思考的起点，如图3-6所示。

图3-6 “选择象限”法

如果业务变化较高、较频繁，并且需要通过市场和用户来挖掘真正的需求，对于技术上都比较成熟的模式，则可以选择迭代型。

如果市场已经比较成熟，且有典型的网红产品，需要以新技术为驱动力去改进市场，则可以选择增量型。

如果市场成熟，业务变化较缓慢，则选择预测型的效果最佳，既好控制成本，又好规划预期。

如果业务变化也快、技术复杂度也未知，则可以尝试通过敏捷型来解决这些棘手问题。通过渐进明细的规划，先建立框架，快速形成MVP（Minimum Viable Product，最简化可运行产品），探索为客户创造价值。

（三）“菜多多”的选择

马丁继续带着大家进行深入的推演和分析：我们新成立的这个团队，还是对于预测型最熟悉，大家已经可以说是炉火纯青。但有时候因为不能一次性交付，或者规模太大，就会自己拆分多个阶段进行分步交付。对于每次分步交付的内容，如果是可以独立运行但并不完善、无法交付客户的情况就比较像迭代型；如果分步交付的内容相对较为独立、完整可以运行，只是不能满足客户的全部期望，则比较像增量型。

以上情况大家或多或少的遇到过，就不能理解迭代型和增量型。但是对于敏捷型，咱们团队还确实没有人正在完整实践过。如果直接应用敏捷型对我们的要求就不仅仅是各自的专业技能的提高，对于我们来说最不确定的就是思想上能否完整理解，行动上是否可以和敏捷实践一致。每个项目的过程都会遇到各种各种的风险和问题，一旦在关键时刻大家因为无法像瀑布模型一样熟练配合，对于产生的种种协作问题进而怀疑敏捷，导致质疑目标和方向的无法实现，那样团队就会进入极大可能失败的境地。

听完马丁的详细推演和剖析后，刚才说敏捷型适合我们的成员们有点不知所措。马丁看出了大家的疑惑，继续说道：“由此我们非常明确的了解了四种项目生命周期的应用，好像纯敏捷型也不太适合我们的菜多多。”马丁整了整衣领，提到了一种融合型的方法。看图3-7，我们所处在的范围。

图3-7 我们所处在的范围

为了保证“菜多多”项目的顺利开展，我们主要是以敏捷型为项目生命周期，开发方法先以预测型切入一个周期，然后开始对“菜多多”深入了解，针对不同交付目标的功能进行拆分，然后引入迭代型和增量型，进行符合客户价值的交付模式。

最终“菜多多”团队决定选择从预测型到敏捷型进行演进，保证融合模式的逐渐落地。如图3-8所示。

图3-8 从预测型到敏捷型演进