煮鸡蛋的启示

　　有个英国人学煮鸡蛋，开始，他把鸡蛋放到开水里煮时总会炸裂。他为此想了各种方法，并找到了一个解决方案：在鸡蛋上打个孔。但在鸡蛋上打孔带来了另一个问题:孔打小了，鸡蛋还会裂；孔打大了，蛋清会在它凝固以前流出来。于是，这个英国人给一批鸡蛋分别打了各种不同孔径的洞，并记录下每个鸡蛋孔径的大小。通过这一方法，他找到了一个最合适的大小──既避免了炸裂，又保证蛋清不会流出来。这时，虽然煮鸡蛋炸裂的问题解决了，但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。为了解决这个问题，他又开始尝试煮不同时间的结果，并从中找出最佳的时间长度。最后，他终于找到了一个放之四海而皆准的煮鸡蛋的方法。这个案例对很多中国人来说是个可笑的例子。因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。 从煮鸡蛋这样一个小小的事件上，中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果，而英国人却仔细地把每一个过程细化到最简单，然后按部就班地执行。（管理软件的发展之路 洪奇）

　　聪明的中国人虽然拥有四大发明，但是对于现代的管理思想，中国人一直没有领会到真谛所在。无论是哪一种的管理方法，过程能力都是特别重要的，虽然生产一件产品的相关人员有千千万万，但是生产出来的产品却只有一种。这种能力并不是从天上掉下来的，是通过制定极为详尽的生产过程规定得到的。在中国接受了ISO的思想之后，这种能力也在国内的制造业中逐渐体现出来。但是在软件行业中，拥有这种过程能力的软件组织仍然是少的可怜，大多数的软件组织奉行的还是一种在八九十年代的个人英雄主义，开发软件单靠个人的力量，能力强的程序员能够成功的完成软件，能力差的则失败。大多数的软件组织中，少数人掌握着代码，他们就是一切，如果他们因为私人原因离开所在的组织，手上的代码则是他们的资本，原有的组织将受到沉重的打击。 中国人热衷于结果，2001年的热点在CMM上，现在还很难说CMM中是不是有一定的泡沫存在，但是可以肯定的一点是，CMM之进入中国软件组织为中国软件工业的发展开创了一个新的时代。中国的软件工业将逐渐摆脱原来的作坊式开发，进入软件工业时代。之所以用软件工业而不用软件产业的原因是希望软件产品能够像工业革命那样进入大规模生产，降低价格的时代。

　　可惜，软件毕竟不同于工业产品，在工业化生产的过程中，质量检测的一个方法是在产品出厂前设置质量检测，通过质量检测的出厂，否则回收。这种方法无法适用于软件。后来，质量检测逐渐倾向于生产过程，在过程中监测产品质量。这种方法比起前一种方法进步了很多，但是它需要对生产全过程进行追踪。这种方法的思想正是软件过程的质量保证的精髓所在。

　　在《软件工程》一书中，作者把软件工程分成三层，最底层是软件过程，上一层是软件方法，最高层是CASE工具。软件过程中充满了各种各样的方法论，从需求到最后的维护。要在自己软件组织中应用所有的方法是不可能的。所以你如果看完软件工程的文章后有一种要在明天就实现现代化的冲动的话，打消那种念头，从零做起。

需求过程

　　需求过程是软件过程的一个很重要的部分。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的"祸根"（Leffingwell 1997）。我在自己的身边也做过一次小范围的调查，结果显示成功的项目都离不开成功的需求（一个重要的标志是用户的支持）。

　　需求过程，也有叫做需求工程和需求阶段的，包括了需求开发和需求管理，他们所涉及到的具体工作流如图所示：

　　需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。需求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。

需求过程和CMM

　　软件工程协会 (SEI Software Engineering Institude) 的能力成熟度模型 (CMM Capability Maturity Model) 提供了一种著名的软件过程成熟度基准。CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件过程的成熟程度。（更详细的定义和说明请参看《CMM白皮书》）。

　　CMM中和需求有关系的是第2级（可重复级）中对需求管理的要求和第3级（已定义级）中对需求跟踪能力的要求。必须指出的是，CMM只是规定成熟的软件组织应该达到的关键能力，是一种改进软件过程的策略，对具体的方法并没有做限制规定。所以CMM中没有涉及到需求开发的内容。

需求过程和软件生命周期模型

　　任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？

　　从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

　　典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

　　迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如上图所示。

　　迭代和瀑布的最大的差别就在于风险的暴露时间上?quot;任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。"（RUP）二者的区别如下图所示：

　　由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"（RUP）

　　快速原型（Rapid Prototype）模型是我喜欢采用的另一种模型。快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。

　　上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

　　软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。

RUP和XP

　　RUP是瑞理（Rational）公司经过不断的实践和理论总结发展出来的一套软件开发统一过程（Unified Process）的思想集和方法集。还记得我们在第一章的那张图吗，那就是RUP的核心图。RUP把软件开发过程分成4个阶段（Phases）和9个核心工作流程（Core Workflows），通过一次次的迭代（Iterations），完成整个的软件生命周期。RUP可以把软件开发过程分到非常细小的单位，每个角色（Workers）都参与活动（Activities），产生出工件（Artifacts）。由于精密的控制，所以RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动，但是由于CASE工具的使用，它并不会像传统瀑布模型那样陷入文档的海洋中。RUP通过适当的剪裁，同样可以试用于较小型的项目。

　　XP（Extreme Programming），极端编程。不过好像并没有这样翻译的（听上去像是计算机领域的极右组织）。它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。

　　制定了大量的规则的RUP方法被称为重量级（Heavyweight）的方法，而像XP这样只制定少量的规则来规范行为的方法被称为轻量级（Lightweight）的方法（实际上，现在有一种倾向称这种方法为Agile方法的）。近来，也看到一些文章在讨论两种方法孰优孰劣。例如：XP兴起，RUP不适合中国国情等。我想，这和以前大家讨论C++和Java谁好的性质是一样的。方法都有两面性，只有最适合的方法，没有最好的方法。我在实践中也感觉到，国外的理论确实不能照搬于中国，毕竟中国人的人文环境和国外相差太大了。不过，RUP不适合的，我想，XP也未必会适合。如果说，有人把RUP的一整套东西生搬硬套，导致了最后项目失败的结果的话。这种行为无异于刻舟求剑。

　　在我看来，RUP就像是一个软件工程思想和方法的大百科全书。在其中，你可以看到诸子百家的论调，可以了解软件工程的整个演化过程。RUP是很值得你投入大量时间去研究的东西的。一个武林高手走进了少林寺的藏经阁，你可以想想，那是一种什么景象。一周只工作40小时。相比较之下，RUP比较适合大企业、大项目，因为大的团队往往需要法制；XP适合于小团队，比较能够发挥小团队的创造力。但是在实际中，也有例外的情况。例如XP方法的第一个项目就是克莱斯勒公司的一个名为C3的大型项目。

　　在现实中，RUP和XP应用于目前中国的软件企业都有一定的难度。有一些来信来问我，RUP真的适合中国的企业吗？我会直接告诉他们肯定不适合。对RUP这个庞然大物来说，很难去评定它的优和劣。关键在于它裁减以后的样子。我看到过一篇文章，是讨论如何将RUP裁减适合XP思想的方法的。所以RUP的使用要很小心。一个高明的铁匠用铁锤可能可以打出一把好兵器，如果是普通人搞不好就会砸到脚。

　　提升企业的内力值并不是一两天的事情，这需要长期的投入和锲而不舍的努力。大刀阔斧的引进一整套流程并不是不行，只是猛药伤身这个道理大家也应该懂得。很多年轻有为的软件界人士希望在自己公司中引入先进的开发理念，但是在真正实施时，往往会被碰得头破血流，也有这方面的原因存在。对他们，我是很佩服的。