软件过程改进：经验和教训

软件过程改进：经验和教训

前言：

2001我开始慢慢关注起软件工程和CMM，也对CMM进行了学习。并且对其中的一些KPA在自己单位中进行了试验。可是一开始这些试验的结果并不令人愉快，甚至遭到了抵制和反对。开发和测试人员认为降低了开发速度和灵活性，加大了工作量，工作流程太烦琐。而质量的提高也不是一时可以反映出来的。于是在进行了2个小项目的试验后，我被迫停止了CMM在公司的实施。

因为公司并不从事外包服务，所以CMM对其没有生存的压力。高层也只是想通过一个可行的过程管理，一个提高软件质量，保证项目进度，有效控制项目成本。所以公司并不是要去过CMM等级，而是要一个有效的过程管理。

所以我此后开始以‘有效、简易、可行、低成本’为标准探索起适合起我们公司的过程改进的最佳实际。现在，我很高兴可以在文中和大家探讨我公司在过程改进过程中的一些经验和教训，也许你会从中得到一些启发，开发出适合你自己的最佳实际。

经验和教训：

在中小型的软件企业当中，软件过程的改进更容易半途而废

中小企业，特别是开发人员小于40个人的企业。一般不会有专门的人员可以组建‘软件过程组’，也很少会有专职的质量工程师和配置工程师。在进行过程改进中，对于这些职位基本上都是由原来的人员兼职完成。这无形中增加了人员的工作量。一旦过程定义的不是太完善，或是在试点中不是太成功。很容易让人去怀疑过程改进本身的可行性。同时中小企业接到的项目也比较小，成本压力是比较大的，而提高质量是必须以牺牲成本为代价的。所以有时从成本的角度出发，可能在高层管理人员的心目中，对于过程改进也是有成本的顾虑的，一方面希望，可以通过过程改进提供质量，并为企业的发展提供基础，另一方面，也面临成本压力，若过程是改进了，可是成本也大幅度提高了，则本事企业的生存就成问题了。

而在大的软件企业，一般可以有专职的人员进行质量保证和过程改进。同时由于大企业拿到的项目一般也比较大，项目组就比较大，客户要求也高。这也为过程改进增加了必要性。

持续的改进很重要，但频繁的改进会不利于过程的执行

CMM中定义了每个KPA的目标和一系列的KP，企业必须根据自己的实际情况去定义实现每个KPA的工作流程。但并不是每个企业都很幸运，在一开始就可以定义一个自己企业的最佳实践。一般的情况是，首先定义一个工作流程，并在一个试点项目中实行，而后对试点项目进行总结，并对此工作流程进行改进。再

在其他项目或整个企业中推广，也许在推广的过程中，又遇到问题，再对流程进行修改。整个的过程定义是螺旋上升的进行。这本身没有问题，但有时当遇到问题时，不要太急于就改流程，或加流程的分支。而要仔细分析后，慎重的进行。太频繁的改动，给人一种不严肃的影响，似乎流程可以随意的改动和定义。最后，没人去遵守流程了。同时，根据不同的项目若定义了太多了流程分支，最后，实际人员也不知道要去实行哪一套了。

总之，频繁改动的规矩，让人无所适从。

过程制定后，一定要有选择的进行试点。一个进度和成本宽余的项目和一群对过程改进有热情的人是保证试点成功的组合

定义好一套流程，最好的验证方式就是找个真实的项目去‘跑’一遍。并注意收集应用流程前后的各种情况的对比。由于在项目的进行中，还要试验流程，所以需要更多的培训时间，让项目组的成员了解熟悉新的流程。需要更多的评审，不但是评审项目本身，还要评审过程和进行必要的度量。

一群对于过程改进有热情的组员是试点成功的保证。他们要有热情去学习新的流程，要有热情去沟通在执行新流程当中遇到的问题，他们要有热情去克服进行中的困难，而不是抱怨，他们要有热情去总结和改进新的流程，使它更完善，最总要的是，他们要有热情作为新流程的传播者，把流程象星星之火一样在组织中开展。

一个坚决支持过程改进的领导是必不可少的

象任何其他的变革一样，一个坚决支持变革的领导是不可缺少的。在一切顺利，大家赞成的时候，也许感觉不到什么。但当变革遇到阻力，遭受暂时的困难时，这种坚决的支持就是变革是否可以继续进行的保证。

因此，在过程改进的初期，于企业的高层进行沟通，让其了解到过程改进的必要性和预期的前景是十分必要的。同时最好在过程改进的开始阶段，一个誓师大会的举行也是鼓舞士气的上佳方法。在过程改进的过程中也要注意及时的通报进行的过程，取得的成果。当然在遇到困难，或需要高层支持时，更要及时开口。（这对于技术人员主持的过程改进尤为重要。）

要有选择的对于KPA进行改进，不一定是最薄弱的KPA，最重要是选择你可以控制的KPA

关于这点其实并不涉及CMM的技术问题，而是一个管理问题。这里有个现实的例子，一家企业的管理有点乱，高层希望可以通过CMM的过程改进，来提高企业的产品质量，理顺工作的流程。于是任命了一个开发组的主管（代称A），来主持这个过程改进。结果A在选择KPA的时候，认为首先应该对于实行需求管理和变更管理。因为开发组的同事们都抱怨，需求经常改变，造成的返工很多，

在最终期限的压力下他们不得不经常加班。这个本事没有问题，可是需求管理和变革管理的发起基本是在系统分析组，而这个组在行政上不归他管。公司也没有因为要进行过程改进而把他提高到一个高的级别（即使是暂时的）。

现在问题来了，虽然他花费了心思去设计的流程。并对于需求部门和相关部门组织了培训。可是在进行试点的时候，他发现，当他去评审需求分析组的工作时，别人很反感。而且对于有些需求的变革也推诿到销售人员、客户等因素。同时，流程中只要有一点不太合理的地方，就抱怨的很厉害。最后试点结束，他自己很累，试点的结果也不好，改善的目标没有实现。整个过程的改进处于一种微妙的处境。最后，试点的流程并没有推广。其他的KPA过程改进也不再进行了，随着时间的推移，过程改进在企业中也不在有人提起。

知道这位开发组的主管错在哪里吗？他选错了KPA，他选了一个不属于自己管辖范围的KPA作为起点。他跑到一个不属于他的地方开始指手画脚，他是个不受欢迎的人。注定了，在一开始他就面对着对立和抱怨。这样的团队是无法经受一点点挫折和失败的。若他一开始选择配置管理，这个至于他管理范围的KPA，他可以利用手中的权利、资源和威信，组织试点。可能情况就好的多。又或者企业的高层给这个开发主管一个虚职，比如过程改进项目组组长，并任命其他组的组长为过程改进项目组成员。情况也会完全不同。

对于过程的改进要有度量

不必一开始就是数字化的，也可以是感性的体会。但要把这些也要收集起来。一个有力的对比可以堵住反对者的嘴。不要因为度量管理是CMM4级的内容就在实施低级别的CMM时放弃度量。一套流程需要一系列度量的数据来说明它改进了多少。而度量的数据将会为它赢得预算和支持。

当然度量作为CMM4级的内容，也是有一定的道理的。收集一套完备、准确的度量是需要大量人力的。但是在一开始，也许我们可以借助一些好的工具达到同样的效果，而不必花费大量的时间和精力。

在我就自己做过一个简易的BUG管理工具，并和数据库相连。在项目结束时我可以轻易的了解项目中有多少BUG、BUG分布如何，BUG的原因统计等度量数据。我只是用了几个SQL语句就掌握了我需要的度量。

另一个例子是微软推出的PROJECT SERVER（注：不是广告）。以前项目经理要了解实际的项目进度并不是件轻松的事，项目经理要去问组员××模块，你开发的如何啦？然后收集好所有组员的进度，填写自己的项目进度。由于这相当的花费时间，过去进度基本上一周汇报一次。可是有了PROJECT SERVER你只要按个‘请求进度’的按钮，组员直接通过WEB填写与他相关的进度就可以了。项目经理就可以得到整个项目的进度了。

不必拘泥于CMM的级别

这一点在CMMI中已经有体现了，CMMI不再只有一种级别的模式，还增加了持续改进的模式。即，可以按过程域进行改进，而不是过去按级别进行改进。

比如，CMM5级的技术革新管理。其实，在现在新技术层出不穷的当今，一个企业不会因为还没到CMM5级就不需要技术革新管理。换一种数据库，换一个开发工具，甚至是换一种开发过程等都是一直发生的。若需要完全可以把这个KPA先实施改进。

不是每个人都喜欢改进的过程，特别对于要增加其工作量的过程。有时必须牺牲一些过程的严谨性，去简化过程。毕竟有过程比没过程好。

也许在看到了这条时很多人会不以为然，说：这样做肯定过不了CMM评审。对，这样确实肯定过不了CMM级别的评审，可是只要可以对于过程有改进，对于软件质量有提高，就可以了。对于中小软件企业，一个有效的（可以满足高层对于过程控制的期望），简易的（是所有基层工作人员可以理解的，无须大量培训的），可行的（不会大量增加基层人员的工作量，不会影响开发速度和效率的。名言是：‘我不要那种原先2天可以完成的项目，因为应用了过程，现在要5天才可以完成的所谓的过程’。）和低成本的（公司一年才赚多少，我可不想把钱全用来采购工具软件）过程才是最重要的。

选择合适的工具，至关重要。好的工具不但使过程更流畅，也大大减少由于过程的引进而引入的工作量。

关于这点其实在前面介绍PROJECT SERVER时已经有介绍。这里只是再作为一个观点再提一下。不过虽然工具的使用可以提高效率，不过这方面的工具都不便宜。是否引进，何时引进确实对于中小型的软件企业要好好考虑。

在这里列一些工具供大家参考：

计划工具：Microsoft Project

项目监督和跟踪：Microsoft Project server 2003，SharePoint

需求管理：Rational RequisitePro, Borland CaliberRM, SYSBASE POWERDESIGN 11

变更管理：Rational ClearQuest

Bug跟踪工具：Rational ClearQuest

配置管理工具：VSS, CVS, Rational Clearcase

一个强有力的执行和守纪律的企业文化，是推广过程改进的保证

一个过程，在试点后，是要推广的，在推广过程中一个强有力的执行力是必然的保证，这个不用多言。

而对于守纪律的企业文化本来我并没有太深的感受，直到有个朋友告诉我，他们公司的印度工程师如何的刻板。我突然意识到这也许就是国内软件公司长不大的原因了。是的，严格的遵守企业定出的过程，有时是显得有些刻板。但在相当长的其他时期，也正是这种刻板，保证了公司的过程被严格执行。

有人说，什么标准一到中国就变了味了。这虽然不太好听，但你不得不承认，有时我们确实为了省力，为了赶工，确实在破坏公司的过程。

毕竟CMM只是软件开发的过程改进的标准，但一个软件项目的成功，并不局限于软件开发。用CMM的模式去改进一些前期项目计划和后期系统实施的过程，将会对组织的软件项目的成功事倍功半。