CMMI在DM中应用的初步成果与弊端

  

DM项目到目前为止，已经完成了需求调研、项目计划和需求分析，进入了详细设计的阶段。从长远来看，经过前段时间的实施，对CMMI我持肯定的态度。在此我强调的是长远，如果一个项目没有长远的发展空间，或者项目组在以后的项目中不能应用CMMI的精髓，只是纯粹的一个DM项目跑CMMI流程，成本绝对过高。而且，在项目开发的过程中，大量的文档和会议，每个动作都需要讲究流程，对于我们这些喜欢自由崇尚简约的研发人员来说的确让人有点难以招架。不过，每个改变都会有阵痛，只是看这种痛是否痛得有价值。CMMI并非成功于一个项目的革命，而是一个持续的改进，是不断总结成功经验和失败教训，进行缺陷预防和不断改良的过程变革之旅。

因为需要严格执行CMMI5的过程，产品的文档必须完整，以往我们项目组中缺少的就是文档，很多问题都无法追查，而CMMI5的执行，在前期花了很多时间在文档的编写、业务需求的理解和调研上，而不是一拿到需求就准备着手coding。文档的质量也不错，因为需要评审，在文档编写的时候，作者都很认真对待，花了比较多的时间与精力去思考与编写，而不是敷遣了事。对于业务理解不清或编写错误的地方，也会在评审被检查出来修正，确保一些潜在的缺陷被提前发现。这样的好处是coding的需求、设计都非常明确，可以减少以往由于需求理解不清或设计错误导致的缺陷，降低项目的成本；另一个好处是对以后的维护，就算是项目组中的成员离开了公司，因为有完善的文档，新接手的同事也可以迅速进入状态。

DM的评审已经进行了三次：项目愿景与范围、项目计划（包括项目计划、总体测试计划和配置管理计划）、需求规格说明书，评审的效果逐渐好转。第一次评审的时候，大家对评审的规程以及检查项都不熟悉，发现的问题和效果不太理想，但随着项目组成员对评审的熟悉以及上层领导的重视，评审的效果初步显露了。通过评审，可以提前发现缺陷，对于有异议的问题也可以通过讨论达成一个共识，即使是没有在评审中发现太多的问题，也可以通过评审增进大家对业务的理解。特别是一些争议的问题，在评审的时候提出来大家讨论达成一个共识，这一点非常好，解决了以往一个争议问题在邮件中各自陈述，好几天才可以达成一致的见解的情况。在DM的评审中，EPG和PPQA都是经验丰富的高级经理，他们在评审表和会议中提出了不少很有价值的意见，可以看出他们对此项目的认真负责，也正是因为高层领导的重视和推动，使得DM的流程开展顺畅且有成效。我想，如果缺少了这两位经验丰富的高层指导，也许又会是另一种局面了。

不过，个人评审提交的评审检查表大部分评委都很少能提出有建设性的建议，在评审中发现的问题并不多，投入这么多的人和时间，成本显得过高。出现这样的问题，可能是文档的作者认真负责，花了足够的时间和精力去编写文档，文档已经是很完善了不会出现太多的问题；或者是评委的水平有限或者不够负责，未能识别本应识别的缺陷；还有一种可能是准备的时间不充足，评委没有足够的时间去阅读评审对象和识别问题。不过，对于第一次参与CMMI的项目，也不能太苛刻，正如EPG所说的那样，在评审中最大的收获不是识别了多少个缺陷，而是大家一起对项目进行讨论，达成了共识。

另外，因为项目比较小，小项目应用CMMI，从短期来看的确显得成本过高。公司一向严格节约成本，而这个项目，舍得投入如此庞大的资源，可见其真的是对CMMI的高度重视。正是因为高层的重视，CMMI的推广才会如此顺利。

PS：在进行需求总结的最后，EPG说了一句话：“在大家提交的评审表中，smilings的检查最认真，可以看出她花了心思在这个个人评审上，既然都开始实施了希望大家以后也像smilings以更加认真的态度对待这些评审工作。”那一刻，我似乎又回到了小学时代，有一种说不出的感动，毕竟，有人知道我花了心思，有人肯定了我的工作。原来，人都是希望被人肯定的，我也不能免俗。