一、过程成熟度与多样性
近年来软件过程改进在国内日益得到重视，一度出现了许多组织纷纷开展 SW-CMM 商业评估的热潮。迄今全国已有近两百家软件企业通过了 SW-CMM、CMMI 各级评估（1 2 3）。这一方面说明原本作为美国军方标准（如今已成为全球通行的国际标准）的 SW-CMM、CMMI 并非高不可攀，另一方面也说明加强软件开发规范化管理、提高过程成熟度已经得到了业界的广泛认同。
与此同时，国际软件界的“敏捷热”、“统一热”也在持续升温。上世纪 90年代以DSDM、Scrum、FDD、Crystal、ASD、XP为代表的轻型软件开发方法逐渐兴起，其中又以XP对传统的“反叛”最为显著，它凭借与传统思维相悖的“极端”做法既获得了许多软件客户、管理者和开发人员的积极拥护，也遭到了传统过程维护者的激烈反驳。2001年2月敏捷联盟成立以及《敏捷软件开发宣言》的发表，标志着这场“敏捷运动”达到了一个高峰。而作为吸收了电信、国防等关键行业以及IBM、HP、Microsoft等多家国际著名软件企业过程经验的商用过程产品，统一过程RUP也在全球取得了广泛的成功。某著名咨询机构 2002 年对全球200位软件相关行业IS/IT经理进行的调查表明：RUP使用率达到了51%，远高于SW-CMM（27%）和ISO 9000（26%）；而且到2003年, 大约50%的被调查者预计其50%以上的项目会使用敏捷方法，14%的被调查者认为其所有的项目会使用敏捷方法 [2] 。
承认软件过程的多样性与追求其成熟度一样重要。“ One size does not fit all ”，事实证明不存在一成不变地适合于所有项目的过程模板。由于软件过程的周境不同（如业务、资源、团队、文化），层次不同（如组织过程、项目过程、团队过程、个体过程），开发类型不同（如新产品、重用、服务、产品线），一时间出现这么多过程方法论并不足怪。
二、过程方法论对比分析
那么，敏捷、统一过程有哪些特点，与传统过程有什么不同呢？下面我们以 SW-CMM 为参照，挑选 3 个最典型的过程方法论（ XP 、 RUP 和 TSP ）作对比分析。
SW-CMM是一套用来评估软件组织过程成熟度的基准，阐明组织为了系统地实施软件过程改进、提高过程成熟度应该做些什么，但没有规定如何去做。它的目标通常适用于所有的软件组织或项目，用来实现目标的大部分关键做法也适合中小企业项目，而许多关键做法中的子做法主要目的是举例说明如何在大型政府、国防合同项目中实现总目标，对中小企业项目仅有参考价值。除了对过程的集成性关注不够，SW-CMM的主要缺点还在于缺少了现代软件过程的一些重要元素，其KPA主要集中在传统过程的静态文档上（如设计、需求文档，合同、计划和报告等），只有很少数的KPA强调了演进式工件（如需求、设计模型，源代码等）、开发环境的自动化水平以及基于架构的过程。 [6]
为了尽早通过评估，人们往往采用或模仿同样是由SEI开发的PSP/TSP过程。建立在PSP之上的TSP可能是迄今为止最为严格的重型过程。为了提高过程的成熟度和可预测性，TSP强调对过程进行全面精确的度量，这依赖于制作大量复杂繁琐的数据表格和文档以及固定程式化流程配合，因而培训、实施的成本很高。
RUP是一个以用例驱动、构件式架构、迭代递增式开发为基本特征，可广泛地应用于各种类型和规模项目的软件过程框架，它的基本特征与需求管理、配置变更管理、OOAD*UML可视化建模、持续检验质量等做法一起集中体现了现代软件开发的最佳实践。RUP定义了起始、细化、构造、移交4个阶段和业务建模、需求、分析设计、实现、测试、部署、配置变更管理、项目管理、环境等9个工种。阶段对应着主里程碑的划分，不同工种的工作流活动在生命周期的迭代中并发进行，具体执行强度可以按需调节，角色、活动和工件也是灵活可配置的。由于RUP提供了极其丰富的内容，所以常被误解为一个重型过程。通过定制RUP通用框架，针对具体项目去掉不必要的元素并吸收其他敏捷方法，完全可以定制出敏捷轻型的RUP过程（如RUP的XP插件）。
极限编程 XP具有强沟通、简化设计、迅速反馈等特点，一般只适合于规模小、进度紧、需求不稳定、开发小项目的小团队。在其12种做法中，测试为先、持续集成、简化设计、代码规范、现场客户、每周40小时工作制、小型发布等早已有之，并不是新的发明，但XP通过巧妙整合把它们发挥到了极致。而代码集体拥有、结对编程、重构、系统隐喻、计划游戏等做法并不是在任何情况下都适用的，使用不当往往会起到相反效果。SW-CMM与XP是互补的，Barry Boehm、Watts Humphrey等权威更认为XP与SW-CMM是哲理相容的 [5] 。主要区别在于，后者更关注过程实施在组织管理上的问题，而XP侧重于具体的过程执行和开发技术，不含有被SW-CMM认为是使良好的工程和管理实践制度化的关键基础设施。
许多团队在一定条件下实践 XP可能会收到意想不到的好效果，但纯而又纯的XP的适用面可能也很小。克莱斯勒公司的C3薪资系统项目恐怕是引用次数最多的XP成功案例，但实际上该项目后期还是由于开发团队与管理者之间的沟通出现问题而遇到了麻烦。一个经典的XP项目偏偏在其核心的沟通要素上出现问题，的确值得人们深思。 [7]
XP以代码为中心，编码和设计活动融为一体，弱化了架构，这是它与以架构为中心的RUP的最大不同，而且它没有业务建模、部署、过程管理等概念。两者也有不少共同点：它们都采用OO技术（取代传统结构化方法）、演进式迭代周期（取代传统瀑布模型），强调风险驱动，以保障可用产品的持续性交付为前提，尽量减少不必要的过程工件，使度量、文档最小化以获得弹性和应变能力。由于RUP、XP结合了具体的开发方法，因此比TSP具有更好的可操作性。
敏捷、统一过程满足了 SW-CMM绝大部分目标及2、3级KPA的要求，对4、5级KPA基本没有涉及。然而，服从类似SW-CMM这样高质量的过程框架，并不一定会开发出高质量的产品，生产出高质量产品的真正高质量的过程却理应被评估为成熟的过程 [6] 。事实上，国际上不少采用RUP的组织已经达到或超过了SW-CMM 3级的水准。通过SW-CMM评估要求组织在过程制度化建设上付出大量复杂、高成本的努力，但过程改进的有效性与复杂性、高成本之间没有必然联系。过程选择的多样性和SW-CMM目标的通用性决定了过程改进途径的多样化。
三、我们的对策
针对国内软件过程改进的现实，我们应该采取什么对策？本文试图提出一种初步的解决方案。
1. 选择正确的生命周期模型
首先，选择一个合适的生命周期模型对于任何软件项目的成功都是至关重要的。大量项目严重拖延、产品迟迟不能交付，究其根本原因往往是与错误运用了存在明显缺陷的瀑布模型有关，所以现代过程方法论，不论轻型、重型， XP、RUP或TSP，无一例外地都推荐、主张采用能显著减少风险的迭代演进式生命周期模型。早在1994年美国国防部就作出了一个重大决定，用新的软件开发标准MIL-STD-498取代旧标准DoD-STD-2167A，而在498所要解决的20个关键问题中就包括：去除隐含的对瀑布型开发过程的偏好，改进与递增演进式开发方法的兼容性以及改进与Ada等其他OO方法的兼容性 [8] 。这一态度的明显转变为我们提供了重要信息。
然而，由于种种原因，上世纪 70年代提出的瀑布模型多年来一直被我们的软件工程教育奉为经典来传授。而在实践中，我们采用的许多生命周期模型却不伦不类地介乎瀑布模型和正确的迭代模型之间，毫无规律性可言，从而为软件开发的成功埋下了严重隐患。应该说这是一个历史性错误，可惜国内许多客户和开发商对该问题的重要性长期没有引起足够的重视，美国人已经为此付出了惨痛的代价，却不知道我们有多少人现在还蒙在鼓里，愿意继续支付学费。
迭代是 OO开发的本性（Grady Booch）。正确做到迭代开发远比字面理解要难得多。世界领先的软件组织其项目迭代开发周期往往呈现图1的形态，每个迭代开发的内容、速度和质量都很稳定，这也是RUP、XP团队所能达到的理想状态（参见《软件架构》节奏原则一章 [3] ）。如果度量我们许多组织的开发工作，结果可能都会表现为类似图2的形状：迭代速度不均，每次交付的内容忽多忽少，而且往往迫于外部压力而牺牲质量。时常见到，开发人员加班随意而频繁，问题却始终层出不穷，进度也总是无法保证。可悲的是类似的现象屡见不鲜，反而让我们认为开发节奏紊乱是一种正常态。
2. 适度度量
CMM/PSP/TSP度量体现的是一切用数字和文档说话。企业要转变粗放式管理，提高效益，就应该注意对度量数据和实践经验的积累。有了历史与今天的对比，才谈得上明天的进步。另一方面，SEI开发CMM/PSP/TSP的主要目的就是为了评估美国军用软件承包商的过程能力。在巨额国防经费的驱动下，显然保证软件的可靠性和质量、过程可预测可度量往往是军用软件项目应该满足的首要目标，甚至可以为之不惜代价，提高生产率和降低成本则在其次。PSP/TSP基于历史统计数据的收集分析对过程进行预测、管理、控制、评估和改进，这必然需要长期积累，而大量样本、数据的收集、维护相对成本很高，如果没有自动化工具支持、严格的纪律保障和在基础设施上大量投入，全面度量的实效将难以保证。这种度量强度适合于组织内外环境和需求相对稳定，综合实力强、开发生命关键或可靠性要求高的大中型软件组织，以及那些需要对过程能力作出客观预测和评价的大型工程、异地外包项目。
图 3 、 TSP 周期 [4]
任何过程的成熟度都应该以最终交付产品 /服务的质量和ROI为最高评判标准。在民用商业软件开发环境中，及时推出满足客户和市场需求、适用的产品是第1位的，速度常常比尽善尽美更为重要。因此，RUP、XP与倡导统计过程控制的PSP/TSP在度量的范围和强度上有着较大差别，但这不意味着RUP、XP不需要度量，不能在敏捷、统一过程的框架中引入必要的度量机制。度量产品本身与度量开发产品的过程有所不同（如图3）。在测试水平还较低、质量保证相对薄弱的国内软件组织中，加强产品度量也尤其重要。我们不应为了追求过程成熟度而使度量面面俱到，应该在敏捷思想的指导下实现适度（按需）度量。
3. 建立 AUPF
是否一定要采用类似 XP那样极限的做法项目才能取得成功？答案显然是否定的。实施过程改进以达到SW-CMM目标，是否只有走PSP/TSP一条道路呢？相信答案也是否定的。组织一旦选定某种过程方法论，就在所有项目上一成不变地照搬执行，排斥其他方法，是不明智的。Alistair Cockburn指出，“不同的项目需要不同的方法论，一个项目的最佳过程是这个项目所能负担的最小过程”，选择过程的原则：1）越大的团体需要越大的方法论；2）越关键的系统在构建的正确性方面需要越多的透明度/更大的密度；3）在方法论体积或密度上相对小的增加会导致项目成本相对大的增长；4）最有效的沟通方式是面对面的互动。
图 4 、软件过程计划谱系
Barry Boehm根据几种过程模型计划性的强弱，描绘了它们在计划谱系中的相对位置 [1] 。可以看到，里程碑风险驱动的RUP位于最极端的敏捷过程XP和里程碑计划驱动的TSP之间。Mark Paulk建议，“应该在组织业务环境中恰当的地方仔细考虑采纳敏捷运动的想法。” [5] CMM、XP是互补的，RUP可以和PSP、 XP集成，XP、ASD与Scrum也天然地相吻合，这些事实都说明重型、轻型过程方法论之间并不存在根本性的矛盾冲突。把这些互补方法论拼在一起，恰好可以发现整个软件过程体系全貌的一部分，可能这就是事物复杂性的原本反映吧。
基于以上讨论，我建议，软件企业可根据自身的实际情况，以统一过程（如 RUP）为基础建立起符合ISO 9001、SW-CMM 和CMMI SE/SW等基准的组织软件过程体系，同时包含敏捷过程（如XP、Scrum）和重型过程（如TSP）等内容。我把这种混合/集成过程体系叫做“敏捷统一过程框架”（Agile Unified Process Framework，AUPF）。这就像饭店的厨师准备了丰盛的自助餐，吃些什么，吃多吃少，按照什么顺序来吃，企业的各个项目团队应该独立作出最恰当的选择。
AUPF为什么不以XP或TSP为基础？首先，尽管XP有敏捷高效等好处，但它很容易被误解误用。现阶段，国内过程管理和软件工程水平还比较低。迫于固定工期和预算的压力，客户和开发商往往只重视编码，轻视/忽视需求分析、计划估算、架构设计、文档编写、有效测试以及良好的开发文化和制度，指望减少前期投入通过事后重构来改进软件，可是重构一旦失败造成的损失往往更大。架构设计正是复杂项目成功的关键，AUPF参照以架构为中心的RUP，通过构造出稳定可靠的架构原型可以为适应需求变化奠定稳固的基础。
其次，针对许多管理者、开发者在提高开发效率、改进软件质量方面应该做些什么、如何去做尚感到千头万绪、束手无策的局面，与大踏步跨越到重型的 PSP/TSP相比，从在短期内相对更容易取得成效的敏捷、统一过程入手，可能更符合国内大部分企业的实际。
企业实施 AUPF，应抛弃旧有的不规范的软件过程，做到适度度量，采用正确的生命周期模型和敏捷、统一过程的最佳实践，并根据实情对个别做法进行调整或舍弃。即使组织已有的过程很成功，也可以借鉴吸收AUPF方法以加强过程的敏捷性。能否让大型复杂软件的开发过程敏捷起来呢？任何大系统、大组织都是由小系统、小团队组成的，所以应该也可以把敏捷方法运用到大项目的子系统子模块的开发中。例如，在起始和细化阶段采用RUP完成需求和架构基线，在构造阶段采用XP实现某个模块。
TRW公司于1987-1994年间为美国空军开发的导弹预警和地面指挥控制系统CCPDS-R是历史上非常著名的、融合统一过程（该项目所采用的过程方法后来形成了RUP的一个主要来源）和敏捷思想的成功范例。该获奖项目的规模为75人、6年、100多万行Ada代码，采用了类似RUP 4个阶段的迭代递增、架构优先过程。它不仅按进度和预算交付了大型关键任务系统，而且还使用户获得了超出预想的功能，在生产率和质量方面取得了2倍的增长。 [1][6]
在整个项目过程中， CCPDS-R承受了大量需求的变化，甚至包括开发后期的一个合同范围变更。同等程度的需求变化扼杀了大部分采用传统管理方法的项目，而CCPDS-R却由于采用了风险管理、设计阶段架构的不断集成以及基于演示的评审方法，有效控制和稳定了变更成本，取得了超乎寻常的成功。CCPDS-R在注重个人互动、可用的软件、客户协作和响应变化等方面都做得非常出色，可以说完全实现了敏捷价值观和目标。（10年前！）
4. 提高组织和个人的软件工程基础技能，全面提升竞争力
过程能力并不是保障成功的惟一因素，影响产品 /项目质量的关键因素还包括开发技能和组织管理（图5），这三者相辅相成、缺一不可。一味地强调提高过程成熟度而忽视组织建设、提高技能，对企业的短期成功和长期健康的全面发展都是不利的。
图 5 、软件质量改进3要素
过程就像武术套路，开发技能就像内功。如果功力不到，招数学得再多再好，也不过是花拳绣腿，摆摆样子。反之，如果功力达到一定程度，就可以运用自如，无招胜有招。许多敏捷、统一过程的发起者、倡导者如 Ivar Jacobson、Kent Beck、Robert Martin、Martin Fowler等人都是全球最著名的OO大师，他们既是令人敬佩的软件思想家，能够不断推陈出新引领软件开发潮流，又是具有丰厚积淀的程序员之优秀表率，达到了真正高手的境界。
与 OO方法紧密结合的敏捷统一过程要求开发人员具备更高的专业素质。XP要求开发团队具备熟练的OO编码、测试和重构等技能，RUP也对OO需求分析、架构设计提出了较高要求。没有真正理解OO范式与传统结构化方法的本质区别，缺乏OO技能，敏捷统一过程恐怕就玩不转了。
由于历史发展和自身局限等原因，应该承认，我们与北美、欧洲的项目经理、架构师、程序员的能力竞争是不在一个层次上的竞争。我们的软件企业和个人，无论在过程能力，还是在技术技能、管理素养上都与国际先进水平存在着明显差距。如果对此不加以重视，老是抱残守缺、自欺欺人，沾沾自喜、不求进取，这些差距还有可能进一步拉大。
5. 弘扬敏捷文化
“敏捷”的意思大概有：轻巧、机敏、迅捷、灵活、高效、活力 …… 轻载——让编程之外的一切工作减到最少的办法——并不能等同于敏捷（当然，组织在重载的情况下也很难做到敏捷）。
我想，实现敏捷过程的真正含义应该是：以满足客户需要、创造客户价值为首要目标，使企业的软件过程容易洞察、适应市场、竞争、技术、需求等内外环境的变化，对此能够迅速做出反应、自我调优和完善，并且在保证产品和服务质量的前提下，对交付内容、速度和资源做出正确的权衡，从而实现企业、员工、客户和社会等多方利益的最大化。
因此，敏捷作为一种快速响应变化、客户 /受益人利益至上的文化，应该是一切现代商业组织的生存手段和终极目标。事实上，上世纪90年代国内制造业就早已开始学习国外敏捷制造、并行工程的先进经验了。RUP迭代递增的开发方式实质上就是一种软件开发的并行工程。历史再一次给了软件行业学习借鉴他人优秀经验的大好机会。
敏捷文化是企业的核心文化。 AUPF的成功实施离不开高度协同的开发文化和良好的人文环境。以人为本的敏捷价值观——注重个人及互动胜于过程和工具、注重可用的软件胜于详尽的文档、注重客户协作胜于合同谈判、注重响应变化胜于恪守计划——正是对刻板僵化的传统过程文化的有力反叛！我们应该在现代软件企业管理中大力提倡和培育敏捷文化，加强多方沟通与信任, 强调领导—协作而非命令—控制，尽量发挥每位员工的潜能和主观能动性；同时，还应该防止把敏捷统一过程奉为新的教条，重蹈官僚形式主义的老路。
四、结语
学习、模仿、运用流行的过程方法论是实施过程改进的好办法。 TSP、RUP、XP这三种互补模型的目标对象和适用环境各不相同，在理解其精神实质和基本原理的基础上灵活运用，整合其最佳元素，我们就可能设计出适合自己的过程体系。相比其他方法，RUP处于能屈能伸的有利位置，具有更广泛的适用性。我们相信，以敏捷思想为指导，在统一过程RUP基础上集成其他重型过程和敏捷方法，建立敏捷统一过程框架AUPF，将是我国软件企业尤其中小企业实施持续过程改进的最有效途径之一。
上世纪 90年代初曾经出现几十种OO方法繁荣竞技的局面，最终OMG UML完成了OO建模语言的统一大业，如今软件过程建模的统一标准（OMG SPEM）业已诞生。可以大胆预测，随着人们的经验愈来愈丰富，不久的将来在进一步达成共识的基础上，全球将会出现占据主导地位的软件过程统一新标准。
成功的过程改进始终离不开专业判断和常识理解，软件组织应综合根据应用类型、项目特点和组织文化等诸多因素确定自己的道路，不能人云亦云、盲目跟风。如何把握好各个因素的平衡是软件工程实践的永恒话题。现阶段我们应当着重提升软件组织的整体竞争力，尤其要加强基础软件工程的实力，注意选择正确的生命周期模型，适度度量，不可偏废开发技能、软件过程和组织管理任一方面。
度量数据和经验积累的匮乏一直是我们发展道路上的羁绊。业界总是喜欢强调特殊国情，然而具有中国特色的软件过程发展模式同样需要事实和数据来证明。不管您的企业在过程改进方面已取得成功，还是正在计划或已经开展了CMM/CMMI、敏捷统一过程方面的尝试，都欢迎 联系我们，与同行交流分享知识和经验，既帮助别人，也帮助自己！
