前言：
2001我开始慢慢关注起软件工程和CMM，也对CMM进行了学习。并且对其中的一些KPA在自己单位中进行了试验。可是一开始这些试验的结果并不令人愉快，甚至遭到了抵制和反对。开发和测试人员认为降低了开发速度和灵活性，加大了工作量，工作流程太烦琐。而质量的提高也不是一时可以反映出来的。于是在进行了2个小项目的试验后，我被迫停止了CMM在公司的实施。
因为公司并不从事外包服务，所以CMM对其没有生存的压力。高层也只是想通过一个可行的过程管理，一个提高软件质量，保证项目进度，有效控制项目成本。所以公司并不是要去过CMM等级，而是要一个有效的过程管理。
所以我此后开始以‘有效、简易、可行、低成本’为标准探索起适合起我们公司的过程改进的最佳实际。现在，我很高兴可以在文中和大家探讨我公司在过程改进过程中的一些经验和教训，也许你会从中得到一些启发，开发出适合你自己的最佳实际。
欢迎对此文章提出评论和质疑，您的来信将是我继续研究的动力。可以发Mail：bluehao@online.sh.cn, roychen7608@yeah.net MSN: bluehao7608@hotmail.com
陈皓
经验和教训：
在中小型的软件企业当中，软件过程的改进更容易半途而废
中小企业，特别是开发人员小于40个人的企业。一般不会有专门的人员可以组建‘软件过程组’，也很少会有专职的质量工程师和配置工程师。在进行过程改进中，对于这些职位基本上都是由原来的人员兼职完成。这无形中增加了人员的工作量。一旦过程定义的不是太完善，或是在试点中不是太成功。很容易让人去怀疑过程改进本身的可行性。同时中小企业接到的项目也比较小，成本压力是比较大的，而提高质量是必须以牺牲成本为代价的。所以有时从成本的角度出发，可能在高层管理人员的心目中，对于过程改进也是有成本的顾虑的，一方面希望，可以通过过程改进提供质量，并为企业的发展提供基础，另一方面，也面临成本压力，若过程是改进了，可是成本也大幅度提高了，则本事企业的生存就成问题了。
而在大的软件企业，一般可以有专职的人员进行质量保证和过程改进。同时由于大企业拿到的项目一般也比较大，项目组就比较大，客户要求也高。这也为过程改进增加了必要性。
持续的改进很重要，但频繁的改进会不利于过程的执行
CMM中定义了每个KPA的目标和一系列的KP，企业必须根据自己的实际情况去定义实现每个KPA的工作流程。但并不是每个企业都很幸运，在一开始就可以定义一个自己企业的最佳实践。一般的情况是，首先定义一个工作流程，并在一个试点项目中实行，而后对试点项目进行总结，并对此工作流程进行改进。再在其他项目或整个企业中推广，也许在推广的过程中，又遇到问题，再对流程进行修改。整个的过程定义是螺旋上升的进行。 这本身没有问题，但有时当遇到问题时，不要太急于就改流程，或加流程的分支。而要仔细分析后，慎重的进行。太频繁的改动，给人一种不严肃的影响，似乎流程可以随意的改动和定义。最后，没人去遵守流程了。 同时，根据不同的项目若定义了太多了流程分支，最后，实际人员也不知道要去实行哪一套了。
总之，频繁改动的规矩，让人无所适从。
过程制定后，一定要有选择的进行试点。一个进度和成本宽余的项目和一群对过程改进 有热情的人是保证试点成功的组合
定义好一套流程，最好的验证方式就是找个真实的项目去‘跑’一遍。并注意收集应用流程前后的各种情况的对比。由于在项目的进行中，还要试验流程，所以需要更多的培训时间，让项目组的成员了解熟悉新的流程。需要更多的评审，不但是评审项目本身，还要评审过程和进行必要的度量。
一群对于过程改进有热情的组员是试点成功的保证。他们要有热情去学习新的流程，要有热情去沟通在执行新流程当中遇到的问题，他们要有热情去克服进行中的困难，而不是抱怨，他们要有热情去总结和改进新的流程，使它更完善，最总要的是，他们要有热情作为新流程的传播者，把流程象星星之火一样在组织中开展。
一个坚决支持过程改进的领导是必不可少的
象任何其他的变革一样，一个坚决支持变革的领导是不可缺少的。在一切顺利，大家赞成的时候，也许感觉不到什么。但当变革遇到阻力，遭受暂时的困难时，这种坚决的支持就是变革是否可以继续进行的保证。
因此，在过程改进的初期，于企业的高层进行沟通，让其了解到过程改进的必要性和预期的前景是十分必要的。同时最好在过程改进的开始阶段，一个誓师大会的举行也是鼓舞士气的上佳方法。在过程改进的过程中也要注意及时的通报进行的过程，取得的成果。当然在遇到困难，或需要高层支持时，更要及时开口。（这对于技术人员主持的过程改进尤为重要。）
要有选择的对于KPA进行改进，不一定是最薄弱的KPA，最重要是选择你可以控制的KPA
关于这点其实并不涉及CMM的技术问题，而是一个管理问题。这里有个现实的例子，一家企业的管理有点乱，高层希望可以通过CMM的过程改进，来提高企业的产品质量，理顺工作的流程。于是任命了一个开发组的主管（代称A），来主持这个过程改进。 结果A在选择KPA的时候，认为首先应该对于实行需求管理和变更管理。因为开发组的同事们都抱怨，需求经常改变，造成的返工很多，在最终期限的压力下他们不得不经常加班。 这个本事没有问题，可是需求管理和变革管理的发起基本是在系统分析组，而这个组在行政上不归他管。公司也没有因为要进行过程改进而把他提高到一个高的级别（即使是暂时的）。[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
