第章合理运用瀑布式开发方法

第27章　合理运用瀑布式开发方法　Succeeding with the Waterfall Process

扬长避短

本章讨论目前大多数产品团队仍然在使用的开发方法——瀑布式开发方法。

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

大多数开发团队仍然在使用瀑布式开发方法，只是人们不好意思承认，所以纷纷换了别的称呼，比如，持续改进方法、里程碑式开发方法等等。

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

瀑布式开发方法的基本原则

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

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

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

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

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

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

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

瀑布式开发方法让产品经理头痛的地方

从产品经理的角度来看，瀑布式开发方法存在不少问题。

产品验证严重滞后

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

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

变更计划代价不菲

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

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

无法适应快速的市场变化

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

小结

了解了瀑布式开发方法在实际应用中的缺点，就不难理解为什么要改用Scrum和极限编程这类敏捷方法了。

瀑布式开发方法过于理想化，以为人们能预见所有问题，全面把握需求。实践证明除非是规模很小的项目，否则瀑布式开发方法很难顺利执行。

如果采用传统的瀑布式开发方法开发产品软件，产品的交付时间通常会比预期的晚，而且用户常常发现产品存在缺陷，开发团队还需要花费大量的时间和资金修补、完善。

如果不得不使用瀑布式开发方法，产品经理应该设法规避以上提到的问题。首要的工作是在探索（定义）产品阶段，制作产品原型，请目标用户试用，确保产品设计是有价值的、可用的、可行的。只有这样才能提高产品成功的几率，同时节约开发团队的时间和成本。