合理运用瀑布式开发方法

瀑布式开发方法已经有三十多年历史了。虽然开发人员和产品经理们早已怨声载道，但它依旧是最常用的软件开发方法。

   
        今天我们郑州软件公司就来结合郑州软件开发生涯来谈谈瀑布式开发。
        大多数开发团队仍然在使用瀑布式开发方法，只是人们不好意思承认，所以纷纷换了别的称呼，比如，持续改进方法、里程碑式开发方法等等。

        本文先揭示瀑布式开发方法的主要缺点，然后着重探讨产品经理如何在瀑布式开发方法中扬长避短。

        传统瀑布式开发方法的理念很简单，主要有两点。

        1．采用阶段式开发  软件开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、 设计低层细节、编写代码、测试、部署。

        2．采用阶段式评审  每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段。

   
        瀑布式开发方法有正式和非正式两种形式。正式的形式可以参考美国国防部软件开发标准2167A及后来的标准498，其中详细地描述了该方法所有阶段的流程，以及需要提交的文档。更常见的还是非正式的形式：首先由市场人员收集市场需求，提交给开发人员；接着由开发人员制订开发计划，设计软件架

构，进一步完善设计细节；然后进入开发测试阶段，完工后邀请用户测试产品，最后部署。

   
        在讨论瀑布式开发方法的局限性之前，有必要先回顾一下它经久不衰的原因。

   
        首先，瀑布式开发方法的流程具有可预测性，因而深受管理层欢迎。只要能准确理解需求和技术，而且需求不再变更，开发团队就能为大规模的、复杂的项目制订精确的开发计划。这种情况虽然很少见，但并非不可能做到。相反，迭代方法的迭代次数不可预估，难以让管理层安心。

   
        其次，采用瀑布式开发方法，在每个阶段结束时都会提交书面材料。有了翔实的文档和设计图表，管理层、客户（委托方）、开发人员觉得所有工作都是经过深思熟虑的，才能放心。这些材料可以从一定程度上增强人们对项目的信心。问题在于把书面材料当成定心丸多少有些靠不住，毕竟文档不能像软件

一样运行、验证。瀑布式开发方法让产品经理头痛的地方

   
        从产品经理的角度来看，瀑布式开发方法存在不少问题。产品验证严重滞后这是最严重的问题。产品经理必须等到软件开发的尾声，才能看到可以运行的软件。也就是说，在投入大量人力和资金之前，软件的可用性无法得到验证。

        进入开发阶段之前，产品经理应该制作产品原型，请目标用户测试，确保最终提交给开发部门的产品设计是通过了用户验证的。此外，在设计软件架构、准备开发之前，在定义产品的过程中，产品经理就应该请开发人员评估产品设计的技术风险和可行性，确保交到开发团队手里的产品设计是可行的。

变更计划代价不菲

   
         在瀑布式开发过程中，任何对前期决策的修改都会打舌L开发流程，大量工作需要从头来过，不仅浪费资金，而且耗费精力。此外，在开发和测试过程中常常会发现前期设计中的缺陷，临时修补也会严重延误开发进度。

   
         产品经理负责跟踪客户和用户的需求，如果需求发生变化，修改产品设计是不可避免的，不过是迟早的问题。推迟到下个 发布周期再修改，只是权宜之计。除非有特殊情况，我建议发现问题应尽早解决，从成本上考虑，早改肯定比晚改好

         无法适应快速的市场变化

         瀑布式开发方法严重依赖文档和流程，在这方面开销很大。哪怕是一点小小的改动都要花费不少的工夫。这使得产品经理的压力倍增，因为一方面产品经理要尽量确保提交的产品设计通过了验证、没有缺陷；另一方面，产品发布后产品经理仍然提心吊胆，随时准备着和产品团队以最快的速度修补产品。

        此外，在设计软件架构、准备开发之前，在定义产品的过程中，产品经理就应该请开发人员评估产品设计的技术风险和可行性，确保交到开发团队手里的产品设计是可行的。变更计划代价不菲

   
        在瀑布式开发过程中，任何对前期决策的修改都会打乱开发流程，大量工作需要从头来过，不仅浪费资金，而且耗费精力。此外，在开发和测试过程中常常会发现前期设计中的缺陷，临时修补也会严重延误开发进度。

 
         产品经理负责跟踪客户和用户的需求，如果需求发生变化，修改产品设计是不可避免的，不过是迟早的问题。推迟到下个发布周期再修改，只是权宜之计。除非有特殊情况，我建议发现问题应尽早解决，从成本上考虑，早改肯定比晚改好。

            好了，今天关于瀑布式开发我们就谈到这里了。愿我们郑州软件公司与您一路共行。