软件小开发团体运用CMM思想进行过程改进

 目前很多有一定规模的软件公司都热衷于CMM认证，他们不仅想借此提高公司的声誉，拉开和竞争对手的距离并且在业务竞标中取得有利位置，也更想借此机会从本质上使本公司的软件开发实力达到一个质的飞跃。但是对于小公司或者小的开发团体呢？他们由于资金，资源和规模等方面的原因，不可能花费巨额的投资去请好的咨询公司来做CMM认证，因此也造成也一些小公司，小开发团体觉得没有认识和运用CMM的必要，但事实真的如此吗？
         在学习了《软件过程改进与管理》这门课程后，并且结合自己工作中碰到的实际问题，我觉得即使是小公司，小开发团体，如果能够适当抽取CMM的部分思想精髓来对日常软件开发工作进行过程改进也是十分必要的，目的不是为了认证而认证，也不是为了接工程而进行所谓的CMM认证，关键在于真的达到“改进”这个目的。
         我公司虽然是香港的一个上市IT公司，但主要业务做系统集成和解决方案为主，而软件部分占的比重并不大，只做技术支持，软件集成和必要的软件开发，因此和一般专业的软件开发公司确实有很多不同的地方，因此我们部门的软件开发只能属于小的开发团体。虽然也过了ISO9001，但是这个认证主要是针对系统集成项目为主的，我们公司一直以来在软件开发部分并没有形成十分规范的管理流程，特别是文挡管理也只是遵循着公司自己制定的文挡模板而已。在学习了《软件过程改进与管理》之后，我觉得其实CMM中的很多思想在以前的开发工作中也有用到，只是没有十分系统的整理或者说上升到一定的层次去做一个提高而已。学习了课本的理论，再回想工作的情况，恰好可以做到理论指导实践，实践检验理论的作用，有些思想在日后的工作中如果可以运用起来的话，确实可以促进象我们这种小团体的开发效率的。
         我大致整理了下，有以下几点心得：

一． CMM是程序员终极目标的提升

        无论做什么样规模的软件开发，重用性是任何程序员和程序开发团体的终极追求目标。从以前结构化开发过程的时候，大家都绞尽脑汁去归纳出公共函数，到现在流行的面向对象开发过程时提出的各种设计模式；从以前的公共程序库到现在流行的组件技术…这些都是程序员在技术方面对重用性的一个追求的轨迹…有人说软件开发成功重要因素就是技术，人和管理，重用性在技术方面的追求一直都没有间断过，而人本身也是重用性的努力追求者，在管理方面呢？虽然各种的管理方式层出不穷，从适合大团队开发的RUP迭代开发到适合小团队的敏捷开发模式XP，这些开发方式或者说是太具体了，对于国内的开发团体，完全地生搬硬套似乎都遇到这样或者那样的困难，或者是中途夭折，又或者寻寻觅觅，在各种的开发模式中犹豫不决，而CMM的层次和它们又有所不同，它没有提出一个具体的操作指南，但却从效果的角度提出了它的要求，并且制定了5个不同的级别：初始级，可重复级，已定义级，已管理级和优化级。这几个级别当然是级别越高越好，但是对于不同的规模的团体却可以根据自己的实际情况去制定自己的近期目标，而不需要去追求不切实际的级别。对于可重复级别，其实已经可以在一定程度上实现程序员一直追求的终极目标--可重用性了。
结合自身的开发过程，像我们这种小的开发团体，并没有必要一定要完全遵循或者达到这些级别的每项要求，然后自诩自己达到了什么级别，这些并没有任何实际的效果，倒不如从中抽取几个精髓加以实现，从而可以达到过程改进的目的。

二． 加强项目策划，规范计划的指定

       任何项目的执行过程中都需要指定必要的计划，这个道理即使没有学习过CMM，只要做过项目都是应该知道的。而学习了CMM后，从理论上知道在项目执行过程中需要制定计划，这是CMM二级中SPP(Software Project Planning)的核心内容，并且还是SPTO(Software Project Tracking and Oversight)的依据。由此可见项目计划这个活动的实施好坏直接影响到2个KPA的效果，而且这个还是CMM二级的难点之一。在以前的项目实施，虽然都可以意识到项目计划的重要性，但在实际执行过程中，对于计划的跟踪和进度记录的工作也往往做得不够充分，特别是任务比较紧的时候，跟踪和记录有时就成了项目经理给领导做的一些门面工夫了，并没有真正起到应有的作用。由于这些记录的并不真实，又往往不能使这些数据对后来的项目起参考的作用，到下一个类似项目，一切又由项目经理根据自身的主观经验来对新项目的进度和资源的分配进行估计，因此项目计划的制定并没有达到一个不断改进的效果。如果项目人员接受了CMM的思想，并且能够真实地跟踪项目进程，真实数据的积累对于日后过程的改进是十分有效的。

三． 建立配置管理机制

       以往的开发中，我们也有用到一些版本控制工具，例如CVS或者VSS，但是都只是为了从技术上同步大家的代码而使用的。在学习了CMM后，才认识到配置管理制度的重用性，而版本控制也是配置管理的其中一部分。对于小的开发团体，设立SCCB机构是完全没有必要的，但是确定受控产品和做版本管理，项目组建立基线，里程碑，版本一致性的概念和更加规范版本操作的Check-in和Check-out等动作确实十分必要的。理解了CMM的配置管理机制，可以让我们在开发过程中，从更高更全面的角度来完成以前版本控制的工作，这个过程改进也是十分明显的。

四． 质量控制体系的完善

        由于人手的原因，对于小开发团体，在某种程度上在以往的开发过程中对于质量保证方面是粗线条的，往往开发人员完成了Unit Test就集成起来做了几次集成测试后就直接去到用户那里做用户测试了，往往造成的结果是开发人员经常被用户叫到现场去修正程序错误。这虽然不可避免，但是次数多了，往往对于整个项目的进度的影响很大，而且对于代码的版本管理和整体监控等方面都十分不利的。在CMM的思想指导下，质量控制管理体系不能够因为人手的原因而减低对其的要求，宁可适当加长项目时间也必须将质量保证下来。

五． 监督体系的完善

       监督体系不仅是管理的需要，也是项目组中成员和项目经理沟通的需要。项目组成员应该定期给项目经理做进度的汇报，而项目经理也有义务定期做项目周报和项目进度总结。监督还包括测试人员对工作产品的审核，包括需求文档，用户说明书，代码和产品质量等环节。虽然这点看起来似乎对于小开发团体，由于因为人手和资源的原因在实施上有一定的困难，但也应该在CMM的思想上对其重视，不应该为了赶进度而将这些必要的事情忽略了，最终又去返工补救。这样只会得不偿失，也使整个开发过程得不到一个持续改进的效果。

        总的来说，CMM的思想不仅适合大公司，对于小开发团体一样可以起到过程改进的效果，关键是要把有限的资源用到“点子”上，使得整个开发过程朝一个健康的，持续改进的方向发展。