记录有关大连软件开发评审的执行情况。这几句话没有错。团队活动总是需要一份计划，活动形式也需要事先规划好，结果也需要记录一下（否则，要犯同样的错误）。有谁会对此心存疑议呢？可是，当看到这些活动的“一般性”规定时，很多人产生了抵触情绪。例如，在讲到文档化的规程时，CMM上是这样说的：由经培训的同行评审领导者计划和领导同行评审。预先将评审材料散发给评审者，以便他们能为同行评审作好充分的准备。已对评审者分派了在同行评审中的任务。详细说明和执行用于同行评审的准备就绪准则和完成准则。使用检查单，以便以一致的方式确定用于评审软件工作产品的准则。

大连软件开发评审中所确定的问题，直至它们得到解决。同行评审的成功完成。包括解决同行评审中所识别出的问题的返工，被用作为相关作业的完成准则。这些“一般性”规定涉及了不少文档和事务性的工作，例如，评审材料、检查单、跟踪表等。再加上质量保证这类如影随形的活动，所以做一次同行评审似乎非常麻烦。还有更麻烦的。有些办公软件开发组织对同行评审活动是这样定义的：项目开始后，每两天进行一次同行评审，并且要提交详细的报告。你会疯掉吗？可是，如果我告诉你，上面的活动一样不做，也是同行评审，你相信吗？

在遵循CMM核心思想的前提下，变通是无限的。CMM的核心思想是：过程，要事先定义（否则是无政府主义）；过程的实施效果，要不断验证（可以持续改进）；过程中的基本活动形式，要保证（你不会排斥同行评审本身吧？）。假设，你正在做3个人月的小项目。你的同行也是做大连软件开发评审项目的，就是找个身边的同事讨论10分钟（也许你需要和他的团队打个招呼）。如果这是最好的形式，把它定义下来。你得通过文档，告诉所有参与此类规模项目的软件开发人员，不要干扰其他人的工作了。可是，如果那些和身边同事的讨论没有给你带来实质性的帮助，你可能就需要换个形式了。很显然，新的形式应该替换旧的形式，并定义到组织级别的过程中去。