1.2 重新审视瀑布模式为代表的传统开发方法

40多年前Winston Royce（1970）博士提出的瀑布开发模式（Managing the Development of Large Software Systems,1970年8月）对软件的发展起到了一定的好的作用。这个开发生命周期识别出了软件开发需要做的重要活动以及除代码外的中间产出物。它对需求明确、开发技术成熟的项目确实有很好的指导作用。令人遗憾的是，40多年来绝大多数人忽略了Royce博士在他的文章里面的一句话“I believe in this concept but, the implementation described above is risky and invites failure.”这句话的意思是：“虽然我相信提出的概念，但是要注意，具体实施这个开发模式时会有很大的风险，它也可能带来失败。”

瀑布模式到底适用于什么样的项目呢？如果下面这些假设是对的话，瀑布模式会是一个非常合适的软件开发方法。

（1）客户在项目开始时，可以准确描述他们真正需要的产品需求；而且开发团队在整个开发过程中不需要客户的任何反馈，仅需要客户在项目结束时对实现的功能进行确认。

（2）开发团队在项目开始时已经很清楚为完成开发工作所需要的一切：人、技术方法和工具等。

（3）项目的进展状况可以通过里程碑完成的文档（而非通过测试的代码）来评估。我们也可以有效地将团队分成4个不同的组：分析、设计、编码和测试。虽然前面组的输出是后面组的输入，但这个接力过程不会有信心的流失。

（4）仅在项目结束时对代码进行测试就能保证产品质量。

1.2.1 来自制造业的接力式开发模式

工业革命带来的流水线生产模式极大提高了生产效率，同时通过对生产制造过程的持续完善改进，产品质量也得到了保证。虽然软件瀑布开发有一条看不见的流水线，但它基本采用了生产线的思路。图1-3是大家熟悉的瀑布式开发生命周期。

很明显这是个接力过程。让我们考虑一个最简单的场景：我们需要在一个已有系统上追加一个功能特性。首先系统分析员会写好一个描述需要实现功能的需求文档，开发人员没有机会和这些功能的使用者有任何沟通，他们将仅仅依赖于这个文档完成代码编写。写好的代码被提交给测试人员，通过测试后，当刚刚实现的功能特性第一次展现给客户时，如果客户的反应是“这不是我要的！”，相信你不会太意外吧！

那么这是谁的错呢？你可能会抱怨客户一开始没讲清楚，也可能指责分析师没有把需求写清楚，程序员有可能成为替罪羊，测试人员也可能是主要的责任人。如果我们好好反思一下，也许真正的问题出在我们的方法上：在这个接力过程中，每个人只负责一段，没有必要的反馈环，以保证及时发现问题、及时调整。任何阶段出现的问题都会继续被传递下去。同时在接力过程中，信息流失是经常发生的。记得看过一个5人参与的电视节目，第一个人做个动作给第二个人看，然后第二个人努力将看到的做给第三个人看，直到最后一个人做给观众看。往往最后一个人展示的动作已经和第一个人的原始动作相差很大了。正是这些差距让观众哈哈大笑。

当这些差异在软件开发过程中出现时，就一点也不好笑了。这些差异正是让客户、管理者、团队头疼的问题。

软件产品开发由一系列互不相交的阶段组成，瀑布模式要求上个阶段所有工作完成并通过了出口检查评审后，下个阶段才可以开始。如设计工作应该在明确定义了所有产品需求，这些需求通过了相关评审后才会开始。实际情况是什么呢？如果读者做一下调查，会发现95%的调查对象会承认设计工作在需求活动完成前已经开始了。这应该是业内公开的秘密，所以很少有团队真正在100%执行瀑布模式。

制造业的生产过程是高度重复，其过程明确定义了每一个生产步骤。而软件开发中的不确定性，导致了过程重复度是有限的。任何两个项目都不会完全一样，不可能走过同样的开发步骤。这个差异是“明确定义的过程”不适用于复杂软件项目管理的重要原因。

1.2.2 瀑布开发模式的不合理之处

从项目立项开始到产品发布，什么时候我们对所开发产品了解得最少？答案很清楚：项目的起点是我们对产品需求、所需技术、团队人员能力等关键信息了解最少的时候。瀑布模式要求我们在这个时间制订出并承诺项目目标和计划，包括实现产品范围、功能、性能、进度和成本。

那么在信息最少时做计划的最可能的后果是什么？一个字：变。需求会变，人员会变，技术方案会变。可令人沮丧的是，瀑布模式同时会惩罚变更，因为变更的代价往往是团队不能承受的。

在瀑布模式下需求变更一定是坏事吗？请你稍微考虑一下再回答这个问题。比较恰当的答案是：视情况而定。那么视什么情况呢？答案是变更的时机。前期变不是坏事，因为变更成本不高，很可能就是改一下需求文档并和相关人员澄清而已。需求变更时机越靠后，变更影响范围越大，变更成本就越高。在验收时客户提出大的需求变更的话，对项目组来说更是灾难性的。接力模式也大大增加了技术变更及人员变更的成本。

看一下软件项目管理中著名的七大恶：

不稳定的需求；

不靠谱的计划；

不切实际的项目进度及预算；

项目失控；

项目投入不当；

永远的借口——“我们特殊”；

缺乏对质量的真正关注。

如果我们认真做一下根源分析，瀑布开发模式及在对所开发产品了解最少时做出对产品功能、性能、进度、成本的承诺并惩罚变更，是一个重要的原因。