摘要 随着软件行业的发展，软件企业对软件开发的一致性、高效、低成本、高质量提出了更高要求。本文从软件企业开展过程改进的关键干系人—高层管理者角度出发，分析和提出如何推动过程改进的一些观念和见解。本文是笔者《软件企业过程改进开展》系列文章之一，后续将会从工具支撑、团队实施等角度尝试分析。

关键词 软件过程改进 SPI CMM/CMMI PMBOK ISO9000 度量

1 引言

软件企业在发展到一定阶段时，对软件开发质量、进度和成本会有越来越高的要求，于是软件过程改SPI （Software Process improvement）进成为必然。我国引进过程改进已经多年，包括CMM/CMMI体系、ISO和欧洲一些模型标准的推广等。20世纪90年代初，我国开始引进国际流行的质量管理标准ISO 9000。20世纪90年代末，软件界又开始逐渐把注意力转向了CMM，越来越多的软件企业开始注意软件过程改进SPI。与此同时，以提升项目管理能力为目标的美国项目管理知识体系PMBOK也引入中国。在这些标准、体系引领下，有的企业在质量和过程方面取得显著成效，有的则不够理想，甚至有的没有什么成效，拿到个证书也只是做做样子，用于装扮自己的企业。

为什么会有这样大的差别呢？关键在于企业或组织如何改进自己的过程。无论是借助标准或模型还是自我内部需要，企业需要结合自己的实际，找到可行的方法和途径。这里面涉及公司高级管理层的支持、人力和物力（如工具）的投入、团队实施等一系列问题，只有解决了这些问题过程改进的开展才可能有成效。
进一步说，众多软件企业对如何制定软件过程改进策略？过程改进需要哪些基础支持？过程改进如何开展？等问题并不很清楚，也没有达成某种程度上的共识。这样，过程改进多趋于形式化，进而无法有效开展。

2 软件过程改进开展概述

过程（Process）是为实现既定目标的一系列操作步骤[IEEE-STD-610]。那么，软件过程（Software Process）则是指人们用于开发和维护软件及其相关产品的一系列活动、方法、时间和革新。

软件过程涉及软件工程和软件管理两类，工程类的主要过程域：需求开发、系统设计、软件实现、软件测试、软件维护等等；管理类的主要过程域：项目规划、项目监控、需求管理、质量管理、配置管理等等。

2.1 软件过程改进策略

通常，软件过程改进有自上向下和自底向上两种模式，前者是基于标准的，由标准来规范实践；后者是基于实践的，由组织中待解决问题出发，选择和裁减标准。

对于大、中、小软件企业而言，采取的软件过程改进策略不一样，关键看是否符合自身的实际情况。中小企业的实际情况是：管理基础薄弱，资源不足，生存压力大，缺乏统一而有力的文化，人员素质良莠不齐；而大型企业相反。大型软件企业自上而下的模式比较容易推动，对于中小型软件企业在没有正式评估的压力情况下，采用自底向上模式更合适。

以下是针对中小软件企业的一系列具体的过程改进策略[1]。

策略一：两个方针

重诊断，轻评估以诊断和解决企业实际问题为SPI方法论，不追求商业评估。

策略二：两手抓

实施制度化的同时，并行实施企业文化；既要施压，又要清障。

中小企业往往制度化体系很不健全，存在着随意决策的管理习惯，甚至基本的企业纪律都不具备，企业还处于人治和法制的争论中，这样的状态和某些大企业实施SPI的状况是不同的，需要特别强调行政施压。由于缺乏统一的企业文化，所以理念的统一也要加以重视。

策略三：推行两种工具

要推行配置管理工具和项目管理工具这两种工具，工具将有效分解事务性工作，从而缓解人力资源投入不足的矛盾。

策略四：补两门基础课

为了解决基础薄弱的问题，需要在SPI前期为企业补基础管理和基本软件工程两门课。

软件企业需要补的基础管理内容包括：基本时间管理、角色转变、目标管理、沟通管理、基本人力资源管理等。基本软件工程则包括基本的软件工程生命周期、阶段划分、基本文档编制等。

策略五：发动三方参与

一是高于项目管理的层面，称为高层经理。他们提供资源和战略两方面的支持，所以高层经理应该对体系总体架构、体系实施必要性、可行性、障碍和风险、资源等负有责任。

二是项目管理层面，含项目经理和SPI人员。SPI人员作为制度化体系的执行者和推行者应该加强自身修养，要求别人的事，一定要自己能做到。而项目经理作为主要的一线实施人员，需要对整个体系的细节有深入了解和研究，应该把日常工作时间的30%～50%放在工程化管理相关事宜上，要贯彻公司的SPI整体制度，积极主动在项目组内进行推行。

三是项目组成员，包括开发和测试人员，要求团队以纪律性要求自己，做好局部和整体、短期和长期的矛盾平衡。

2.2 软件过程改进开展的基础支持

软件过程改进SPI是变革管理的一种，凡是变革管理都需要进行干系人分析，包括企业的高级管理层、部门管理、项目经理、项目成员、客户等几部分。软件企业在确定适合自身的实施策略后，需要这些利益相关人的支持，特别是高层管理者的支持。

同时，所谓巧妇难为无米之炊，软件过程改进需要一定的人力、物力的投入，包括设立EPG组织、专职SPI人员、专门的工具等。通常SPI专职人员的比例应该占公司研发团队总数的3~5%；过程数据的采集和分析需要工具的支撑，要考虑是外部购买还是自我开发支撑工具。这些都涉及一些投入成本。

企业有了以上这些基本支持，软件过程改进才能有保障。

2.3 软件过程改进开展的团队实施

确定了适合软件企业自身软件过程改进的策略，获得了高层管理等干系人的支持，有了一定专门的人力和物力投入，那么软件过程改进的实施关键就剩下在组织团队中推广了。推广的步骤，参考如下[2]：

步骤1 – 准备项目列表

识别所有当前正在运行的项目

识别项目状态

步骤2 – 识别要开展流程的项目

识别项目中需要导入的过程

识别项目中需要开展的过程

步骤3 – 准备导入或开展流程的计划(包括项目)

项目成员的角色和职责

从项目团队中获取支持

召集会议并说明角色和职责

步骤4 – 提供支持

SEPG应该辅助项目组填写模板

SEPG应该注意解决过程的疑问

SEPG应该为实践者所遇到的的问题提供可行的解决方案

SEPG应该对所开展的过程有积极的评论

步骤5 – 收集反馈意见&进行改进

每日召集项目成员开项目会议（15分钟左右）

收集反馈意见和所面临的问题

在每天的SEPG会议上进行讨论

识别解决方案来合并反馈

当过程需要变化时进行过程改进

步骤6 – 提供培训

解释为什么过程发生了变化？

给实践者提供详细的过程培训

过程输入

过程步骤

过程输出

解释需要使用的模板

步骤7 – 在组织范围内推行

在组织范围内推行过程

SEPG在开展过程期间要给予支持

重复开展步骤4中的活动

步骤8 – 准备开展总结报告

SEPG准备推广总结报告以提供每周的过程开展状况

步骤9 – 提交给SEPG负责人

SEPG要走查过程中的每一个模板，应该理解过程，理解过程输入，过程步骤；理解模板中应该纳入什么内容,理解何种信息需要被纳入及应该如何被纳入。

3 SPI与高层管理者支持

如果软件企业简单制定软件过程改进策略后草率推进，我们可以想象：在SPI状态评估会上，通常只有密切参与SPI实施的部门总工持坚定的支持态度，市场总监担心客户的抱怨，副总则探询SPI能给我们带来什么好处？SPI主管发现，他不得不在SPI已进展到一半的时候回答一系列最基本的问题：为什么要实施SPI？SPI能给各方面带来什么好处？这些好处何时见效……

其实，分析其抗拒原因主要有三条：

一、不了解目标，感到迷茫，从而产生恐惧，为不了解；

二、损害了既得利益，为不愿意；

三、与原来的做事方式有差异，不知道怎么做，为不会做。

如何解决这些问题？首先，要获得高层管理者的全面认可和支持，一把手的态度往往决定SPI的有效性；其次，对过程改进中的其他干系人进行分析、培训和指导，让他们没有过多顾虑。

3.1 高层管理者抵触软件过程改进的原因分析

国内众多软件企业是在互联网蓬勃发展时代下成立发展，这造就了一些软件企业领导相对年轻。他们对市场敏感，对客户需求理解清楚，但在软件产品开发规律等方面的理解相对乐观，对开发团队能力提升、提高成熟度等方面缺乏认识。

还有部分企业领导人，他们是改革开发的先驱者，他们年长、有能力、在财富积累上也先人一步，转行进入软件行业，他们对过程改进等新事物的理解相对保守。

软件企业领导由于以上的自身背景原因，或者在自下而上过程改进实施过程中，沟通不畅，不能深刻理解EPG组成员提出的意见和建议，从而缺乏领导的全面有力支持。或者对于自上而下实施改进的企业，企业领导人的初衷更多是为了过级、过认证。一旦过程改进实施涉及到大量的工作和来自项目经理的部分反对声音时，生存、进度等压力就会战胜提升企业内部能力提升的过程改进。

从而，使得改进失去最主要的推动力。

3.2 如何得到高层管理者的支持

3.2.1 让领导系统了解过程改进好处

要让领导们进一步理解SPI的优势。虽然每个软件企业由于自身情况的不一样，但绝大多数的软件企业可以把软件改进目标与商业目标结合在一起，这样高层管理者会看到SPI带来的收益。

通常，软件企业的商业目标有：

• 提高软件产品和项目的质量，降低缺陷率
• 提高客户满意度，减少客户投诉
• 降低软件开发成本
• 提高软件开发进度，减少延期交付产品的情况
• 提升企业知名度，增加企业市场竞争力

可以看出，上述商业目标实际上是相互影响的，在实施过程改进开始的时候，不要把目标定得过高过大，只要把过程改进认真落实，并且保持着组织中对于过程改进的焦点和关注，经过一段时间后，势必会在上述这些方面获益。

3.2.2 制订合理的软件过程改进组织方针

可以这样制定公司SPI组织方针，让领导从形式上承诺支持，比如：

1、公司的EPG组作为软件过程制定和优化的专业小组在公司长期存在。

2、 EPG组长是由公司任命并直接向公司高层管理负责。

3、公司高层管理者全力支持、相关部门全力配合EPG组的各项工作，共同建立高质量的过程标准。

4、 软件过程改进要结合市场特点和项目特点，具有可操纵性。

5、切实推行已定义的过程标准，提高软件质量，加强公司在软件市场的竞争力，为进行大型软件开发打下基础。

3.2.3 软件过程改项目管理化

软件过程改进也可以看作一系列项目，不同阶段制定不同的目标，通过不断的项目达成让领导切实看到效果。用一句形象的表达，高层管理者通常是不见兔子不撒鹰的。只有上一个目标达成了，高层管理者才会无顾虑的进行下一轮的过程改进。

因此，过程改进项目管理化，针对每个阶段的目标设定一些里程碑milestone，在每个里程碑总结汇报。

里程碑（基线、基点）则是一个软件配置项在生存周期内的某一特定时刻正式设计并固定的静正式批准的版本，不管媒体如何，它是阶段性目标（可以认为是一个中间产品）。配置项是一个配置中的实体它满足一项最终使用功能，并能在给定的参考点上单独标识。里程碑应该是团队阶段性工作完成的标志，对于任何一个里程碑都应该给于认真的检查、审定和批准。一般里程碑应该少于两个月，多于三个星期，里程碑给团队带来成就感，提高士气。

软件项目通常必须含有的里程碑为：

里程碑1：调研 标准输出：调研报告

里程碑2：需求分析 标准输出：需求规格说明书、结构设计报告

里程碑3：数据分析 标准输出：数据字典

里程碑4：概要设计 标准输出：概要设计报告

里程碑5：详细设计 标准输出：详细设计报告

里程碑6：编码 标准输出：各配置项编码、测试报告、产品文档

里程碑7：发布 标准输出：用户使用报告、产品文档、总结报告

一个SPI项目开展，通常至少可以设置5个里程碑[4]：

3.2.3.1 里程碑1：体系诊断

标准输出：诊断报告，通常的方式为面谈、文档查阅、检查表填写等形式。

3.2.3.2 里程碑2：方案设计

标准输出：SPI解决方案

体系诊断评审结束后，策划组要对评审结果进行分析，筛选出一些改进点；然后将每个改进点都作为一个改进项目，分别制定改进方案。

SPI方案应该包括以下内容：

• 本组织软件过程改进的历史
• 过程诊断
  • 诊断方法
  • 诊断结果和差距分析
• 改进方案
  • 总体目标
  • 总体工程化管理系统设计
  • 详细改进措施
• 预期收益
• 实施负责人
• 对成本、资源和项目周期的估计
• 计划进度概要
  • 前提和承诺
  • 资源需求预测
• 风险
• 子里程碑

方案中还应该说明建议使用的实施方法，例如是否进行试用等。估计成本时要包括：过程定义的时间、试用期间人员培训的成本、处理反馈意见的时间和重新试用的成本。同时，可以基于CMM/CMMI、SEBOK（软件工程）、good practice (最佳实践)、PMBook、ISO等模型和标准设计，也可以融合设计SPI方案。

因为所有的改进工作不可能一次实施，所以要确定各个改进项目的优先级。我们怎么确定改进活动的优先级呢？主要是通过考察三方面的因素，即：对商业目标的影响、风险和在过程改进模型标准中的定位（如CMM/CMMI）。

有些公司还会对各方案进行成本/收益分析（例如，考察投资回报率），但是1级或2级的企业往往没有充分的历史数据，因此无法准确估计过程改进的无形收益；4级和5级的企业通常就能作到这一点，3级的企业也有可能作到。

1、对商业目标的影响

对商业目标的影响是指某项改进工作对总体的战略目标的影响。

首先，策划小组要和主管的高层经理进行讨论，明确公司商业目标、并分析确定决定商业目标能否实现的5-7个关键成功因素（CSFs）。如果公司没有明确成文的商业目标，小组的首要工作就是确定商业目标；如果商业目标已经非常清楚、明确，并且形成了文档，策划小组的核心工作就是分析关键成功因素并每个关键成功因素确定权重。

接下来，我们要对每项改进活动进行分析，按其对每个关键成功因素的贡献进行评分，然后将结果进行加权平均，作为最后比较的一个依据。

2、风险因素

风险是指实施改进工作的困难程度，我们要考虑实施某项改进是象赌博一样冒险么？结果是不是有一定的可预测性呢？通常，风险的来源主要有三个方面：项目的规模、结构的问题和技术。

项目规模风险，是指实施的人工成本，一般人工成本越低风险越小。

结构方面的风险，主要有以下因素：参与该项目开发的功能组的数量、项目的复杂程度、制定解决方案的人员在该过程域的经验是否丰富、对改进中带来变更，预期存在抵触行为等。

技术风险，这里就不分析了。

3、过程改进模型标准中的定位

如果企业有认证过级的目标，那么需要结合起来考虑。

3.2.3.3 里程碑3：项目策划

标准输出：SPI项目计划

如果我们把软件过程改进看作一个项目，象其他项目一样，它也要有一个好的计划，这个计划不但要满足公司的商业目标，还要包含过程改进战略和具体的实施步骤（子项目）。软件过程改进非一日之功，急于求成必将导致失败；因此，如果不进行系统的战略策划而盲目进行过程改进，只会浪费时间和资金而不会取得好的效果。有了有效的战略计划，我们才能在这项长期的活动中获得管理人员、开发人员和公司的所有者的理解和耐心的支持。

• 项目目标
  • 整体目标
  • 本阶段目标
• 假定和约束
• 项目组织
  • 组织结构
  • 接口关系
  • 报告关系
  • 责任矩阵
• 项目进度跟踪方式
• 项目里程碑
• 交付物
  • 文档编制
  • 人员培训
• 风险管理
• 项目激励
• 项目验收

3.2.3.4 里程碑4：过程管理

标准输出：定期的过程管理度量数据报告

计划制定好以后，还要对 SPI的的实施过程进行定期和不定期的过程跟踪，才能确保及时纠正和预防计划执行中的偏差，最终达成项目的成功。

一般可通过“周”和“子里程碑”两种定期进行跟踪，周跟踪的内容为进度、完成量、问题、风险，通过周报和周会的形式进行；子里程碑跟踪的内容为进度、工作量、人力开销、风险等，还要对项目管理的经验和教训进行总结。里程碑也是识别典型案例和收集最佳实践的良好时机。里程碑跟踪活动通常包括“里程碑总结报告编制”和“里程碑总结会”两种形式。

3.2.3.5 里程碑5：项目验收总结

标准输出：SPI数据报告、软件项目SPI工作产品、总结报告

3.3 引导领导对SPI的客观认识

在让高层管理者对软件过程改进对企业带来好处的同时，还需要让他们客观认识软件过程改进的客观规律，包括投入和持续改进的思想。

3.3.1 让领导知道过程改进的基本投入

软件企业的过程改进，一方面要高级管理层知道SPI是需要投入的，包括人力（专职和兼职SPI人员）和物力投入（资金、工具等）；另一方面要他们认识到，SPI会要求他们改变以往的粗放管理方式。同时，不能短时间对SPI结果期望。

对大多数的国内中小软件企业来说，都是在求生存中求发展，因此，企业很难在人力、物力和财力上有足够的投入来进行革命性的质量改进。因此，企业需要结合本企业的实际情况和可能的投入，确定每阶段质量改进的重点并各个击破，这样不但可以在较短的时间内收到明显的效果，而且不会让公司投入过大而对后续工作改进供血不足，有利于形成良性循环。

对于高层管理者来说，需要正确认识过程改进带来的额外工作量，配备必要的资源。比如，会增加一些的事务性管理工作，这要求设立一些专职的角色，如SEPG组人员、SQA、SCM等，配备适当的度量、跟踪工具。

3.3.2 让领导知道过程改进对现有团队的暂时影响

过程改进会增加一些的事务性管理工作，这些工作会影响项目经理的管理精力，同时会规范项目团队的行为引起一定的阵痛。只有把相应的工作量从项目经理的身上分离出来，才能切实在项目中展开软件过程改进。否则，一旦技术和管理展开竞争，牺牲的肯定是管理。这一点高层管理者必须要清楚。

过程改进会修改已有的规范制度平衡体系，建立新平衡，这个过程中体系会有短时间的“混乱”，可能会对正在运行的项目会产生一定的影响。甚至于在个别企业中，出现技术人员由于适应不了新的工作方式而离职的例子。

同时，高层管理有必要改变自己的管理习惯，原来很多事都口头裁决，现在需要依据规范执行。带头榜样的做用是无穷大的。

这些情况，高层管理者都应该心理上有所准备，对过程改进抱有坚定的信心。

3.4 如何动用高层管理者深入开展SPI

3.4.1 高层管理者是SPI的资源

有时候我们认为得到高层管理者对SPI的支持是一件比较难的事情，甚至有时候会有息事宁人的想法。其实，高层管理者是SPI开展很好的资源。在得到高层管理者对SPI的支持后，他们会提供资源和战略两方面的支持，他们对体系总体架构、体系实施必要性、可行性、障碍和风险、资源等负有责任。也就是说他们是SPI项目的sponsor！

SPI开展过程中，SPI人员会有两类常见的看法：

一种认为员工都是自觉的，只要把道理讲清楚了，制度就能得到实施。但这种假定是不现实的，如同法律，如果假设人们都是遵纪守法的，那么法律本身就没必要存在了。实际情况是，人们在组织中总是有区分的，有的人主动顺应变革，有的人推一推也能动，有的人可能推十下也不动，从而成为变革的障碍。所以变革的落实需要一个强的推力。

另外一个观点刚好相反，认为没必要对员工讲为什么，只要告诉怎样做就行了。这又走到另外一个极端，体系在强力的推动下可能会暂时得到执行，但是由于并没有解决观念转变的问题，一定难以持久。

针对这两种意见，高层管理者恰恰可以为SPI提供强有力帮助：一方面利用高层管理者强有力的行政权利，可以有效推动SPI活动的进行；另一方面，利用高层的感召力，通过宣传SPI对企业商业目标的帮助和对个人利益的提升，可以有效激发员工的自主改进热情。

3.4.2 高层管理者是SPI的客户

SPI是一个持续的过程，时间一长高层管理者对SPI可能会失去关注焦点。同时，高层管理者在经营管理方面占用了大量精力，对SPI的细节数据没有时间或者没有能力去认真分析。

为此，SPI人员特别注意：高层管理者是SPI的重要客户。对于客户，提高满意度是关键。要让客户物有所值感，又要让客户清楚自己的投入做了些什么。这样，就很清楚了，SPI人员可以采取如下措施：

1、定期总结，简化汇报：有重点的开展SPI工作，将收效和问题及时总结汇报

2、考虑设定一些指数，让高层管理人通过指数直观了解SPI开展情况

比如，质量指数、进度指数，PMBook强调的挣值管理就是一个好的方法。也可以，将所有信息汇总为一个参数。比如，高层管理更关心质量，那么将所有的行为对质量的影响归一为一个质量指数进行汇报；关心成本，那么可以将所有的行为归一为成本指标。这里可能会有很多工作要在下面做足。

4 总结与展望

软件过程改进是企业高效率、高质量和低成本地开发软件的必经之路。其中，软件过程改进至关重要的一点是需要企业高级领导的重视和大力支持。此外，如何制定SPI策略、如何投入SPI人力物力、如何在项目团队中开展SPI等问题也是制约SPI实施的关键因素。

5 参考文献

[1]《软件过程改进实践》，北京SPIN，2004.1

[2] 个人博客，龚云卿

[3]《Exposure Draft Practice Standard For EVM 4-04》，美国项目管理协会 (PMI)

[4] 《以项目形式管理SPI》，雅行，计算机世界网，2002

[5]《软件项目管理中的三要素控制研究》，淦未宇，徐细雄，2006

[6]《对软件企业质量管理标准的探讨》，葛晓斌，2003.10

[7]《项目管理度量模型及其基础度量元的研究》，张红彦，相慧如，2006