小的软件公司运用CMM思想进行过程改进方法浅析

一、 确定生命周期模型，制定软件开发规范SPE

虽然说SPE（Software Product Engineering）这个KPA是在CMM三级中体现出来的，对于软件开发过程的描述和要求；但是在小公司开始规范化中可以先初步的实施，对于公司领导和开发人员比较容易接受。目前，国内的一些小的企业大多数在具体的一个项目中都没有开发规范，完全是手工作坊式的开发，思想深处是“重技术，轻管理”项目经理和开发人员虽然都学习过软件工程理论，但是没有明确的在开发过程中显性的表现出来。制定出简单而实用的开发技术规范，比较容易符合开发人员的惯有思路。主要的目的是在开发人员中建立起最直接的规范，培养他们的管理意识。这要比一开始就让项目组去实施需求管理、项目策划和项目的跟踪与监督非技术的流程更实用。
在生命周期模型的选择上面，我还是建议对于不成熟的公司，采用重叠瀑布型，原因有两个：首先，瀑布型是“线性化”大家最容易掌握并能熟练应用其思想方法；其次，在其他的生命周期模型中细分后几乎都能找“线性”的思想，为以后的改进打好基础；

二、 项目策划的实施，计划的制定

在项目执行过程中需要制定计划，这是CMM二级中SPP（SoftWare Project Planning）的核心内容，并且是SPTO（SoftWare Project Tracking and Oversight）的依据；项目计划这个活动的实施好坏直接影响到2个KPA的效果。我认为这是CMM二级中的难点之一；在小公司实施CMM开始阶段，开发人员不习惯也不可能准确的在制定计划前估计出项目的规模、工作量、进度、计算机关键资源、预测风险及其预防措施，但是对于计划制定的必要性所有人还是比较认可的。所以在开始阶段让项目组一起讨论制定出计划 （讨论的时候项目管理人员有意识的引导项目组是作类似于估计的活动），由项目经理或者项目管理人员跟踪计划，在项目结束后，总结项目的进展情况并记录下来。作为下次开发的经验。几个项目的完成后，有了历史数据对估计的过程有实际的认识后，再明确的提出估计活动和SPTO的相关活动，大家就会很自然的接受并且去执行了，大大的减少了推广的难度。

三、 建立评审机制

同行评审也是CMM三级的KPA之一；评审活动也可以在小的公司执行，首先从技术评审开始实施，管理评审可以先暂缓执行。技术评审对项目组的工作有着直接的帮助，并且能得到管理者的支持。评审会议可以采用讨论、问答、讲解、走读等等形式（虽然理论上评审中不提倡讨论并且要避免讨论，但是我认为小公司在刚开始阶段没有必要严格遵守），执行一段时间后，所有的人对评审的流程和重要性有了充分的认识，结合公司的实际情况确定引入其他评审内容（例如里程碑的评审）；但是要记住切不可急于求成，一旦评审会议造成走形式，产生负面影响，资源的浪费，人员情绪的抵触，对于小公司来说是很不利的。

四、 建立配置管理制度

配置管理执行的过程中，暂时不设置SCCB这个机构，首先先确定受控的工作产品和做版本管理；进行相应的培训让项目组建立起基线、里程碑、版本一致性的概念并具体的工作为Check-in 和Check-out活动。对于配置审核、SCM活动状态的审计等管理、验证内容项目组可以暂缓执行，具体的工作可以由项目管理和配置人员作这方面的工作，发现问题提醒开发人员，及时进行纠正。上面的配置活动和采用的配置工具无关，及时公司没有配置管理工具，用Windows目录管理也不会影响执行的效果。

五、 监督体系的完善

监督体系可以从三个方面进行。第一、项目经理每周提交项目周报，内容包括，项目的进度是否符合计划、从事的额外工作汇总、出现的问题及其解决办法、人员的变化等方面；第二、测试人员对相应工作产品的审核，包括需求文档、用户说明书、代码和产品质量等环节；第三、类似于SQA职责，主要的职责帮助制定计划、配置活动，出现了非技术性问题，由其解决并汇报。这种情况下，对SQA的要求比较高的，不仅仅是担任高级管理者的“耳目”的作用，而且还要能帮助解决项目组实际困难的职责。这需要一定的管理能力，工作技巧。
总的来说，小公司实施CMM应当符合自己公司的现状，在人员、资源有限的情况下，将有限的精力用于“刀刃”上，每件事情都能起到积极的效果，保证产品和公司的最大利益这才是最关键的。