敏捷方法在小型软件企业软件过程改进中的实践

张安勤　田秀霞　彭源

摘 要：CMM/CMMI是国际上主要采用的软件过程改进模型，但这些模型主要来源于大型软件企业的软件过程经验，在小型企业中实施起来存在一定困难。敏捷方法是一种“轻量型”的软件开发方法。在敏捷方法开发过程中围绕用户的需求，采用迭代的方法进行开发。本文结合一个小型企业的软件过程改进实践，采用敏捷开发方法和CMM/CMMI相结合的思路，经过两年在上海某小型软件企业的改革和实践，探索到了适合小型软件企业软件过程改进的方法和模型。

关键词：小规模软件企业；敏捷方法；迭代方法；软件过程改进

中图分类号：TP311.5-4 文献标识码：A

1 引言（Introduction）

能力成熟度模型CMM（Capability Maturity Model）及能力成熟度模型集成CMMI（Capability Maturity Model Integration）是国际上采用的软件过程改进模型，是被广泛应用于现代软件企业的过程改进和评估中的主要模型。目前，在实施软件过程改进的软件企业中，超过一半的企业采用了CMMI作为过程改进的指导模型。但是，CMM/CMMI的主要是根据大型软件企业的开发经验提出的，而我国软件企业中大多数是中小型企业。CMMI过于庞大和复杂，对于这些小型企业来说，实施起来存在诸多困难。

为了使开发团队具有高效工作和快速相应变化的能力，17位著名的软件专家提出了敏捷方法（Agile Method）。敏捷方法的主要强调：优秀的团队成员是项目获得成功的重要因素，可以工作的软件胜过面面俱到的文档，与客户的合作胜过与客户的谈判，相应变化胜过遵循计划。

敏捷方法是一系列“轻量型”的软件开发方法，是以快捷、轻便的思维方式面对各种变化的新软件工程思想的统称。

极限编程（eXtreme Programming，XP）是敏捷过程中最负盛名的一个，其名称“极限”二字的含义是指把好的开发实践运用到极致。极限编程有许多有效开发实践，这些实践都是前人经验的总结，我们选择了方便实现的客户参与、代码规范、代码集体所有等进行了尝试，在项目的开发中取得了较好的效果。

本人产学研所在的上海A公司是一个具有30多人的软件公司，之所以选择这样规模的公司，是因为这样的公司在国内具有代表性。而且现在鼓励学生自主创业，如何在学生创业初期给予一定的指导，并给出一些指导模型尤为重要。本文结合A公司的软件过程改进实践提出了一种结合敏捷方法的小型软件企业的软件过程改进的模型，在项目的开发的实际过程中取得了不错的效果，能给同类的企业提供一定的借鉴。

2 小规模企业软件过程管理现状（The present

situation of small scale enterprise software

process management）

2.1 小规模软件企业的特点[1]

我国的软件企业以中小企业为主，大多数是50人以下的小企业，这些小企业具有以下一些特点：

（1）员工的年龄比较年轻，但是却没有相应的培训计划。企业的领导认为员工的培训是一种浪费时间与金钱、没有回报的付出。

（2）小型软件企业员工用户需求变更频繁，人员流动大。

（3）小型软件企业的经营者缺乏有效的管理手段，业务负责人大多是计算机、软件和其他的相关专业，极少是管理专业，表现出人员的管理混乱，难以准确地掌握并控制产品及项目的开发成本。

2.2 小规模软件企业应对策略[2]

由于小型软件企业存在以上一些特点，导致了这些软件开发企业经常会遇到任务完成进度难以控制、项目延期，疲于应付需求的变更、软件版本混乱、软件质量难以保证、没有有效的项目管理方法和实践指导等问题，从而使得客户满意度降低。针对这些管理和与技术方面的问题，许多小型软件开发企业已开始在软件过程管理、软件过程改进方面采取一系列措施和手段。

3 敏捷方法使用中存在的误区（The misunderstanding

in the use of agile method）[3]

（1）敏捷方法没有文档，也不做设计

敏捷方法并不是所有的文档都不写，敏捷方法奉行的是“必要且意义重大的文档”才写。

敏捷遵循的是持续设计，并不是不设计。这实际上是将设计工作分到了每天的日常工作中，不断的设计、改善。敏捷方法不是不设计，而是更重视设计。

（2）敏捷好，其他方法不好

似乎敏捷和其他方法是完全对立的。事实上敏捷方法也吸取了其他方法论的优点，敏捷依然保持了很多历史悠久的实践和原则。

（3）敏捷就是XP，就是Scrum

XP和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。

即使将XP或Scrum完全的应用到项目中，也不一定就能成功，适合别的项目的方法未必就适合所有的项目。最适合的方式还要在实际工作中探索和寻找。

4 软件过程改进模型（Software process

improvement model）

在上海A公司的软件开发过程中，笔者所在的软件开发团队借鉴了RUP中的迭代式开发和敏捷方法中若干有效的实践方法，提出了一个结合敏捷方法的迭代的软件过程改进模型。具体措施如图1所示。

图1 基于敏捷方法的迭代的软件过程改进模型

Fig.1 The improved iterative software process model

based on agile method

4.1 重点突破[2]

软件过程改进是要在一定程度上改变软件企业现有的软件开发和管理过程，对于已经习惯了企业现有的工作方式的员工来说，大规模的改动不太容易被接受，也很难取得相应的效果。因此应该从企业当前存在问题的地方开始，重点突破。

软件开发过程中的需求、设计、编码等阶段，主要依赖于企业的技术实力和开发人员的能力，对于项目计划、软件测试、配置和质量保证则依赖于软件过程的改进和管理。

因此本文结合A软件公司的特点以项目计划、软件评审和测试、配置和质量保证几个方面作为软件过程改进的重点突破点。

（1）项目计划

项目计划是项目成功的前提，大部分项目的失败的原因都是不合理的计划或者计划执行不到位。

项目计划应从以下几方面进行：

①应对项目进行准确的项目估算。参考历史数据库中的规模数据或者估算者所能做的最好猜测，估算待开发产品的规模。

②资源估算，这里主要是指人力资源，主要单位是人月、人天或者是人时。由于软件工程师每个月能够提供的有效资源有很大差异，人月会带来额外的不确定性，因此建议使用人天和人时这样的单位来描述项目的人力资源需求。而且在项目执行时项目任务要充分并行，以提高人力资源的利用率。

③计划安排不能过于乐观，应留有一定余地，避免项目延期的情况。

④合理评估项目计划的变更，充分考虑到所有可能会受到影响的因素。

（2）软件评审和测试

为了尽可能地消除软件产品中的缺陷，在我们的软件过程改进模型中，采取了评审和测试两种方法来发现和消除缺陷。

本模型的软件评审和测试改进主要体现在以下方面：

①由于缺陷在开发过程中停留的越久，消除它的代价就越高，因此应尽早地消除缺陷。

②在软件测试计划中，引入个人评审和小组评审，有经验的评审者可以在产品进入测试之前发现，并消除80%左右的缺陷，这样大大提高了测试消除缺陷的效率。

本模型以测试驱动开发，并引入评审机制，评审和测试工作贯穿于整个软件开发过程。

（3）配置管理

配置管理的目的是建立和维护工作产品的完整性。本模型的配置管理措施如下：

①选择合适的配置管理软件。

②对软件版本进行统一管理。

③规范配置项变更控制流程，使整个开发和管理过程可以被追溯。

（4）质量管理

在小型软件企业中过于复杂的质量管理措施，往往不具有实用性，因此结合A公司的实际情况，本模型中采用了用缺陷管理代替质量管理，这样大大简化了质量管理的方法，使得质量管理更加易于操作。在质量管理过程中，以测试为驱动，结合软件评审方法，可以显著减少缺陷消除代价；而且质量人员就可以由评审和测试人员担任，能够减少人力成本。

4.2 个体软件过程改进[4]

开发人员的技术水平和个人能力对软件的质量起着决定性的作用。合格的软件工程师，应该自己度量、跟踪和管理自己的工作，应该自己管理软件的质量，应该从自己开发过程的偏差中学习总结，建立持续的自我改进机制。

个体软件过程改进的具体措施可以从时间管理、缺陷管理、规模度量和计划管理等几个方面着手，并以任务检查单作为辅助工具。

①对于时间管理，我们要求软件工程师先确定纯工作时间，再确定日程上需要多少天（周）可以提供这么多的纯工作时间。通过时间日志，个体软件工程师可以了解时间的消耗情况，了解自己的有效工作时间状态，从而更加有效地确定开发日程。

②缺陷管理要求工程师使用缺陷日志对各个阶段发现的缺陷进行记录。这些记录的缺陷信息可以很方便地统计出缺陷在整个开发阶段被引入和消除的状况，从而为提升过程质量、更加有效地消除缺陷提供了参考。

③规模度量方面我们采用了代码行作为度量的主要方式，并辅以功能点度量方式，从实际度量的效果来看，代码行这种规模度量方式可以更好地反映实际开发成本。

④任务检查单可以与计划管理和缺陷管理搭配使用，有利于个人工作任务的管理。

图2 PSP的训练框图

Fig.2 The train diagram of PSP

4.3 TSP与敏捷开发方法的结合[5]

软件开发在绝大多数情况下是团队作战，团队的有效性决定了产品的质量。TSP团队在软件项目开发过程中可运用。在A公司的软件开发实践中，我们结合了XP、RUP等敏捷方法，提高了软件开发的效率和质量，形成了有自己风格的软件开发过程模型。

（1）客户作为开发团队的成员

必须至少有一名客户代表在项目的整个开发周期中与开发人员一起紧密地配合工作，客户代表负责确定需求、回答开发人员的问题并且设计功能验收测试方案。

（2）每日站立会议

通过每天举行一次的“站立会议”，解决遇到的问题、调整迭代计划。在每天的会议中主要关注三个问题：昨天完成了什么，今天需要做什么，有什么困难。这种方法每天所花时间一般只有15分钟，但是效果非常好。既能促进项目组成员了解彼此的进展，获得项目的真实情况、增强团队的凝聚力、又能培养团队的文化。

（3）编码规范

开发团队结合以前的工作，并参考一些公开的编码规范，经过多次讨论和征求意见，制订了符合团队习惯的编码规范。这种方法可以很好地增强程序的可读性以及改善遗留系统可修改性。

（4）代码集体所有

程序代码属于整个开发小组集体所有，小组的每个成员都有更改代码的权利，每个成员都对全部代码的质量负责。在具体实践过程中，必须对代码更改的情况进行记录，包括修改人，修改时间，修改部分的修改前后的代码。因为小型软件企业的项目规模一般不大，开发团队人员较少，每个开发人员都要承担多种不同任务，实施“代码集体所有”并辅以“编码规范”，互相配合，修改代码会变得比较容易，项目的人员调配也比较灵活。

4.4 有效地评价机制

为了检验模型的效果，特设置了一个评分规则[1]，列出一系列评分指标及权重，并通过若干位小软件企业项目管理负责人和若干位专家进行评价。列出6个评分指标，每个指标的满分指为10分，这些指标如表1所示。

表1 评价指标表

Tab.1 The evaluation index table

评价指标 不及格（6分以下） 及格（6-7分） 良好（7-9分） 优秀（9-10分）

是否符合软件规格说明

是否完成客户提出的要求

是否易于软件工程师理解、使用和接受

每个过程是否能取得明确的结果以及是否对外可见

是否会出现过程错误

是否易受外界问题的影响

5 结论（Conclusion）

软件过程改进是一个循序渐进的过程，软件企业需要在不断的积累中持续改进。本文在A公司的过程改进实践基础之上定义了一个基于敏捷方法的迭代式的软件过程改进模型。A公司在实践这一模型时取得了如下的成效：

（1）项目组建立了规范的研发过程，使得项目开发有了可参照的过程标准[6]。

（2）能够比较准确地估算项目，在此基础上所做的项目计划比较合理，项目延期的情况有了较好地改善。

（3）以测试驱动开发，并引入评审机制，评审和测试工作贯穿于整个软件开发程，大大提高了软件的质量，受到了客户的好评。

（4）项目组成员养成了良好的配置管理习惯，使得软件版本混乱和难以查找的问题得到了很好的改善。

（5）充分重视新进员工的培训，在开发过程中严格进行规范的个体软件过程改进。

（6）项目开发中结合了XP、RUP等敏捷方法，提高了软件开发的效率和质量。

本人“产学研”项目所在的上海A公司是典型的小型软件企业，在该公司的软件开发和改进中提出的方法和过程可以供其他小型软件企业进行过程改进借鉴和参考。

参考文献（References）

[1] 马小龙.一种中小型软件企业软件过程改进框架研究[J].电脑

与电信，2010（10）：38-39.

[2] 楚书来，于文新.小规模软件企业软件过程管理与改进策略研

究[J].黑龙江科技信息，2012（2）：199-200.

[3] 对敏捷开发的五大误解.http：//www.searchsoa.com.cn/

showcontent_24633.htm.

[4] 徐玲，等.高校软件开发项目中的软件过程改进[J].计算机教

育，2012（24）：77-81.

[5] 隋立江.敏捷方法在软件开发过程中的实践[J].航空制造技

术，2011（10）：64-67.

[6] 田丽从，李铁牛，彭宏.中小型企业软件过程改进方法研究[J].

计算机应用与软件，2011（4）：208-211.

作者简介：

张安勤（1974-），女，博士生，副教授.研究领域：软件工程.

田秀霞（1976-），女，博士，教授.研究领域：信息安全.

彭 源（1981-），女，博士，副教授.研究领域：图像处理.