2.2 CMM的精髓

2.2.1 过程定义

CMM（Capability Maturity Model，能力成熟度模型）对软件开发过程的关注是其最重要的贡献之一。能力成熟度越高，说明软件开发过程越成熟。成熟的软件开发过程，是一个软件开发组织进行团队开发的基础，而如何运用软件开发过程，则是保证团队项目持续成功的关键。

对于软件开发组织来说，无论是否实施CMM，软件开发过程都是存在的。

什么是过程呢？举个例子。

如果你现在打算去钓鱼，那么有一系列的事情要做。

首先，要确定地点。你打算野钓还是塘钓？海钓还是江钓？通常情况下，你会从以往的经验中找一个地方。由于很多塘钓点会按天（或按斤）计费，所以，经济因素也是确定地点前要考虑的。

确定地点之后，要计划一下交通路线和交通方式。

然后，要确定时间，为此你可能需要关注一下天气预报。

然后，你要准备钓鱼装备。根据地点不同，选择不同的鱼竿。鱼线、鱼钩、浮标这类的小装备就不用多问了，你可以带得很全。如果夜钓，需要照明工具以及带灯光的浮标。此外，可能还有一些常用的装备，像杆包、钓箱等。

接下来，根据目标地点的鱼的种类，例如，鲤鱼、鲫鱼、草鱼等，你可能会在家里自己配制不同的饵料，也可能直接从渔具店购买商业包装后，简单加水混合即可。

到了目的地之后，一般需要找一个固定的钓台。你先要在这个钓台前方的水域中打窝抛饵。吸引鱼群进入你的钓区。一段时间后，你要试杆调标。根据鱼群活动的垂直区层，确定钓底、钓中还是钓面的战术。你要做一些试验，揣测并验证鱼群今天最喜欢的口味，高手可能还会现场调制饵料。

最后，你开始钓鱼。

以上就是钓鱼的过程。很有趣，尽管我们的目标是钓鱼，却需要做很多相关的事情。这些事情都是一些经验知识。随着钓鱼经验的增长，这些知识可能会不断被修正，变得越来越合理，越来越成熟，最终越来越容易帮助我们完成钓鱼的目标。

尽管在钓鱼过程中很少有人去系统地思考这个过程，但是，这个过程是存在于人们的意识中的，以一种不是很严密却根深蒂固的方式存在着。

和钓鱼一样，软件开发存在着类似的过程。不同的是，软件开发通常需要团队成员的协作，换句话说，那些和软件开发相关的事情，是由不同的人完成的。而且，一件事情的完成情况，可能会影响另一个人正在做的另一件事情。

在这种情况下，仅仅依靠个人的想法，片面决定自己的工作内容，就可能会对团队目标的实现造成负面的影响。

有一种例外情况，如果团队成员非常稳定，而且他们在长期的共事中形成了一种默契，也许不用过多强调过程的意义。

当人们需要共同完成一件事情时，常常需要一些契约来规范人们的行为。在软件开发中，这些契约以过程的形式存在着。

为了使契约更加合理，软件开发组织需要对过程进行系统地思考和总结。这是一种持续的行为。另外，在软件开发实践中，过程会不断地得到优化。那些更合理的过程，会被保存下来并重复使用，最终成为知识资产的一部分。

在理想的情况下，CMM所关注的软件开发过程，应该是解决软件开发中各种混乱现象的一种理想方案。但是，在现实中，CMM往往被很多软件开发组织、甚至软件开发人员个人所排斥。有一种说法是这样的。因为软件项目的计划经常受各种不确定的因素干扰，所以，要保证严格遵守繁琐的过程是不现实的。

这种想法是错误的。

在软件开发实践中，我们经常会遇到很多模糊的反对意见。在不成熟阶段产生的判断，被固定成一些错误的想法，而这些错误想法，又会阻止一切迈向成熟的尝试。糟糕的是，这些反对意见往往来自掌握话语权的软件开发人员。

这有点像司法中的“有罪认定”。原告（反对者）没有举证的义务，当他指控一个人或一件事的时候，只需要一分钟的时间。这有点不公平。虽然我并不完全认同CMM，但是，我仍然非常感慨。因为这种“有罪认定”，很多软件开发组织甚至放弃了尝试了解CMM的机会。

我一直认为，排斥CMM是错误的。CMM中包含了很多有价值的想法，尽管它很少提及人的因素（在敏捷软件开发中，人的因素得到了充分的关注，甚至有被夸大的嫌疑）。

开源软件的开发过程，几乎不用考虑人的因素，这并不代表个人因素不重要，而是因为人们的想法简单而统一。

开源软件的开发人员，常常以一种松散的形式组合在一起，兴趣爱好是他们最主要的驱动力。对于这样的组织来说，过程可以最简化，只需要保留减少混乱、提升效率的活动，而剔除在缺乏主动性的情况下进行约束的所有内容。

有哪些有价值的想法呢？

首先，CMM对于软件开发过程的关注是系统性的。在CMM中，定义了质量保证、配置管理、需求管理、项目管理、软件开发管理、同行评审、项目资源协调、人员培训等概念，涉及软件开发过程中方方面面的活动。

其次，CMM推荐了大量被证明有效的活动，并把它们纳入一个模型中。在这个模型中，CMM定义了这些活动的类型，以及先后次序和依赖关系。

最后，CMM鼓励软件开发组织基于模型和推荐的活动来定义自己的软件开发过程。CMM会依据规范来评估自定义的软件开发过程，换句话说，CMM是一个参考模型，它不要求软件开发组织严格遵守。CMM只是建议，在软件开发组织自定义的活动和CMM规范推荐的活动之间做一些映射。这些映射可以非常灵活。

我很少看到有人提及最后这一点。这也许是很多人对CMM产生错误印象的原因之一。在我看来，CMM所倡导的灵活实践，使它的老学究形象平添了一份可爱。

我认识一位SEI认证的CMM评估师。在与他的交流中，我深刻地体会到，CMM其实是一个非常灵活的模型。

事实上，只要有想象力和创造力，你定义的软件开发过程，将会完全适合你的组织现状和企业文化。你可以为不同类型的项目定制不同的过程，从而最大限度地提升工作效率。

有兴趣的读者可以去阅读相关的参考书。

为了进一步了解CMM的灵活性，我们不妨来谈谈CMM中的同行评审活动。

同行评审是我非常推崇的一项活动。通过同行评审可以及早发现软件开发工作中的一些失误，可以及早为一些问题找到解决方案。

CMM建议，同行评审应该执行这样一些活动：

• 计划同行评审，并将计划写成文档。
• 按照已文档化的规程进行同行评审。
• 记录有关同行评审的执行情况和结果的数据。

这几句话没有错。团队活动总是需要一份计划，活动形式也需要事先规划好，结果也需要记录一下（否则，要犯同样的错误）。有谁会对此心存疑议呢？

可是，当看到这些活动的“一般性”规定时，很多人产生了抵触情绪。例如，在讲到文档化的规程时，CMM上是这样说的：

• 由经培训的同行评审领导者计划和领导同行评审。
• 预先将评审材料散发给评审者，以便他们能为同行评审作好充分的准备。
• 已对评审者分派了在同行评审中的任务。
• 详细说明和执行用于同行评审的准备就绪准则和完成准则。
• 使用检查单，以便以一致的方式确定用于评审软件工作产品的准则。
• 跟踪同行评审中所确定的措施，直至它们得到解决。
• 同行评审的成功完成。包括解决同行评审中所识别出的问题的返工，被用作为相关作业的完成准则。

这些“一般性”规定涉及了不少文档和事务性的工作，例如，评审材料、检查单、跟踪表等。再加上质量保证这类如影随形的活动，所以做一次同行评审似乎非常麻烦。

还有更麻烦的。有些软件开发组织对同行评审活动是这样定义的：项目开始后，每两天进行一次同行评审，并且要提交详细的报告。你会疯掉吗？

可是，如果我告诉你，上面的活动一样不做，也是同行评审，你相信吗？

CMM提供了“裁剪”的概念。在遵循CMM核心思想的前提下，变通是无限的。

CMM的核心思想是：过程，要事先定义（否则是无政府主义）；过程的实施效果，要不断验证（可以持续改进）；过程中的基本活动形式，要保证（你不会排斥同行评审本身吧？）。

假设，你正在做3个人月的小项目。你的同行评审活动，就是找个身边的同事讨论10分钟（也许你需要和他的团队打个招呼）。如果这是最好的形式，把它定义下来。你得通过文档，告诉所有参与此类规模项目的软件开发人员，不要干扰其他人的工作了。可是，如果那些和身边同事的讨论没有给你带来实质性的帮助，你可能就需要换个形式了。很显然，新的形式应该替换旧的形式，并定义到组织级别的过程中去。你的实践经验应该被记录下来，免得重复发生无效的活动。不就是这样的吗？

针对同行评审，我们继续往下思考。

如何制定同行评审（这里单指针对代码的同行评审）的计划呢？

首先，软件设计人员在设计时，对于算法实现的难易程度，应该是心中有数的。在这个前提下，设计人员可以标记出需要进行同行评审的位置。

其次，可以参考程序员本身的业务水平，来制定同行评审的计划。例如，有经验的程序员，或多次被证明合格的程序，在没有明确求助的情况下，没有必要进行强制的同行评审。反之，对缺乏经验的程序员，则需要加以关注。

如何进行同行评审活动呢？

如果，你的组织拥有先进的设备，那么，白板上的结论，或许可以直接保存为同行评审的报告。另外，定义了简单格式的邮件可以作为报告，结对编程的代码也可以作为报告。

报告存档的意义，不在于应对质量检查。它的意义在于，将来有可能从这些档案中提炼出有价值的信息。那些有价值的信息，将成为组织内的知识资产的一部分。关于知识资产的话题，我们会在第10章中展开讨论。

总之，当我们不断产生关于同行评审的问题，不断思考它们，并给出解答，然后验证解答，然后再次给出解答的过程，就是我们的软件开发能力成熟的过程。

CMM建议，有价值的过程应该被记录下来，并在实践活动中完整地验证。相比于那些没有任何记录、重复讨论、人走茶凉的垃圾会议，CMM的做法不值得赞许吗？