【IT168 专稿】

    Rational统一过程（Rational Unified Process，RUP）提供了一个极有价值的软件开发业务框架，它正在成为一个广受欢迎的当代软件开发过程的事实标准——它整合了公认的非常好的实践，例如适应性的、迭代的和风险驱动的开发模式；它是由在大、小型系统开发中均具有丰富经验的世界级领导者设计的；它在应用和扩展上都很灵活，而且被正式的出版物以及相应产品很好地记录了下来。然而作为框架，必须根据每个项目团队及其环境的需要进行调整。RUP 本来是用一种轻型和敏捷的方式来开发项目的，而不是被当作一个“功能较多尺码”的开发过程。若干因素妨碍了RUP的成功实施，其导致的结果往往非常糟糕。

    本文用略带一点俏皮的口吻，与大家分享一组常见的RUP应用陷阱。如果您的目标是让RUP实施的结果一塌糊涂，那么我们向您推荐以下七招。

第一招：在RUP之上叠加瀑布思维

    您的开发过程是否有点像：(1)企图定义和稳定绝大部分的需求，然后进行签署；(2)基于需求，进行详细设计；(3)基于设计，进行实现；(4)进行集成、系统测试和部署。这是一个线性的、串行的瀑布型生命周期的典型例子，而且是一个最优先的、最棒的，也是最常见的让RUP实施完全失败的策略。如果您的开发过程看上去与这很像，那么祝贺您，您成功地没有采用RUP！

关于瀑布型生命周期与迭代式开发最重要的一件事是，我们在20世纪60年代和70年代被误导了：许多人当时接受到的教育是瀑布式做法是聪明老练的。然而，历史研究表明，这一建议的出现并没有得到任何统计意义上的证据的支持，而且更为重要的是，当前的软件项目失败研究结论性地表明，瀑布型是风险最高、极易失败、低生产率以及高缺陷率的软件构建方法。如果您要一个软件项目失败，您应该遵循瀑布型做法！而与之相反，现在有极具说服力的证据表明，迭代和演进式方法(如RUP)能带来较低的失败率、更低的风险和更高的生产率。值得称道的是，美国国防部原本提倡瀑布过程和观点，在发现那么多采用了该方法的失败之后，不但放弃了对它的要求(如1988年的STD-2167A标准)，而且从1994年的报告开始，积极地鼓励采用更加现代化的迭代式生命周期来取代瀑布型做法。

从发展的角度，瀑布型过程与20世纪60年代开发软件的随心所欲方式相比，它是一个相对合理的策略。这一做法借鉴了其他领域的工程和建造，但遗憾的是，未经对其应用于软件开发的真正适应性进行认真和严肃的研究，它就被广泛地传播和采用了，于是几代师生都不假思索地学习、不断地照搬它。不幸的是，如今仍有许多软件过程“专家”、咨询顾问、项目经理和过程工程顾问(例如某些带有瀑布型偏好的CMM实施顾问)似乎一点儿不知道已有的研究证据，仍然继续根据自己的主观意愿或信念而非统计意义上的证据来行事。

有些东西必须像建筑那样被建造，然而人们发现软件通常不属于这一类。这有许多原因，最具有说服力的是一个错误的假定，即可以在项目的第一个阶段中定义绝大部分的需求。Capers Jones等人的研究粉碎了这一神话。如图1所示，在这项含有6700个项目的庞大研究中，蔓延的需求(在项目开始时没有预见到的需求)是软件开发业当中非常显著的一个事实，在普通项目中它大概占到了25%，而在大型项目中则占到50%。

需求变化呈常态

    瀑布式价值观和做法是：(1)完成绝大部分的需求，隐含着假定那些以前没见过该产品的用户们能很好地定义这些需求；(2)根据能够精确地为一个定义很差的问题制定解决方案这一假设，进行详细设计；(3)尽管设计还没有被证实，而且往往不可能被证实，仍然进行系统的实现；(4)集成、测试和部署。

瀑布型竭力回避需求变化的现实，它假定需求和设计能够正确地被指明和冻结，这与项目的现实严重不符。软件开发在设计和实现之前无法固定需求有许多原因，但不管什么原因，高明的应对方法不是去“对抗变化”，竭力固定需求，而正相反，应像Kent Beck积极主张的那样“拥抱变化”，并把这当作软件过程的一个核心驱动力。

于是，在RUP当中，开发的行进表现为一系列的迭代，每个迭代都被时间盒限定在一个固定的工期(例如正好4周)当中，每次迭代结束时都将产生最终系统某个子集的一个稳定内部发布。在迭代式开发中，时间盒限定是一个关键的概念：它意在固定迭代的结束日期，而且通常不允许结束日期的推迟。如果无法满足所有的目标，那么就要从迭代中去掉一些需求，而不是延长当前迭代的工期。

在一个迭代中，有一种类似微型瀑布的情况。首先挑选一小部分需求，相对全面地对其进行分析；用几天时间进行设计，然后迅速地对系统的这一部分开始实现、集成和进行实际的系统测试与压力测试。每次迭代的结束将产生一个可运行的部分系统，它能产生反馈，并引发未来迭代中对需求和设计的调整。随着时间的流逝，这些反馈-适应迭代周期揭示了一组合适的需求和一个健壮的、经过验证的设计与实现。这里，一个串行的瀑布方法在周(而不是月或年)的尺度上得到了应用，而且存在一个有机的反馈和适应机制。在一个数周的时间尺度上，一个串行的生命周期是可行的，然而当迭代长度增加时，这种方式将不再有效。

即使到了今天，在第一轮警报响起的十多年之后，仍有不少咨询公司、管理者、教师和作家们把瀑布型生命周期或观点当作一门优越的技术来提倡。克服有意识或无意识地在RUP和迭代式开发之上叠加瀑布价值观，是一个项目团队面临的最大挑战之一。真正掌握了RUP的一个最深刻的变化不在于诸如写用例、对象建模等技能上，也不在于在学习RUP提供的许多工件和活动上(所有这些都是可选的)，而在于对瀑布思维的根本态度和期望的转变。下面是RUP事实中四个典型的错误。

错误一：在RUP的阶段上叠加瀑布型阶段

RUP开发周期由四个阶段组成(起始、细化、构建和移交)，导致RUP实施失败的最常见策略就是把这四个阶段与瀑布阶段(需求、分析设计、实现和部署)直接等同起来。在此对RUP的四个阶段作一简短描述。

1. 起始：制定系统的业务依据；探查一小部分(大概占10%)但很重要的需求，以便对项目范围的大致规模和关键风险有比较准确的把握，并决定是否值得为细化阶段拨付资金。

2. 细化：迭代地构建核心架构，消除项目的主要技术风险。所谓的构建架构，是指真正地编程、集成和测试——决不是纸面上的练习或可抛弃的原型。为了达到这一目的，可能需要迭代地详细探查绝大部分的需求(可能占到80%)，并同时并行地实现系统中有风险的核心部分。在这一阶段中，通过反馈-适应周期不断地评估部分实现，需求则可能发生显著的变化。请注意与经典的瀑布式需求定义不同，RUP的绝大部分需求是在与开发核心架构的工作并发的过程中精化的，而且从实际的开发当中获得了反馈。在此阶段，还要决定是否为项目的最终完成拨付资金。

3. 构建：迭代地构建在细化阶段尚未完成的内容，进行迭代集成和质量保证，为部署作准备。在这一阶段需求变化较少，因为大部分需求的不稳定性已经在前面阶段得到了迭代式的澄清。

4. 移交：完成Beta测试，解决遗留问题并部署系统。

错误二：迭代不是太长就是太短

如果把计划的平均迭代长度定为6～12个月，在绝大多数情况下是很不适宜的。RUP有一条惯例：“在理想情况下，一个迭代的工期应该是2～6周。”迭代式开发与RUP方法的精华在于通过小规模的工作步骤逐步获得一个可能不完善的实现，接着快速集成，进行QA和测试，快速获得反馈，然后基于该反馈调整需求、设计和实现。短小的步骤、反馈和调整是关键的思想。过长的迭代则达不到这种效果，因而是使RUP实施失败的一个良好策略。

错误三：在设计前磨亮需求

迭代式方法允许有指导方向的试验和创造，而瀑布方法迫使我们从一开始就必须做到聪明绝顶，这种在没有反馈的情况下，把绝大部分需求定义并稳定下来的想法与软件开发的现实不符。

假设用瀑布方法建议我们购买软件的方式来购买衣服，那么，我们必须要在看不见能得到什么的情况下来确切地描述我们需要什么，甚至还不能先试穿一下，看看穿上这件衣服效果如何。我们必须要在真正收到这件衣服的几个月甚至几年之前，精确地指明每一个测度。一旦我们改变了主意，或者长胖了、变瘦了，那只有老天来帮忙了。不错，这恰恰就是瀑布方法的解决之道——在设计或实现之前确定绝大部分的需求。如果我们连买衣服都不想用这种办法，那么，凭什么让我们相信它对软件开发也是有效的呢？

错误四：项目刚开始就期望获得可信的估算和详细的计划

一位石油业高层主管对您说：“我听说FooBarKhan那里有石油，我太想要了！请您赶紧用一周的时间写一份报告，告诉我那里有多少石油，在那里建油田需要花多少钱、多少时间、多少资源。”在石油业中，这样的场景是很滑稽的，为什么同样的做法反而被软件工业接受了呢？理智的石油人士知道：没有预先在试验性钻探上大量投入是不可能获得答案的。只有通过调查发现了储量和地质情况的真相，作出估算或初步的计划才有可能。可是，在同样的不确定性和高复杂度的情况下，我们却奢望没有投入实际的“试验性钻探”调查就能对软件项目进行估算和计划，这不是很可笑吗？

仅仅因为我们能够作出计划显示出我们正取得进展，并不意味着我们真的能够做到。在没有获得任何关于未完成工作量的真实信息的情况下，在日程表上填上精确的日期是容易的。如果我们依赖完美的计划来交付一个项目，那么失败将是注定的。迭代方法允许我们边干边学，随着迭代的进行，我们获得了有关真实需求的更多信息，对真正的风险有了更好的了解，对我们应对项目的各项挑战的能力也有了更为清晰的认识。

有时固定价格交付要求的存在被当成瀑布方法的一个理由，因为在没有真实信息的条件下作出决策也是合理的。迭代方法对初始的估算可能并没有什么改善，不过您能很快知道您做得怎么样，然后您可以更加容易地选择必要的时机启动协商，设定干系人的期望和管理项目范围。正如RUP所倡导的，一个处理固定价格投标与合同的理智方法是一种两阶段的策略。在第一阶段中，针对初始短暂(比如4周)的固定时间和固定价格签订合同，以便开展实际的调查和试探性编程，以产生更加成熟的范围、风险和需求规约。这一经改进的规约随后可被用作第二阶段(完整的开发)投标的基础。第一阶段调查的投入并没有浪费，其结果将节省第二阶段的工作量，并有助于产生第二份(最终的)更加符合实际的合同。