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

2001我开始慢慢关注起软件工程和CMM，也对CMM进行了学习。并且对其中的一些KPA在自己单位中进行了试验。可是一开始这些试验的结果并不令人愉快，甚至遭到了抵制和反对。开发和测试人员认为降低了开发速度和灵活性，加大了工作量，工作流程太烦琐。而质量的提高也不是一时可以反映出来的。于是在进行了2个小项目的试验后，我被迫停止了CMM在公司的实施。因为公司并不从事外包服务，所以CMM对其没有生存的压力。高层也只是想通过一个可行的过程管理，一个提高软件质量，保证项目进度，有效控制项目成本。所以公司并不是要去过CMM等级，而是要一个有效的过程管理。

　　所以我此后开始以‘有效、简易、可行、低成本’为标准探索起适合起我们公司的过程改进的实践。现在，我很高兴可以在文中和大家探讨我公司在过程改进过程中的一些经验和教训，也许你会从中得到一些启发，开发出适合你自己的实际。欢迎对此文章提出评论和质疑，您的来信将是我继续研究的动力。

　　经验和教训：

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

　　中小企业，特别是开发人员小于40个人的企业。一般不会有专门的人员可以组建‘软件过程组’，也很少会有专职的质量工程师和配置工程师。在进行过程改进中，对于这些职位基本上都是由原来的人员兼职完成。这无形中增加了人员的工作量。一旦过程定义的不是太完善，或是在试点中不是太成功。很容易让人去怀疑过程改进本身的可行性。同时中小企业接到的项目也比较小，成本压力是比较大的，而提高质量是必须以牺牲成本为代价的。所以有时从成本的角度出发，可能在高层管理人员的心目中，对于过程改进也是有成本的顾虑的，一方面希望，可以通过过程改进提供质量，并为企业的发展提供基础，另一方面，也面临成本压力，若过程是改进了，可是成本也大幅度提高了，则本事企业的生存就成问题了。而在大的软件企业，一般可以有专职的人员进行质量保证和过程改进。同时由于大企业拿到的项目一般也比较大，项目组就比较大，客户要求也高。这也为过程改进增加了必要性。持续的改进很重要，但频繁的改进会不利于过程的执行CMM中定义了每个KPA的目标和一系列的KP，企业必须根据自己的实际情况去定义实现每个KPA的工作流程。但并不是每个企业都很幸运，在一开始就可以定义一个自己企业的实践。一般的情况是，首先定义一个工作流程，并在一个试点项目中实行，而后对试点项目进行总结，并对此工作流程进行改进。再在其他项目或整个企业中推广，也许在推广的过程中，又遇到问题，再对流程进行修改。整个的过程定义是螺旋上升的进行。 这本身没有问题，但有时当遇到问题时，不要太急于就改流程，或加流程的分支。而要仔细分析后，慎重的进行。太频繁的改动，给人一种不严肃的影响，似乎流程可以随意的改动和定义。最后，没人去遵守流程了。 同时，根据不同的项目若定义了太多了流程分支，最后，实际人员也不知道要去实行哪一套了。总之，频繁改动的规矩，让人无所适从。过程制定后，一定要有选择的进行试点。一个进度和成本宽余的项目和一群对过程改进 有热情的人是保证试点成功的组合。定义好一套流程，的验证方式就是找个真实的项目去‘跑’一遍。并注意收集应用流程前后的各种情况的对比。由于在项目的进行中，还要试验流程，所以需要更多的培训时间，让项目组的成员了解熟悉新的流程。需要更多的评审，不但是评审项目本身，还要评审过程和进行必要的度量。