如何制定同行评审（这里单指针对代码的同行评审）的计划呢？首先，大连软件设计人员在设计时，对于算法实现的难易程度，应该是心中有数的。在这个前提下，设计人员可以标记出需要进行同行评审的位置。其次，可以参考程序员本身的业务水平，来制定同行评审的计划。例如，有经验的程序员，或多次被证明合格的程序，在没有明确求助的情况下，没有必要进行强制的同行评审。反之，对缺乏经验的程序员，则需要加以关注。

如何进行同行评审活动呢？如果，你的组织拥有先进的设备，那么，白板上的结论，或许可以直接保存为同行评审的报告。另外，定义了简单格式的邮件可以作为报告，结对编程的代码也可以作为报告。报告存档的意义，不在于应对质量检查。它的意义在于，将来有可能从这些档案中提炼出有价值的信息。那些有价值的信息，将成为组织内的知识资产的一部分。关于知识资产的话题，我们会在第10章中展开讨论。总之，当我们不断产生关于同行评审的问题，不断思考它们，并给出解答，然后验证解答，然后再次给出解答的过程，就是我们的软件开发能力成熟的过程。 CMM建议，有价值的过程应该被记录下来，并在实践活动中完整地验证。相比于那些没有任何记录、重复讨论、人走茶凉的垃圾会议，CMM的做法不值得赞许吗？

只有成熟的大连软件设计开发组织，才能快速适应组织规模的变化，才能持续不断地递交成功的项目成果，才能最大限度地降低软件团队开发的成本。 CMM提供了成熟度评估模型。这个模型，可以帮助软件开发组织，围绕着软件开发过程这条主线，通过各种有价值的活动，最终达到软件开发能力成熟的目标。 我相信，在我们这个美丽的星球上，有不少值得尊敬的、成熟的软件开发组织。遗憾的是，我至今还未接触到它们。 这使我充满了幻想。 在软件开发实践中，我们经常会遇见这样的场景。

在项目进行过程中，由于某些原因，项目无法按时完成。于是，为了确保及时交付产品，项目经理会提出两种方案：加班或加人手。高一级的经理会对这种做法表示赞赏。因为在项目出现延期风险时，项目经理采取了相应的对策。 接下来，项目经理召开了多次会议，讨论软件开发人员的工作安排。由于公司可以提供的资源是有限的，所以往往采用加班这个方案。类似的会议不断地召开。 最终，项目延期了。显然，偶尔出现这种场景是正常的。可现实的情况是，这种场景几乎出现在公司的每一个项目当中。我认为，频繁出现上面的场景就是一个大连软件设计开发组织不成熟的特征。