本人经历过CMM2、CMM3、CMMI4和5，随着对CMM的理解的深入，越发产生了深层次的思考。CMM对我个人影响也很大，的确有很多好的实践和理念供我们学习和借鉴。本文不是全面否定CMM，而是从批判的角度审视我们对CMM的认识。

度量的目的主要是实现精细化的管理、有效地对项目进行控制，对度量数据的分析用于辅助决策、经验积累、有效评估等。但是度量本身就是双刃剑，一方面度量对于精细化管理是必要的前提，另一方面度量体系、度量的执行需要花费大量的人力成本，而且如果没有明确的目标和有效的方法来分析和利用这些数据，度量就又陷于无谓的劳民伤财，成为组织过程的累赘。 很多企业的度量陷于盲目，导致了很多负面的影响，进而影响整个组织对项目管理体系的理解和信任。

如何才能建立起规范化的文化呢？我想不同的组织和不同的人的答案肯定是不同的。我的经验就是：加强宣贯，不断强化，建立共识，形成习惯。

2004年底在大连出差的时候，帮一个项目做测试，顺便写下这个检查表，这个检查表对测试的初学者积累经验比较有用，实际对于有经验的测试人员尤其对于测试业务管理信息系统，基本上大量的测试不需要再编写测试用例，当然对业务流程、复杂逻辑还是要设计详细的测试用例的。如果你测试的系统是有大量人机交互的业务管理信息系统，而且你又比较懒惰，那就可以使用这个检查表检查了。 因此我总结了这类系统中常用的测试的检查项，供当时项目组的测试人员使用，现在再次整理出来发于博客。

做好需求是一个软件项目成功的一半，尤其对于业务管理系统更是如此。如何更好地获取需求和分析需求，本文介绍个人的方法，不是阳春白雪的方法论，也没有很深的理论术语，但是却是很实用，供大家参考。

以前的CMM的QA是只关心过程质量，由此也是众多的咨询师也是众口一词，对此也没有置疑。还是在2001年在做CMM的时候我就觉得至少在国内这些过程还不成熟甚至没有过程的软件企业（通过了N级并不代表过程真正的成熟）是难以实现的，最后导致的结果就是做CMM的时候QA在公司还比较重视，做完CMM了，QA在公司就难以生存，纷纷或跳槽、或转到测试、配置和项目管理上去了。

对代码的质量控制一直是保证最后产品质量见效最快、也是非常关键的环节，我在去年的一个大型项目中，对于代码的控制是基本做到了每日检查，即开发人员在每天完成代码的编写和调试后提交到配置库中的时候要先进行自测检查，自测完成后由组长对代码进行走查。通过后的代码才可以提交BUILD。下面就给出我们的检查单，方便开发人员个人和组长对代码的检查用。

在软件测试过程中，测试数据的准备是一个工作量很大而且也是一个技术活。因此如何准备大量的测试数据，而且如何准备高质量的测试数据，满足测试的需求，就是一个重要的话题。

我作为项目经理一直是标榜自己是以质量为导向的项目管理的倡导者和身体力行者，为何这样提呢？也是基于自己做过的成功的项目的经验得来的。 在项目管理的三要素TQC中，这三者在项目管理中是需要平衡的，但是更需要明白他们并不是平等的，为什么这么说呢？这也是因为软件项目的特点引起的，关于软件的项目管理的特点参见我的博客中关于CMM的文章的描述。在软件项目中进度的延迟和成本的增加很大程度上是因为质量引起的，系统的质量问题往往会导致返工，在软件项目中返工已经成为项目经理的恶梦。而返工的直接后果便是进度的拖延和成本的上升，当然还会导致团队人员的沮丧、挫折的心理，这当然都会影响到开发的效率。

对于一些大型项目的中后期，或者产品化项目，很难按照正常的生命周期模型来开发，这类项目的特点就是开发模式是任务触发型的，而不是需求或者计划触发型的，因此应对的方式建立一种以变更为核心的开发管理模式是非常实用的。