基于以上讨论，我建议，软件企业可根据自身的实际情况，以统一过程（如 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、敏捷统一过程方面的尝试，都欢迎 联系我们，与同行交流分享知识和经验，既帮助别人，也帮助自己！