架构之道之软件开发过程的瀑布模型

         软件开发过程描述的是软件构造、部署还有维护的一种方法，早在 20 世纪 70 年代，人们为了改变软件开发混乱、随意、无秩序的状态，提出了经典的瀑布式软件开发过程。在这样的模型下，人们发展了经典的项目管理方法，提出了诸如 PERT（计划评审技巧）、甘特图以及早期实现软件预估的一系列项目管理原则。

         在经典项目过程中软件分析占了软件设计很大一部分工作量，用户、市场、分析、设计，是整个软件设计中密不可分的几个部分。模型要求在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来，并且实际开发前冻结需求。在概要设计阶段主要需要建立系统高层模型，建立系统和子系统的框架以及基于服务的层等。在详细设计阶段，可以精细的把业务需求转换为系统模型。然后在实现诸如编码、测试、系统集成以及发布等下游模型。经典瀑布式过程的大致情况如下图所示。

二 、 经典项目管理导致失败的原因

       经过 20 年的应用，人们发现经典项目过程存在很多问题，这迫使人们研究它存在的问题，以期找到解决方案。一个项目成功的关键是有良好的规划，产品在初期规划的时候，应该说明产品应该具备哪些能力？在什么时间完成？需要哪些资源？需要多少资源？这些信息有助于我们通过项目规划减少风险、降低产品目标的不确定性、为更好的决策提供支持，这是构建良好的项目管理必备的信息。但是，经典项目管理最困难的问题是项目难以规划，做出来的计划往往会出错。于是开发小组往往走向两个极端：要么是不做规划，这样的小组根本无法回答“你们什么时候能完成？”这样的问题。要么是在计划中投入大量的精力，直到自己确信计划是正确的，但这种“正确”往往是自欺其人的，这种计划可能更全面，但不意味着更准确或更有用。因为软件的特点不确定性是始终存在的。

   下图显示了 Boehm 所考虑的不确定性在顺序开发过程不同点的范围，这个图称之为不确定性锥形。图上表明，在项目定义阶段，对进度估计的偏差可能达到 60% ～160%，也就是说一个预期 20 周完成的项目，实际花费可能在 12～32 周之间。而在写下需求之后，估计的偏差可能还在±15%，这时的 20 周预期可能实际上可能会花 17～23 周。这么大的预估偏差根本就无法实施有效的项目管理。

尽管经典项目管理把费用、质量（功能目标）、时间设定为最重要的三角约束，遗憾的是很多人的研究都告诉我们，传统方法不一定会得出满意的答案，下面是很多人做的研究结果：

1. 大约 2/3 的项目会显著超出费用预算（Lederer and Prasad 1992）。
2. 产品中 64%的功能很少或者从不会被使用（Johnson 2002）。
3. 一般项目花费的时间会超出进度表 100%（Stndish 2002）。

这就迫使我们仔细研究项目失败的原因，归纳起来可以有 5 个原因。

1. 基于活动而不是基于功能进行规划

   传统项目管理方法的一个关键问题是，它们强调的是各项活动的完成而不是对功能的交付。以传统方法管理的甘特图或者工作分解结构指明了要进行的活动，我们可以基于这种方法来度量开发小组的进度。这种基于活动的管理存在着一些问题：

第一个问题是：客户并不能从活动的完成获取价值，功能才是客户价值的计量单位。所以，规划项目应该是在功能层面上的而不是活动层面上的。

第二个问题是：当我们审阅进度表的时候，我们实际上是在寻找被遗忘的活动而不是缺少的功能。

第三个问题是：基于活动的计划往往导致项目超期，而一旦面临项目超期，项目组或者通过不恰当的降低质量来节省时间；或者通过变更控制程序来限制变动，即使是是高价值的功能变更，也往往被限制。为什么基于活动的规划会导致项目超期呢？我们可以从三个方面来讨论它的原因：

1）活动不会提前完成

设想某一个资深程序员正在为一个产品编制一个有趣的新功能，同时他还承担了一个为CMMI 审核准备文档的任务，他会怎么样分配时间？毫无疑问，他会把大部分时间用于编制这个有趣的程序，而准备审核只留下了刚刚够用的时间，而且是到最后才不得不草草完成。实际上这种行为非常普遍，以至于有了一个名称叫帕金森定律（Parkinson’s Law，1993）：“工作总是要拖到最后一刻才完成。”如果一项工作在甘特图上分配了 5 天，处理这个活动的员工一定会用满 5 天，即使能够提前完成，他也会通过增加一些花哨的修饰（镀金需求），或者尝试着用一些新的热点技术。在不少企业文化中，一项活动提前完成，往往被指责为当初他做的估计不准确，或者会另派其它的任务给他，为什么要冒这个风险来提前完成呢？人的本性就是如此：用多余的时间去做一些对自己有价值，但对别人不一定有用的事情。

2）延误沿着进度表向下传递

   由于传统的计划是基于活动的，因此它们主要关注活动之间的依赖性。如果需要提前完成测试，就要求编码提前完成，而它受到向数据库添加数据表这一活动完成时间的影响。任何一件事情，都可能导致测试推迟。事实上我们已经确认了活动很少会提前完成，所以发生的绝大多数事情是延误，而这种延误会沿着进度表传递下去，最终导致后续项目很少会提前启动。

3）活动不是独立的

   当一项活动的时间范围不影响另一项活动的时间范围的时候，我们称这两项活动是独立的。但是，在软件开发中，大部分活动之间是不独立的。比如编写客户端程序，如果第一个界面花费的时间超过计划 50%，那么接下来每个界面花费的时间都要比计划的多。换句话说，如果一项活动花费了比计划更多的时间，那么所有类似的活动都可能花费比计划更多的时间，积累起来数据就会非常庞大。

2. 多任务处理导致更多的延迟

   传统项目管理方法会失败的第二个原因是多任务处理。多任务在处理两件事情上有时候是有道理的，当在一项工作中受阻的时候，暂时放下这个工作去做第二件事情，也可能回过头来第一件工作的障碍就在不知不觉中消除了，这是很多人的经验。但是如果同时处理 3 个甚至以上的任务，那么任务之间的切换所花费的时间和代价就会大大增多，会对生产率产生可怕的影响。

3. 不按照优先级开发功能

   传统项目管理方法不一定能够带来高价值产品的第三个原因是，制定的计划没有按照对用户或者客户所具有的价值大小来排列工作的优先级。很多传统的计划实际上假定工作都可以完成，工作的顺序主要是由依赖性来决定。但是随着项目结束时间的逼近，开发小组会匆忙放弃一些功能以跟上进度，由于不是按照功能优先级顺序开发的，某些被放弃的功能反而比交付的功能更重要。

4. 忽视了不确定性

   传统规划方法的第 4 个缺点，是不承认不确定性的存在。人们假定最初的需求分析就可以产生对产品来说完整的、完善的定义。我们假定用户在计划覆盖的整个时间内都不会改变想法，他们的观点也不会更细化，也不会提出新的需求。与之类似，我们还忽视了如何构建产品这样的不确定性，某种技术在实现中才发现并不一定

合适，但我们已经给它分配了确定的时间（两个星期），事实上我们不可能指望一开始就确定项目进程中所需要的所有活动，但我们又不愿意承认这一点。事实上，随着项目的进展，项目的不确定性和风险会逐渐减少，这样就可以做出更精确的估计，但这样一种处理问题的风格，在受过严格经典项目管理训练的管理层面前，会不会受到认可？

5. 把估计当成了承诺

   在每个估计中都包含了一个可能性，它表示了某个特定工作在估计的时间内得以完成的可能。如果开发小组或者利益相关人把估计当成承诺，传统项目管理方法就会出现问题。对可能性做出承诺几乎是不可能的。

          在分析了传统项目管理方法所存在的问题以后，我们对那么多项目令人失望就不会感到奇怪了。基于活动的规划方法分散了我们对功能的注意力，而功能才是衡量客户价值的单元。本来项目的参与者满怀好意的把多任务处理当成解决延误的办法，结果却造成项目更加的延误。当进度表剩余时间不够的时候，不可避免地要放弃一些功能，由于开发人员是按照最有效的开发方式来安排进度的，因此放弃的功能对用户来说不一定是价值最低的。忽视用户需求的不确定性，会导致虽然按时完成了任务，但很多后来发现的重要功能没有办法加入，或者即使加入了但要不是项目延误，或者不恰当的降低质量。这是在这些分析的基础上，我们就必须考虑解决这些问题的办法。