现在的软件行业竞争激烈，生存环境也极恶劣，为了提高自身的竞争力，提高生产效率和产品质量，不少软件企业开始想办法过CMM了，或者根据CMM和自身的经验制定类似的过程。我曾经研究过一点点CMM皮毛，也经历过一些公司如何理解及实施CMM的，现在的公司已经过了CMM3，准备过CMMI5。有一组同事专门从事此项工作，并建立了公司的过程，我们也在实施这些过程，也有一些感触。
首先说文档吧，公司制定的过程采纳了CMM的很多建议，文档的建立和使用尤其多。从需求到设计再到编码，然后是测试，发布（典型的瀑布模型），每一步都会有许多的文档产生。我所在的项目组只有两个开发，一个项目经理，两个高级工程师（基本上不编码），三个测试，仅仅从人员构成上就可以看出文档占总工作量的比重。需求阶段，先写需求文档，写完后大家一起做PeerReview，在会议上发现的问题作为BUG全部记录到BugTracking中，会议之后除了把问题修改完还要把BugTracking中的记录全部更新（一条一条地）。这么做的理由是过程组要使用这些数据来分析和提高我们的产品质量。测试人员同时也在写他们的测试设计和案例，写出来的比我的设计文档要多很多，让我感觉很不好意思。后果是我做完一部分模块之后叫他们先测试一些，他们说没时间，因为文档还没有写完。最近去了几次，几个人都在埋头苦写文档，我建议他们先写得简单点，边测边补充，但被拒绝，理由是CMM是这么规定的，搞得我很郁闷。难道CMM会规定我们写文档必须要写成这样?!其实最失望是做PeerReview，大家精力集中在文档本身，而不是它所表述的内容上面，会议结束后我的善后工作是要写成另个一种格式，，内容没大问题，只花了五分之一的时间来讨论。会上很多人要求设计文档应该再细化，最好是连文件名定好，编码的人比较方便，以后想查这部分的资料看起来也方便。又是为了以后！这个借口只比“CMM规定”要少。
CMM的作用是有限制条件的，文档的作用是有限的，你做得越多，最后被抛弃的可能性也越大。CMM中提及的方方面面很多，如果全部采纳，公司无法长期承受因此而带来的成本压力，CMM也不是短期内就带来效应的。最后的结果只能是放弃。文档也一样，你的文档越详细，维护的成本也越高，代码的小小改动都要修改文档，维护文档的时间超过了代码的维护时间的时候，我们都会选择不修改文档。一旦有了第一次，后果显而易见，文档最终被抛弃，而不是为后来者提供尽量多的信息。因为你根本无法从文档中获取正确的信息，说不定还会误入歧途。
这段时间我感触最深的是CMM和实际工作相结合的难度超乎想像，你真的很难说做到这个程度就是合适的。不会过分，也不会不足。CMM比较全面地定义过程，各个公司应该要根据自身的特点改造和扩展CMM，因为大家的目标都一样，就是要提高产品的质量，提高企业的生产效率。