对于过程的改进要有度量

    不必一开始就是数字化的，也可以是感性的体会。但要把这些也要收集起来。 一个有力的对比可以堵住反对者的嘴。不要因为度量管理是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的模式去改进一些前期项目计划和后期系统实施的过程，将会对组织的软件项目的成功事倍功半。