那么，反观我们记载文档的过程呢，早先我们完全听取了日本评估师的建议，针对各个过程做了部分剪裁后，制作成了各种各样的excel模板，在实际工作时，就从模版来复制出一份实际的文档。比如，我作为PairReview Leader，每次有人申请PairReview，我就必须用模版来复制出一张实际的Review票，接着填入参与的人员，Review对象等内容，再发邮件给Review者，然后参与到Review的整个漫长过程中：Review者Review完后，在票中填入Review意见，发回做成者修改，做成者修改完后再填写已修改信息，再一次给Review者检查。。。。N个回合后，Review票回到我的手里，我再将其归档，有时稍一疏忽，某封Review票就被我遗忘在邮件堆里了。。。。更悲惨的是，每当要统计些什么数据的时候，虽然外部有一个总的Review管理票，但是部分细节数据，我还是必须一个一个打开所有的Review票，手工进行统计。。。。。一个Review票如此，其它如Bug管理，Test管理等，都是如此，其间的痛苦，相信只有做过CMM的朋友可以体会了。
纵观以上的过程，我觉得关键的问题并不是出在CMM本身上，只是我们在具体实践的时候，纯粹教条主义的照搬别人的方法，选择了错误的管理工具(SourceSafe+Excel的模式实在是罪魁祸首了），所以，当公司的CMM评审结束，CMM不再作为一种公司的强迫性措施的时候，我们开始找寻自己的裁减之路了。。。
开始的时候，从《程序员》杂志的介绍中我们得知了BugFree这个Bug管理工具，作者以其多年微软的工作经历，总结后开发了这个Bug管理工具，具体的介绍我就不谈了，关于这个工程的内容，去年年末的某一期以及今年2月的《程序员》杂志都有介绍，其项目也可以在这里找到：http://sourceforge.net/projects/bugfree
BugFree确实为我们解决了Bug管理的问题，因该说在Bug管理方面它做得非常出色，但是也仅此而已，我们需要的还是一款能够由综合管理功能的软件。这就是最近我们开始使用的一款软件：TaskVision。
它是微软为了演示其.Net开发能力的一个OpenSource软件（微软，呵呵，它的OpenSource可不多阿），它的代码有C#和VB.Net两个版本的，都可以在微软网站上下载。它是一个C/S型的工具，S端负责事务处理和DB访问，C则负责用户界面，它将开发过程分为多个Project，每个Project中可以有多个Task，Task可以分配给某个用户（开发人员），并可以指定开始，结束日期，任务说明等内容，每个用户都可以方便的察看所有Task或者属于自己的Task，谁有些什么开发任务，要改些什么Bug等内容都一目了然。每天上班只要看一下TaskVision中属于自己的任务列表，就可以开始工作了（简直把人当作了机器，呵呵，这部正是CMM所要求的嘛），每天下班时，用户对自己的Task写入当日进度报告（这是我们这里的高手自己增加的功能，呵呵），以及Task完成的百分比。TaskVision有个好处，它分为连线以及非连线两种状态，连线状态下，用户修改的情报会被直接递交到S端，而非连线状态下，所有数据会暂时保存在本地，当下次连线时才被更新到S端，同时，它又监测当前的空闲状况（用时钟），会自动从S端获取别人更新的内容。
用户在C端所有的Task以及其完成的进度都会以列表的形式显示出来，作为PM就可以方便的查看每个开发人员的完成情况了，同时，整个Project的总体完成进度也会被自动统计出来，对于管理人员来说这时非常方便的。更重要的是，现在PM一眼就可以看出谁空着了，可以马上给其分配新的任务（CMM的又一个不人性化的特点，我们的娱乐时间啊！！），而不大会出现某些人手上有一大堆东西要做，某些人却无事可做得情况了。
目前，我们的Bug管理也开始使用TaskVision了，虽然相比BugFree它没有那么方便，不过，毕竟统一了工具（统一的工具就好像统一的语言一样，可以减少学习的成本），更丰富的功能只好等以后慢慢加了。