配置审核的实施
 
配置管理（CM）是CMMI里最容易体现效果的过程域之一。一般开始从事过程改进的时候，项目的研发活动对很大部分的工作产品，产生很多很多的变动与修改，做成很多版本，最后就是一片混乱。进行过程改进之后，就实施了配置管理的变更控制。变更受控之后，工作产品与产品的版本就得到有效地控制，研发活动才可以有序地开展。所以配置管理是最早能够体现价值的一个过程域。
 
配置管理的早期效果，来自于变更和版本控制。但是很多配置管理人员对于配置管理很多概念，如基线、配置项、配置审核等等的了解还是有困难的。其实如果我们了解配置管理的目的，不太关注它的名词，反而更容易理念他的概念。
 
配置管理的最终目的，是保证产品的各个组成部件，就是说，产品的“配置”，都是匹配的。为什么产品的组成部件可能不匹配呢？这主要是错误的部件，或是错误的版本。错误的部件，是因为它们提供的功能、性能根本就不符合需求，或是接口细节不符合需求，造成部件之间不能兼容。就是部件都是按需求实施，但在修改的过程之中，导致产品的所有部件，不能同时满足同一个有效的需求版本。
 
配置管理可以理解为确保产品的所有部件，都跟有效（最新）的需求版本是一致的。
如何达到这个目标的方法，就是第一，要识别这个产品的所有部件，以及可以影响这些部件特性的任何工作产品，比如：需求、方案、设计、图纸、代码、编译工具，等等。这些就是“配置项”。我们需要在整个项目的过程中，尽可能控制所有这些配置项的变更，来达到它们之间都经常是一致的。
 
请留意，通常“项目计划”不是一个配置项。为什么？
 
另外一个考虑，是为什么要在整个项目的过程中保证各个配置项之间的一致性？我们到产品交付之前，一次过保证产品部件之间的一致性不就成了么？我们需要接受，最有效的方法，就是越早发现问题，越早处理好问题越好。最有效的意思，就是说如果不这样做，总体的工作量反而会比较大，效率比较低，后期时间紧迫，会造成很大的混乱。效率低的意义，就是周期会比较长。
 
这是一个非常基本的质量原则。所有的质量模型都会有这些要求。CMMI、TL9000等也是质量模型，所以都有同样的要求。文档记录、每个步骤都要求评审、自测试、等等，都是这个原则的体现。不习惯的话就觉得很烦，觉得是浪费时间。其实，这才是最节省时间的做法。这是一个我们一定要改变的观念与习惯，否则改进不能有效。
 
那什么是配置审核呢？
 
配置审核就是通过检查所有这些变更受控的配置项，是否都是相互一致的。
 
配置审核的种类
 
很多配置管理员都不很清楚配置审核的种类。在罗列配置审核的种类之前，我鼓励大家不要太关注这些种类的名称。要了解这些不同的配置审核，最好的方法是理解配置管理与审核的目标。我们现在有一堆工作产品，（配置项）放在库里（一个或是多个库），它们的变更是受控的。配置审核的对象，就是这一堆在库里受控的工作产品。
 
配置审核可以分成功能审核和物理审核。这两个概念，其实来源于项目的最终产品有关的两个议素（issue）：产品是否跟需求（和系统方案）一致，以及与产品的其他配套部件是否一致。
 
产品如果跟需求一致，那么，产品的功能就得到保证。所以配置审核中，检查产品与需求（和系统方案）一致的，就叫做“功能审核”。
 
在这个竞争激烈的时代，我们已经不能单单开发一个产品。我们需要有一个“产品配套”的概念。什么是产品配套呢？在产品本身之外，所有对提高产品有帮助的东西，连同产品本身，就是产品配套。最简单基本的配套，就是产品用户说明书、安装手册、维护手册，等等。检查这一堆配套的东西是否一致，就是“物理审核”。
 
这两个分类的重点，是不同组合之间的一致性。其他还有“基线审核”。“基线”这个概念，比较复杂，我会在其他的文章里讨论“基线”的概念。简单来说，“基线”只是库里配置项的一部分。它是受控库德一个子集。但是现在我们讨论如何进行配置能审核的审核对象，就是变更受控库里的配置项。
 
审查的过程意义和技术意义
 
很多配置管理员的困惑，就是害怕自己对项目的技术细节了解不够深入，不能保证配置项之间的一致性。这是一种从技术角度看问题的态度。这个非常自然。但是我们更需要一个过程的角度，否则就体现不了效率。
 
什么样的过程角度呢？举一个例子：CMMI要求同级评审，也要求QA审核。同级评审的目的，就是发现工作产品（评审对象）的缺陷，保证它的质量。这是一个从技术角度考虑的行为。基本上是项目本身的责任。QA的审查呢，如果发现技术缺陷当然应该要报告，但其实重点在于某个过程活动（在这里，是同级评审）是否符合标准规程，（记住：标准规程应该是明确了最有效的因素的规程）每一个不符合项，都产生了质量（产品质量、成本、周期）的风险。它如何从过程的角度来保证质量呢？它是检查这个活动是否充分体现了所有关键有效因素。比如：同级评审之前，评审员是否都看过需要评审的文档？评审员工是否熟识其中的关键技术与重点（用检查单保证），是否有足够的经验，评审速度是否过快？等等。没有充分体现这些关键因素，就是不符合。
 
所以要项目成功，有两个要点，它需要通过有技能的员工（技术），考虑并体现所有对效能有重大影响的因素（过程），来开展项目的活动。配置审核，是主要从过程的角度来保证受控库里的配置项的一致性。保证的方法，就是检查项目成员和CCB成员是否都体现了对一致性有重大影响的因素。比如：CCB做的波及分析是否到位？记录时候明确。多个配置项需要一起变更的，解决步骤是否协商、配合？变更是否按CCB要求验证通过才检入到库里？等等。
 
请留意，如果没有维护需求追踪矩阵表，或是维护了，但CCB没有使用，或是使用了，但使用的不正确，有遗漏，等等，都是从过程角度判断CCB的波及分析有问题。
配置审核也可以说是检查整个变更过程是否规范。我不爱用“流程”这个词，因为很多需要考虑的因素，是跟“步骤”没有关系的，如：人员履历、态度等等因素。
 
由此可见，配置审核的先决条件，是变更过程是规范的。CCB的工作是规范的，变更单的内容是规范的。这个很重要。
 
配置审核、同级评审、QA审查的分别
 
简单地说，同级评审是项目成员从技术角度保证质量，以发现技术缺陷为目的的项目活动。他的效果，就是这个项目团队所有的技术能力的最佳表现。同级评审的对象，是个别的工作产品。这个跟配置审核不同。
 
配置审核也是项目的活动，但是它关注所有配置项之间的一致性。这不表示其它项目成员的日常工作，不需要保证跟其他工作产品的一致性。每一位员工都需要这样做。但是配置审核是直接对一整套配置项之间的全面一致性进行的检查。配置审核的目的，就是希望得到“所有的配置项都是一致的”这样一个信心。如果发现不一致的地方，项目是一定要处理的。
 
QA审核呢，就是项目以外的活动。它需要这样才保证它的独立性。主要的目的，是反映项目执行规程的符合程度，从而通过提高符合度来保证项目的过程与产品质量。他的检查，不一定是全面的，可以是抽样的。只要能够保证项目质量就可以了。同时，QA因为不是项目的一部分，它需要高层的支持才能有效。
 
配置审核的层次
 
虽然说配置审核是从保证变更的规范性来保证其一致性，但是如果能够考虑技术内容，效果自然会比较理想。所以从CMMI的角度，过程的要求，要过级，最低限度需要检查所有的变更请求记录，验证它们的规范性，并且是与配置库的检入活动是一致的。比如：变更请求单里，说明要修改这个文档，但是检入的是其他的文档，等等。这是最低层次的配置审核。
 
深入一点的，就会遇到需要技术判断的情况。这个时候，配置管理员可能有这个能力，但未必所有都具备这个能力。这个情况，配置管理员只能要求项目成员帮忙。我的经验，大家不习惯要求人家帮忙。这是一个非常低效的习惯。所有员工，都应该知道团结一致，为项目的高效完成任务努力。我们需要养成这个习惯（你看，流程解决不了这些问题。这是一个“过程”的因素）。我要强调一下，这个层次，不是说要求配置管理员推翻一个变更验证的结论。这样的纯技术问题，最好是项目人员负责决定。
 
最高层次的配置审核，就是一个不成熟的项目，到非常混乱的情况之下，要把所有的工作产品理顺。这一定要求非常有经验，有能力的配置管理员，协同骨干项目人员，同心协力，才能处理好这样的问题。
 
在项目里，什么时候要做配置审核？
 
最好是定期做。比如每星期做一次。项目开始的时候，控制不需要这么严格。越接近发布，审核就要越严格，因为大家已经没有多余的机会让问题延误了。
其他，每次构建，都应该做一次。我们不希望构建是徒劳无功的。发布之前要做一次。
 
如果大家有任何意见和问题，欢迎给我邮件。