如何选择项目开发模式 - 我们一起学项目管理 （十八）

今天说个题外话，项目的开发模式。之前我们已经制定了项目计划。并且找到了项目的关键路径。还记得我们在《再聊项目的关键路径》一文中，用甘特图来讲解项目计划吗？不记得的可以看下图唤醒你的记忆：

为什么要把这个甘特图拿出来呢？因为这个甘特图是基于可以添加资源，来迎合项目交付日期的假设的。现在思考一个问题，如果资源不能增加，又不能更改项目交付日期，该怎么办呢？

这就需要我们从项目的开发模式上入手思考了。

项目的开发模式，一般分为三种，瀑布式，迭代式和现在如火如荼的敏捷开发。

瀑布式：是最典型的预见性的方法，严格遵循预先计划的需求分析，设计，编码，集成，测试，维护的步骤，并按照顺序进行。每一步骤结束之后才能开始下一步骤。而前一步的成果物会作为后一步骤的输入物。如我们的例子中就是使用的瀑布模型。

优点： 对于每一阶段的产出有严格的要求。对于项目质量的追踪非常密切。

缺点： 不够灵活，严格的分阶段导致自由度降低。对于项目后期需求的变化难以调整，或者说调整的代价过于高昂。

对于一个项目来说，越早期的调整对于项目的影响越少。而瀑布式的开发模式，客户在最后阶段交付的时候才能看到成果物。一旦成果物有偏差，调整起来的代价势必相当巨大。也鉴于此，使用瀑布模式开发，对于早期需求的提炼，分析和把控相当的重要。而需求不明或者项目需求经常变化的情况是不建议使用瀑布模型的。

迭代式：是一种与瀑布式开发相反的开发过程，他弥补了传统开发方式中的一些弱点，具有更高的成功率。

所谓的迭代开发，就是每次只设计和实现一个产品的一部分，逐步完成整个产品。说白了，就像画画一样，先画轮廓，然后得到客户反馈后在画细节。每一次迭代都会经历瀑布模型的需求分析，设计，编码，集成，测试，维护的步骤。即我先做到从没有到有，然后再精益求精，慢慢优化。

优点：每一次的迭代，客户都可以看到成果物，然后做出反馈。相比瀑布模型在整个项目最后看到结果，每一次迭代的完成都可以看到相关的结果和得到客户的反馈。同时，每一次跌代里，都是小的瀑布模型，从而保证了每次产出的准确性。

缺点：明知道项目中的不足之处，但是不马上修复。将主要精力优先放在从无到有的过程中。

所以对于迭代模型，即保持了瀑布模型成果物的高质量，也降低了项目在实施过程中需求频繁变化造成的负面影响。但是在短期内，无法整体到达客户质量要求。

敏捷开发：是一种应对快速变化需求的一种软件开发模型。更加强调面对面的沟通。和非敏捷类模型不同，敏捷开发，强调：

人和交互终于过程和工具

可以工作的软件终于求全而完备的文档

客户协作终于合同谈判

随时应对变化终于循规蹈矩。

于是对于敏捷的模型，可以归纳为，整个团队是一个整体来工作的；有迭代周期，每次迭代交付一些成果物。这些和迭代很像。但是不同于迭代的是，敏捷的周期更短，适用于项目初期需求不明确的情况。

因为敏捷开发的模型，并不注重整体的项目进度。相反的敏捷强调的是业务优先级，检查和调整。于是即使在项目初期需求不明的情况下，使用敏捷的方式开发，可以做到每个迭代周期都能够得到基于该迭代周期的成果物。而客户可以根据当前迭代周期的成果，确定后一周期的目标。所以，敏捷强调的不是预见性，而是适应性。

优点：适用于项目初期需求不明的情况。

缺点：适合与小团队，不适合与大团队实行敏捷。对于团队成员要求比较高。对于项目整体的目标没有清晰的设定。

最后简单对于几个开发模型的区别做一个总结：

瀑布式开发模型，对于需求，设计，编码，测试，交付各个阶段，每一个阶段都要求做到最好。前期阶段也好，后期成本损失也少。即，做的慢， 但是完美。前提是需求不能变。

迭代式开发模型，不要求每一个阶段的任务做的是最完美的，知道有不足，但是不去完善它。即用最短的时间，搭建一个不完美的成果物。然后在通过客户反馈信息，逐步完善。

敏捷开发模型：强调团队高协作。开发周期比迭代更短，常用于项目初期需求不明的情况下。通过适应性弥补预见性不足。即当需求发生变化时，快速反应，产出成果。但是具体项目将来要做成什么样，并不知晓。

现实场景中的项目其实并不仅仅使用一个开发模型的。项目经理需要根据当前项目阶段的特点，来选择合适的项目模型。

如果当前项目初期需求经常变化，那么敏捷会是一个不错的选择。而一旦需求确定了，可以使用迭代的方式，进行开发。并且将瀑布模型植入迭代的每一个周期。这样既保证了迭代的每一个周期的产出质量。有可以适应客户经常变化需求的客观事实。

当然，项目有特殊性，所以具体问题还需要具体分析。切记照搬经验。