1软件工程的诞生

在计算机发展初期，程序设计是少数聪明人干的事。他们的智力与技能超群，编写的程序既能控制计算机，又能让别人看不懂、不会用。那个时期编程就跟捏泥巴一样随心所欲，于是他们很过分地把程序的集合称为软件，以便自己开心或伤心时再把程序捏个面目全非。

人们就在这种美滋滋的感觉下热情地编程。日积月累，不知不觉产生了一堆问题：程序质量低下，错误频出，进度延误，费用剧增……这些问题统称为“软件危机”。

发生“软件危机”最突出的案例是IBM公司在1963年至1966年开发的IBM 360操作系统。该项目花了5000人/年的工作量，得到的结果却非常糟糕。据统计，这个操作系统的每个新版本都是从上个版本中找出上千个错误而修正后的 结果。该项目负责人Brooks在其1975年著作《The Mythical Man-Month》（人月神话）中这样描述：“……正像一群逃亡的野兽落到泥潭里作垂死挣扎，越挣扎陷得越深，最后无法逃脱灭顶之灾……谁也没有料到会 陷入如此的困境”。

在1968年，计算机科学家与工业界人士聚在一起共商对策。通过借鉴传统工业的成功做法，他们主张用工程化的方法开发软件以图解决软件危机，并冠以“软件 工程”这一术语。三十年余年来，尽管软件的一些毛病如人类的感冒一样无法根治，但软件的发展速度超过了任何传统工业，这的确是前辈们的先见之明。

1969年的NATO会议上给软件工程下了非常模糊的定义：软件工程是为了经济地获得可靠的和能在实际机器上高效率运行的软件而建立和使用的好的工程原则。看了这样的定义，几乎每个软件工程学者都忍不住要加点什么。

1993年的IEEE文献给出了更加综合的定义，软件工程是：（1）将系统化的、规范化的、可度量的方法应用于软件的开发、运行和维护的过程；（2）对上述方法的研究。

很难给出软件工程的完美定义，很多学科如数学、物理等都遇到类似的问题。对于应用者来说，大家只要理解软件工程的内涵就行了，不必在定义上纠缠。

不是说搞软件开发的人都很聪明吗，聪明人怎么会发生像“软件危机”所描述的那些问题呢？

至少有两个理由可以说明人们不得不采用软件工程方法来解决软件开发中存在的一些弊病，即“技术发展的需要”和“软件工业化生产的需要”。这与软件开发人员是否聪明没有太大的关系。

一、技术发展的需要

随着计算机应用领域的不断拓广，软件的规模与复杂性急剧膨胀。现代软件开发与早期的程序设计已经不是同一回事了，确切地说，编程只是软件开发过程中的一个环节而已。再聪明的程序员也不太可能独自把复杂软件系统的开发工作全部做完。

与我同龄的程序员们都能亲身感受到软件的发展速度。在20世纪90年代初期，我们去机房编程时，随身总是带着几张装有DOS操作系统、Turbo C、Turbo Pascal等开发工具的软盘。那时候感觉整个软件世界似乎就装在口袋里，自己是主人，编程的确很有成就感，甚至托着磁盘盒在校园里晃悠都有一股得意劲 儿。

到了90年代后期，PC机操作系统、开发工具都是上百兆字节的容量。过了2000年，PC操作系统的容量居然要用千兆字节（GB）来度量。尽管我们天天搞 开发，积累了不少经验，但总觉得懂得的越来越少，学都学不及。等我读完博士到大型电信企业工作，发现PC机应用软件的开发与电信领域的相比简直是小巫见大 巫。电信领域的某些产品线可能需要成百上千的开发人员，维护队伍也非常庞大。我所在的公司就有数千名研发人员，那些在学校里尚能自命不凡的编程高手一到企 业就被“开发大军”给淹没了。

如果把编程技术比作工匠的盖房技术，那么软件工程就可比作一整套建筑规范。一群会盖房子的能工巧匠并不能建造摩天大楼。同样，只懂得编程的人们远远不能胜 任大型软件系统的开发。我们需要包括需求分析、设计、编程、测试、维护在内的一整套方法与技术，即软件工程。

二、软件工业化生产的需要

很多国家纷纷把软件业列为支柱产业之一。为什么？归根结底是软件业的效益（包括经济效益和社会效益）远远高于其他行业。举个例子，如今农民和工人劳碌一年 的平均收入可能只有高级程序员一个月的工资，不用细比谁都知道哪个行业好。在当前的国际形势下，如果一个国家不发展信息产业（涵盖了软件业），那么它的经 济就无出头之日。据说日本前首相森喜郎在开大会时把IT（Information Technology的缩写）念成it，成为笑柄。但森喜郎知错就改，请了家教学电脑。不久后在西方八国首脑会议中，森喜郎谈IT比美国前总统克林顿还要 热切。

先看看硬件工业化生产的特征：用规范化的方法和技术，大批量地生产相同规格的硬件产品。

那么用生产线大批量地生产相同规格的软件产品算不算是软件的工业化生产？例如光盘制作。

当然不算。否则以我国盗版光盘制造业之发达，我们岂非早就成了软件大国！

软件工业化生产的特征应该是：用规范化的方法和技术，快速地开发出各种用途的软件产品。

可见实现“软件的工业化生产”绝不是靠某一项技术突破所能解决的。毫无疑问，软件业发达的国家一定是软件工程方法应用得很好的国家，如美国和印度。

由于美国的科技全面发达，反倒看不出软件工程有什么了不起的。而印度这样的第三世界国家竟然能成为全球排名第二的软件大国，不禁让人惊叹而又眼红，可见软件工程实在是功不可没。

2.软件工程模型介绍

在计算机发展初期，应用领域比较狭窄，通常侧重于科学计算。那时候软件开发几乎等同于程序设计，程序员们很少考虑需求分析和系统设计等工作。随着软件复杂 性的增加，开发人员不知不觉地陷入到“边做边改”的困境。“边做边改”的开发方式必然会导致质量低下、进度延误、成本高昂等问题。

人们意识到，若要把软件开发工作做好，必须有条理地安排需求分析、设计、编程、测试、维护等活动，于是产生了软件工程模型。

软件工程模型的研究兴起于20世纪70年代初，典型代表是1970年提出的瀑布模型。之后学术性的软件工程模型层出不穷，但是常用的模型并不多，本文主要介绍“瀑布模型”、“喷泉模型”、“增量模型”，“快速原型模型”、“螺旋模型”和“迭代模型”。

2.1 瀑布模型

瀑布模型最早由Winston Royce于1970年提出，如图8-1所示，尽管图中带有“回退箭头”，但人们通常把瀑布模型看成是严格线性的。顾名思义，瀑布是从上往下流的。给瀑布 模型加上“回退箭头”是为了学术上的完整性，谁也不希望在实施过程中出现“回退”，因为“回退”意味着“边做边改”。

瀑布模型的核心思想是将软件开发划分为若干阶段，按顺序执行。至于究竟要分多少阶段、各阶段做什么，应该根据实际情况来定。例如美国航空航天局（NASA）的一个软件工程研究机构（SEL）把开发过程划分为8个阶段，其瀑布模型如图8-2所示。

瀑布模型是最早的、最简单的软件工程模型，其应用也最广泛，它对软件业的发展无疑有很大的促进作用。然而瀑布模型在大量的实践中充分地暴露了缺点：

（1）瀑布模型是一种理想化的顺序模型，无法克服“变化”引发的问题。如果上一步做错了，下一步会继续错。如果直到产品做完了才发觉不是用户真正想要的软件，那就只好从头到尾重新修改

（2）开发人员常常陷入“阻塞状态”，如果前面某项工作卡住了，后面人员只好等待，人力资源的运用不合理。

2.2 喷泉模型

喷泉模型是一种“逐步求精”的软件工程模型，如图8-3所示。代表不同活动的“圆圈”相互重叠，没有严格的边界，这表示分析、设计、实现等活动是连续的、无缝的。“圆圈”之内的箭头则表示迭代、求精。

从宏观上看，喷泉模型中的各个活动仍然按照分析、设计、实现这样的顺序来执行。喷泉模型其实是瀑布模型的另一种表述，只是它的“重叠”与“迭代”特性比瀑布模型更加形象。

2.3 增量模型

增量模型由若干个开发序列构成，每个序列均采用瀑布模型来开发可以发行的“增量”，如图8-4所示。每个“增量”都是在原有软件基础上开发出来的，每产生一个“增量”相当于推出一个软件新版本。这个过程不断地重复，直到产生最终的完善的产品。

例如采用增量模型开发字处理软件，可以在第一个“增量”中实现基本的文件管理、文档编辑等功能，在第二个“增量”中实现拼写和语法检查功能，在第三个“增量”中实现高级的页面布局功能。

增量模型是多段的瀑布模型，如果项目比较复杂，就把它分成若干个版本来开发。由此带来的好处有：

（1）抗“变化”能力比瀑布模型强。

（2）每个“增量”实现后就可以交给用户使用，可以边开发、边使用。不像瀑布模型，必须等到全部工作做完了才可以使用。

采用增量模型的主要难点是，新开发的“增量”在合并入原有软件系统时，必须保证不破坏原来构造好了的东西。此外，现有的软件系统必须具备良好的可扩展性，加入新的“增量”的过程应当简便。做到这一点并不很容易，对系统设计师的水平要求颇高。

2.4 快速原型模型

在很多时候，需求分析人员无法仅仅通过与用户交谈就能获得明确的、详细的需求。如果匆匆地开发软件，无疑会冒很大的风险。但是又不能干等着，因为需求不会自动送上门来。

快 速原型模型应运而生，如图8-5所示，它的主要用途就是获取与验证需求。首先由开发人员构造原型，然后让用户体验该原型。一般地，当用户面对一个可操作的 软件原型时，他比较容易说清楚“需要什么”和“不要什么”。从而有助于分析人员获取更详细的需求以及验证需求是否正确。

原型内部结构及其实现细节并不重要，重要的是原型必须能被快速地构造出来，以迅速反映用户的需求。一旦需求明确了，原型就完成了使命，应该保留还是抛弃，就看此原型是否值得复用。最好的情况是原型与正式产品的框架完全吻合。这样，原型的开发既快又不浪费。

由于快速原型模型的主要目的是获取与验证需求，只采用该模型并不能开发出最终软件。快速原型模型通常与其他软件工程模型结合使用。例如可以先用快速原型模型确定用户真正的需求，然后采用瀑布模型进行正式的软件开发。

2.5 螺旋模型

产品开发过程存在很多风险，例如，在产品没有开发完成之前，一些关键人员已经辞职；产品开发所依赖的软硬件厂商可能倒闭了；新技术的诞生可能使目前正在开 发的“老”产品变得毫无价值。经验表明，项目规模越大、问题越复杂，那么资源、成本、进度等因素的不确定性就越大，风险也越高。

螺旋模型综合了瀑布模型、快速原型模型与风险分析，力求使项目的风险降到最低。该模型最初由Boehm于1988年提出，如图8-6所示。螺旋模型沿螺旋线演进，直角坐标系的4个象限分别代表4个方面的活动：

（1）制定计划：确定目标和约束条件，选择方案。

（2）风险分析：评估方案，发现并消除风险。

（3）实施工程：构造原型、开发产品。

（4）用户评估：评估开发工作，提出改进建议。

沿螺旋线自内向外每旋转一圈，意味着开发出更加完善的版本。

对于大型软件项目而言，采用螺旋模型比较适宜。开发者与用户能够很好地了解每个演化层的风险，继而采取有效的措施来降低风险。从理论上讲，螺旋模型比前面论述的其他模型都要完善，但在实际使用时并不一定是最好的。螺旋模型存在以下缺点：

（1）执行风险分析的费用较高，会大大降低项目的利润。一般地，只有大型项目才有必要多次进行风险分析，并且要有足够的经费 支持。

（2）使用该模型要求开发人员具备相当丰富的风险分析经验。如果项目实际上正走向灾难，而分析人员还认为一切良好，那么项目还是会失败。

（3）螺旋模型过于复杂，不及瀑布模型那么容易理解和使用。

2.6 迭代模型

RUP（Rational Unified Process）是Rational公司推出的软件开发过程模型，是软件业界迄今为止最完善的、商品化的开发过程模型。RUP的近千页文档可以从Rational公司的网站（http://www.rational. com）下载，RUP中文版也已经发布。

RUP的主要特征是：

1、采用迭代的、增量式的开发过程，如图8-7所示。

2、采用UML语言描述软件开发过程。

3、有众多功能强大的软件工具支撑（Rational公司的软件产品）。

UML是三位面向对象大师Jacobson、Booch、Rumbaugh提出的面向对象建模语言，1997年UML被国际对象管理组织（OMG）采纳为 国际标准。UML是独立于过程的，可以应用于任何开发过程模型。由于UML和RUP都是Rational公司的研究成果，两者有天然的联系。RUP的文档 里面充满了UML模型，需求建模、分析与设计、实现、测试等阶段的角色的主要工作都是用UML来描述的。与RUP配套的软件工具相当完备，例如面向对象分 析设计工具Rose、配置管理工具ClearCase、变更控制工具ClearQuest、需求管理工具ReQuisitePro、文档生成工具 SoDA、测试工具Purify，还有TeamTest/TestStudio等工具。

所以RUP不仅是一种先进的软件开发过程模型，更是一种完备的管理整个软件开发过程的解决方案，并且在商业上获得了成功。

不过RUP并不能解决中国广大IT企业的软件开发问题。RUP面向的是高端用户，对用户的财力、开发和管理能力要求都很高：

首先，用户得有钱买Rational的软件工具，否则只有RUP方法论如同纸上谈兵。Rational的软件工具都是非常昂贵的，例如配置管理工具几乎是 每个项目成员都要使用的，但ClearCase的每个License大约5000美元，这个费用相当于中国普通程序员一年的工资收入！如果要为所有项目配 齐Rational软件工具，那么估计中国普通的IT企业就承受不起了。

开发人员应当熟悉面向对象方法和UML，否则除了RUP模型图之外你基本上看不懂细节内容。

项目经理要有能力控制迭代过程，否则迭代式开发就变得混乱无序和漫无边际。可是国内很多项目经理连瀑布式开发过程都控制不住，他们怎么能够管理好迭代过程呢？

国内软件开发人员学习UML、使用Rose的劲头很足，相关书籍和网站也越来越多，造成了一派红火的景象。但是完整采用RUP的企业则非常少。毕竟个人行 为比企业行为的代价低得多。业内人士认为，在国内推广RUP的难度如同向农民推广机器人，东西是很好，但是用不起啊！

2.7 从企业应用角度评论软件工程模型

企业在选择或制定软件工程模型时，不要太在乎学术上的“先进”与“落后”，正如有才华的人并不一定要出自名牌大学或拥有高学历那样。关键是看该模型能否有 效地帮助企业顺利地开发出软件产品，并且要考虑员工们使用起来是否方便。简而言之，就是考察模型是否“好用”。

最早出现的软件工程模型是瀑布模型。它太理想化、太单纯，看起来已经落后于现代的软件开发模式。瀑布模型几乎被学术界抛弃，偶而被人提起，都属于被贬对象，未留一丝惋惜。贬低它，为的是说明新模型是怎样怎样地好。

然而企业界不同于学术界，我认为瀑布模型对企业太有价值了，应当恢复它应有的名誉。几乎所有的开发模型都能够找到瀑布模型的影子，例如增量模型实质就是分段的瀑布模型。

让我们引用爱因斯坦的名言来指导软件开发：任何事物都应该尽可能地简洁。瀑布模型是如此的简洁，所有的软件开发人员很快就能学会。所以瀑布模型非常适合于企业，请大家别轻易贬低它。

我在这里宣扬瀑布模型的好处，并不是要让大家呆板地套用它。而是希望大家能深刻领会瀑布模型的思想，在实践中活用它。企业在开发产品时，应当根据产品的特 征来确定开发模型。如果没有现成的模型和规范可以套用，那么就自己制定。我本人倡导“以瀑布模型为主线，局部采用并行迭代方式”的软件开发模型。

3 软件过程改进的概念

3.1 为何要重视软件过程改进

在20世纪七八十年代，软件工程的研究重点是需求分析、软件设计、编程、测试、维护等领域的方法、技术和工具，我们称之为传统软件工程。

现代的软件技术、软件工具要比几十年前好不知道多少倍，可是如今绝大多数软件项目依然面临着质量低下、进度延误、成本超支等这些老问题。人们逐渐意识到， 由于企业管理整个软件过程（包括开发过程、管理过程、支持过程等）的能力比较弱，常常导致项目处于混乱状态。
过程混乱使得新技术、新工具的优势难以体现，传统的软件工程不是不好，而是不够用。

提高软件过程能力的实践统称为软件过程改进（Software Process Improvement）。软件过程改进的最终目的是：提高软件质量、提高生产率并且降低开发成本。从20世纪90年代至今，软件过程改进成为软件工程学 科的主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。

3.2 什么是过程？为什么要重视过程

一、什么是过程

人们使用合适的方法、技术、工具才能开发出用户需要的产品。过程是指“人员、方法、技术和工具”的集合，如图8-8所示。
过程被写成文档后，变成了企业的“流程制度”，人们依据“流程制度”开展工作，这叫“法治”。

二、过程与产品有什么关系

软件产品不能靠人们的意念瞬间完成，它需要比较长的开发过程。一般情况下，好的过程才可能得到好的产品，而差的过程会得到差的产品。

当然也有相反的情况，有些人在混乱的过程中创造了很好的产品，也有些人在严谨的过程中研发出商业上失败的产品。但这类现象不具有指导意义，本书不作讨论。

三、为什么要重视过程

由于公司销售的是产品而非过程，人们常常只把眼光盯在产品上，而忘了过程的重要性。例如，领导对员工们下达命令时经常强调：“我不管你们怎么做，只要时间一到你们交付产品就行。”其实这是一句因果关系颠倒了的话，却在业界普遍存在。

下面的故事给出了警示：如果领导不关心员工怎么做（即做事的过程），往往会得到失望的结果。

公司领导对项目经理小王说：这个软件项目对公司和客户都很重要，你们要好好干，在6个月之内完成，要让客户满意。6个月后我来看你们的成果，为你们庆功。

每个月末，领导照例打电话问小王：“项目进展怎么样了？”

小王每次答曰：“挺好。”

6个月后，领导兴冲冲地问小王：“项目完成了吧，可以交付给客户了吧？”

小王说：“还有一点东西没有完成，再给我们一个月时间，肯定能够完成。”

7个月后，小王说：“出了一些小意外，我们正在解决之中，我保证下个月完成。”

8个月后，小王说：“我们正在修改某些功能，还需要一个月。”

9个月后，小王说：“我们正在完善某些功能，还需要一个月。”

领导和小王日益焦虑……

12个月后，项目终于完成了。领导喜气洋洋地请客户来验收软件，大家都做好了庆功的准备。

客户看了软件后，大吃一惊：“这不是我们想要的东西！”

在12月里，公司和客户都不关心该项目的过程，都不知道软件是怎样开发的，不知道软件做成什么模样了，都等着看最后的结果。结果是，进度延误了6个月，终于开发完成了不符合客户需求的软件。项目团队疲惫不堪，公司和客户损失惨重。

所以，人们既要关注结果，又要重视过程。

3.3 什么是过程改进？为什么需要过程改进

过程改进（Process Improvement）是指：根据企业的现实情况和发展需求，优化流程制度，努力提升人们在过程中的工作能力，从而提升产品质量、提升生产率并降低成本。

“过程改进”本身就是一件消耗时间、精力和成本的事情，那么企业为什么要做“过程改进”？

答案是：过程改进是企业谋求进步的需要。

企业谋求进步离不开以下两点：（1）企业人士要不断学习新技术，开发新产品，开拓新业务领域。（2）企业人士要不断反省自己，总结经验教训，改正缺点、发挥优点。后者就是“过程改进”的体现。

过程改进体现了“自我反省、自我改进”的精神，不论对人生还是对企业而言，都是极为重要的。

4.CMM/CMMI介绍

4.1 CMM/CMMI的诞生

1981年，美国卡内基梅隆大学软件工程研究所（SEI）应美国联邦政府的要求开发了一种用于评价软件承包商能力，并帮助其改善质量的方法。Watts Humphrey将成熟度框架带到了SEI并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，它提供了评估软件开发过程 能力的一种标准。

1987年，基于Watts Humphrey 等人的工作，SEI的Mark Pauk 等人建立了第一个CMM（Capability Maturity Model，能力成熟度模型），即软件CMM。1993年，SEI推出了CMM 1.1。

之后十几年来CMM的改进工作一直不断地进行着，相继有多个学科领域的CMM模型问世，如SE-CMM、SW-CMM、IPD-CMM等。美国国防采购与 技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架，即CMMI（Capability Maturity Model Integration，能力成熟度模型集成）。

CMMI的基础源模型包括：软件CMM 2.0版本、EIA-731系统工程，以及IPD CMM （IPD）。2002年1月CMMI 1.1版本正式发布，立即被广泛采用。

2006年8月，面向开发的CMMI（CMMI-DEV 1.2）版本正式发布，如图8-9所示。为了适应更加广泛的应用，SEI计划今后发布另外二种模型，分别是面向服务的CMMI（CMMI-SVC 1.2）和面向采购的CMMI（CMMI-ACQ 1.2）。本书论述的CMMI是CMMI-DEV 1.2。

4.2 CMMI的5个等级和22个过程域

CMMI将能力成熟度分为5个级别：初始级、已管理级、已定义级、量化管理级和优化级。

这5个成熟度等级为评价软件过程能力提供了一个有序的级别，如图8-10所示。同时也为软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。

除 了成熟度等级，CMMI还有一个重要的概念是过程域（Process Area）。过程域指出了达到某个成熟度等级必须要解决的一族问题。除了初始级以外，每个成熟度等级都有若干个过程域，如表8-1所示。由于成熟度等级是 循序渐进的，如果想达到某个成熟度等级，例如CMMI 3级，除了满足CMMI 3级本身11过程域之外，还要满足CMMI 2级的7个过程域，依此类推。

4.3 CMM/CMMI和软件过程改进有什么关系

从20世纪90年代至今，软件过程改进成为软件工程学科的主流研究方向，其中CMM/CMMI是该领域举世瞩目的重大成果。CMM/CMMI是世界范围内用于衡量软件过程能力的标准。

人们往往搞不清楚“软件过程改进”和“CMMI等级评估”之间的关系，经常混为一谈。这里作个比喻来解释：

把“软件过程改进”比喻为“学英语，提高英语能力”，那么“CMMI等级评估”就好比是“英语等级考试”。一般情况下，英语等级考试的成绩反映了英语能 力。但是，在特别擅长应试的中国，英语考试成绩很好并不见得英语能力很好，甚至差到“哑巴英语”的程度。这种“特性”传染到软件领域，不少企业虽然通过了 高级别的CMMI等级评估，但是其实际的软件过程能力却非常低下。

软件过程改进的真正目的是提高企业的软件过程能力，而不是为了达到CMMI高等级，切勿本末颠倒。

4.4 有了CMMI为什么还要研制软件过程规范

CMMI 1.2厚达560页，既然有了全世界认同的“CMMI宝典”，企业为什么还要研制自己的软件过程规范呢？

为了解答这个疑问，我们首先要搞清楚“CMMI是什么”以及“CMMI不是什么”。

CMMI是世界范围内用于衡量软件过程能力的标准，但是CMMI不是软件过程改进的执行标准，世上根本不存在适合所有企业的执行标准。

就如“英语四六级考试”是中国所有大学都认同的大学生英语能力的评估标准，但是“英语四六级考试指南”绝对不是“学好英语的执行标准”。

不能把“CMMI宝典”直接作为企业的软件过程规范，主要原因如下：

CMMI的560页文本论述了二十多个过程域和数百条实践，但是这些“过程域和实践”没有与“企业的具体业务和组织结构”衔接起来，所以没法直接使用。

有些企业死搬硬套CMMI，竟然按照CMMI文本逐个遍历CMMI的所有过程域和实践，这种方式非常迂腐可笑。就像给一个病人治病，不考虑病人需要吃什么药，却把药店里面的药逐个儿吃一遍，以为就能治好病。

4.5 如何应用CMMI

既然不能全盘套用CMMI文本，那么究竟该如何应用CMMI？

应当根据企业的实际情况，既要裁剪CMMI过程域和实践，又要补充CMMI没有涉及的过程域和实践。

企业领导和软件过程改进工作者必须明白：企业需要吻合商业目标、容易执行的软件过程规范。

什么是裁剪？

裁剪不是指用剪刀把CMMI厚厚的书剪成薄薄的书，裁剪是要动脑筋的：要分析企业的业务特征，根据自身的人力和财力，选取CMMI文本中一些重要的东西，舍弃其他不重要的东西。至于什么是“重要的东西”，则要根据它对企业的贡献多少来衡量。

CMMI有560页厚了，为什么还要补充过程域和实践？

CMMI对于软件开发过程和项目管理过程的论述非常深入，但是却没有涉及“商务活动”，例如没有谈营销和服务等。

企业开发产品的最终目的是卖出产品，赚取利润。如果软件过程规范中不考虑商务活动，那么会导致开发团队“闭门造车”，很可能开发出“技术上很好的产品，但却是商业上失败的产品”。

5 敏捷开发理念介绍

2001年，为了解决许多公司的软件团队陷入不断扩大的过程泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟（Agile Alliance）。

他们起草了一个旨在鼓励更好的软件开发方法的宣言，称为敏捷联盟宣言（The Manifesto of the Agile Alliance），如表8-2所示。然后在该宣言基础上制定了12条原则用于指导实践。该宣言和12条原则是敏捷软件开发方法的核心。

敏捷软件开发的12条原则如下：

（1） 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。

（2） 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

（3） 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

（4） 在整个项目开发期间，业务人员和开发人员需天天都在一起工作。

（5） 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

（6） 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

（7） 可以工作的软件是首要的进度度量标准。

（8） 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

（9） 不断地关注优秀的技能和好的设计会增强敏捷能力。

（10） 简单——把无需做的工作最大化的艺术——是最根本的。

（11） 最好的构架、需求和设计出于自我组织的团队。

（12） 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

我对敏捷开发的看法：

我认为“宣言”中的左右4项都很重要，但是不能绝对地说左边4项“胜过”右边4项，这是“一刀切”的结论，没有考虑成千上万个企业的具体情况。

敏捷软件开发宣言和12条原则并非普遍适用。其中（2）、（4）、（5）项看似很好，但是不符合中国软件机构的普遍现状，几乎行不通。我个人比较赞同的是（1）、（3）、（6）、（7）、（12）项。

敏捷开发方法表达了“简单、快速、实用”的软件开发思想，它不是成熟的理论、也不是事实上的标准（不像CMM、PMBOK那样具有严密的理论体系，被企业广泛接受）。即使人们认同某些原则，但是不同的人往往有不同的理解，实践差异很大。

敏捷开发方法对于提高个人、小型团队的工作效率是很有帮助的（如果用对了的话）。但是企图用它指导大型、中型软件机构的研发管理是有很高风险的，它的某些 主张是局部观点而不是全局观点，如果把握不好分寸的话可能导致整体混乱，而“整体的混乱”会淹没“局部的好处”。

企业若采用敏捷开发理念来精简流程，为了避免过度简化而导致混乱，至少要做到以下几点：

（1）流程具备最少的必要步骤；

（2）流程具备最少的必要角色；

（3）每个角色写尽可能少的必要文档；

（4）项目关键点的进度和质量必须受控。

6.软件过程改进的实施建议

6.1 过程改进的目的和基本措施

过程改进的目的是：优化流程制度，努力提升人们在过程中的工作能力，从而“提升产品质量，提升生产率并降低成本”。
基本措施包括：

（1）如果某个领域还没有流程制度，那么先要制定流程制度，防止流程制度缺失而产生隐患。

（2）对于已经存在的流程制度，要定期审查是否合适企业的实际情况，如果流程有缺陷，则要及时改进，要随着企业的发展而优化流程制度。

（3）有了合适的流程制度之后，要对员工们进行培训，让大家都知道流程制度并且遵循之。

（4）要不断地帮助员工们提升工作能力，如果能力不足，再好的流程也执行不好。

6.2 各级领导亲身参与而非口头支持

我曾多次看到这样的现象：咨询师给企业员工培训流程制度的时候，各级经理总有各种理由不参加培训。当真正在项目中推行新的流程制度的时候，各级经理自己却不懂，仍然按照他原先不合理的方式去管理，让下属不知所措。

各级经理的主要职责是“带领团队完成目标”，他们要“亲身参与”过程改进，才能深刻体会过程的要点，掌握相应的方法技能。“亲身参与”体现在：参与分析问题，商议对策；参与制定和自己工作相关的过程规范；参与评审；参加培训学习等。

6.3 制定合适而非大而全的过程规范

大凡第一次从事过程改进的人员，他们总是希望制定“大而全”的流程制度，企图覆盖企业中的所有事务。

2000至2001年，我带领6名研究人员在上海贝尔公司一个软件事业部（约150人）从事过程改进工作，一年时间不知不觉写了长达千页的软件过程规范和相关指南。我花了九牛二虎之力去培训推广，最终还是没有用起来。

我们走了很大的弯路，反省后发现，缺乏经验只是一个原因，而“贪大求全”才是最大的失败原因。站在用户角度想想也是，那么厚的过程规范，人都看晕过去了，怎么能够地很好执行呢！

从2002年至今，我一直不断地创作、改进“集成化软件研发流程”（详见第6章），从最初冗长的1000多页精练到100页之内，才能够在IT企业中广泛应用。所以“合适”比“大而全”更重要。

6.4 不要迷信所谓的标准

CMM/CMMI、PMBOK、ISO9000等标准都是用来参考的，而不是用来“迷信”的。我发现当人们崇拜CMM/CMMI时，他的思想意识就不知不觉地被CMM/CMMI控制了，这是非常有害的。

2000年之后，国内软件业界兴起CMM/CMMI等级评估热潮。很多软件过程改进人员把CMM/CMMI当圣经看待，完全对照CMM/CMMI文本来操作，都不敢想一想是否合理。

其实软件企业即使不采用CMM/CMMI，也是有可能把软件研发做得很好的，例如Microsoft、Google并不采用CMMI，它们有自己的研发管理方法。互联网公司的软件研发人员最喜欢嘲笑“笨重”的CMMI，有例为证：

某互联网公司的领导夜里经常做恶梦，老梦见竞争对手超过自己。有一天，他梦见一个过了CMMI 5级的公司在做总动员，要和本公司竞争，于是他在梦中笑醒了。

企业采用业界推荐的标准时，要舍弃那些听起来很先进，但是对本企业无益处的东西，只选取对企业有实用价值的东西。

6.5 引导推行而非强硬推行

作者曾经询问某公司领导：“在推广流程制度的时候遇到阻力怎么办？”

该领导回答很干脆：“强制执行，不按流程执行者要处罚。”

这种答复“说得容易，做起来难”。在中国自古就存在“上有政策，下有对策”之说，在推行流程制度时，不仅要预防员工们应付了事，还要引导员工们正确地做事情。

举个例子说，计划生育是一项基本国策，它在实施之初遇到了强大的阻力。有一些人暴力对抗，很多人东躲西藏（形成了超生游击队）。怎么办？惩罚违抗者是一种 不得已的措施。更好的方法是对全国人民进行教育宣传，例如农村的墙上到处都是“只生一个好”，这么多年下来，成绩斐然。如今计划生育已经深得民心了，很少 发生对抗。

企业制定流程制度是为了帮助员工们把工作做得更好，而不是存心与人们过不去。企业要设法使员工们乐于执行，从而避免流于形式。
以下是作者总结的“引导推行”的建议：

一、解释流程制度

过程改进者不要只是埋头写流程制度，写完了上缴了事。最好在企业内部网上开辟一个专栏，专门解释流程制度。流程制度不是数学定理，可谓“智者见智，笨者见 笨”。如果不对流程制度作解释，员工们就不理解“为什么”，如果不理解“为什么”，怎么能够很好地执行呢？

不少公司都有名目繁多的规章制度，很多条款用了“必须”的语气。有些内容会损害不少人的利益，但为了顾全大局不得已这样做，如果不解释清楚原因，可能会招致本来可以避免的埋怨或对抗。

解释流程制度还会带来间接的好处：不合理之处会很快被发现（因为解释不通）。

二、培训和考试

要对全员进行培训与考试，使企业中的每个人都熟悉与自己工作相关的过程规范。只有这样才能防止一些人拖后退，使团队发挥最大的力量。

企业里的各级经理往往派下属参加培训，而自己则以工作忙为理由回避培训。我曾经给一个软件事业部做了大力度的培训，几乎所有干活的人都参加培训和考试了 （连行政秘书都没放过），但是漏掉了几个经理。结果“当兵的”至少都知道到哪里下载流程制度，知道讲些什么东西。但是那几个“当官的”却浑然不知，依旧我 行我素，带头起破坏作用。所以，领导亲自参与培训和考试要比口头支持有意义得多。

三、质量保证人员监督实施

人都有惰性，如果没有人来监督员工们按照流程制度办事，那么自觉性不强的员工就会回到“无序”的老路上。

CMMI把质量保证称为“过程与产品质量保证”。质量保证人员的主要职责就是周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的过程规范。

几乎所有的老百姓都明白基本的交通法规，可是明知故犯的人仍然不少，所以社会需要很多交通警察。质量保证人员的工作性质有点像交通警察。

6.6 写好必要的文档

企业应用CMM/CMMI之后，通常会要求开发团队写不少文档。据说CMM/CMMI等级和文档有这样的关系：

你们对所做的事情有文档记载吗？如果有，好，达到了CMM 2级。

你们对所做的事情的文档有文档记载吗？如果有，很好，达到了CMM 3级。

你们对所做的事情的文档的文档有文档记载吗？如果有，非常好，达到了CMM 4级……

很多管理者有这样的感受，在推广流程制度时，员工们抱怨最多的就是“要写的文档太多了”！甚至很多人把进度延误归罪于写文档。
人们抱怨“文档太多了”，有两种原因：

一是过程规范的确很臃肿，规定了太多不必要的文档，如果是这种情况，那么应该精简过程规范，减少文档数量。

二是要求写的文档本身是合适的，但是人们以前写文档太少了，一下子不习惯写文档。现代人早晚各刷一次牙，我们觉得很正常。可是古代人不刷牙，如果你要求古代人早晚各刷一次牙，他们肯定觉得太麻烦了。

企业应该想办法降低写文档的难度，帮助员工们提高写文档的效率：

一要下功夫制定出良好的文档模板，给出充足的提示和示例。这样使用者就可以“依葫芦画瓢”，总比他自己琢磨怎样写要方便得多。

二要督促开发人员经常写文档，才会熟能生巧。