编者按：
CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域，笔者将通过系统性的梳理、浅显易懂的文字描述，同时结合笔者的思考和观点，对每个实践域的目标以及所基本涵盖的内容进行描述，希望能抛砖引玉、相互碰撞，燎原出契合读者各自心中的答案。
目录/CONTENT
01 策划PLAN
02 风险与机会管理RSK
03 估算EST&监视与控制MC
04 组织级培训OT&供应商协议管理SAM
05 需求开发和管理RDM
06 验证和确认VV&同行评审PR
07 技术解决方案TS&产品集成PI
08 原因分析和解决CAR&决策分析和解决DAR
09 配置管理CM
10 过程管理PCM&过程资产开发PAD
11 管理性能和度量MPM
12 治理GOV&实施基础条件II
13 过程质量保证PQA
CMMI2.0之我见-配置管理CM
市场大环境下的激励竞争，频繁的人员流动，组织内部如果没有必要的配置管理流程和工具，大量的文档、代码、经验、数据等知识财富必将很难进行复用和有效管理，数据、文档、资料则会是随意地保存在项目经理和项目开发人员各自的电脑中，因此有时我们会看到因为硬盘故障或人员离职，导致资产永远消失的惨痛案例，组织的过程财富就这样因为缺乏必要的配置管理而流失。
何为配置管理？配置管理是通过技术或其他手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。
配置管理的主要目的是进行工作产品管理，确保产品开发者在软件生命周期中的各个阶段都能得到良好的产品配置。其中包括各类文档、源代码、规范、bug等等。
但不要简单理解为，配置管理就是版本管理，配置管理是所有工作产品的管理。通常配置管理的主要活动包括：制定配置管理计划、配置项识别、建立基线、建立配置管理系统、版本管理、变更管理、配置状态报告和配置审计。
在CMMI2.0中对配置管理又有新的诠释和变化，例如：去掉了配置状态记录，重点强调了配置控制的方法，将配置控制明确为版本控制和变更控制。再如：对基线的阐述不仅仅有软件基线，2.0也新增了硬件基线，这给软硬件一体项目实施的组织提供了理论基础。
何为基线？基线可能对刚刚执行过程改进的组织来说比较陌生，基线是一组状态已经固化的配置项。设置基线的目的简单来说是让项目组能够使用同一组正确且稳定的工作产物。通常，我们在项目实施过程中会制定几条基线，例如需求基线，开发基线，产品基线等。基线的建立和变更需要经过CCB（变更管理委员会）严格的审批，通常不能随意变更，特别是在开发阶段，如果基线发生变更，代码务必要进行回归测试，只有这样，基线的内容才是可控的，基线也才是真正的被管控起来。
配置管理活动覆盖了整个软件生命周期，也覆盖了生命周期中所有的工作产品，所以这个活动会涉及很多的干系人，彼此工作都是相关联的，并不是简单说是某个配置管理员的工作，一定是通过这些工作产出，将过程管理与人员管理关联起来。我们可以设想一下一个组织如果缺少配置管理活动，项目管控会变成怎么样的？下面的场景大家一定不会陌生：
① 在日常的开发工作中，经常会出现并行开发的需求，这种场景下，不同开发人员可以同时编辑修改某一文件，主要目的是为了提高开发效率，但是这种协同极有可能产生冲突和矛盾。如果没有配置管理工具的支持，进行并行开发将十分困难，单单通过人工操作，往往会造成修改过的bug 重复出现或者几个人进行相同的工作，产生不必要的浪费。
② 在项目的联动性方面，部门主管会无法确切得知项目的进展情况，项目经理也不知道各个开发人员的具体工作完成情况，项目进展随意性很大。所有的问题往往都会集中到项目里程碑时一起出现，这必然会造成巨大的成本浪费，结果往往是产生大量的缺陷或者延误开发周期。
③ 没有配置管理流程的组织，软件复用的效率将大打折扣。我们知道软件资产是组织的重要财富，软件复用是提高软件产品生产效率和质量的重要手段。代码的可重用性是相当高的，如何建好知识库，用好知识库将对公司优质高效开发产品产生重大的影响。
如果缺少有效的配置管理，代码的复用管理就无法进行，开发人员也会各自为政，缺少统一的规范要求，后续会产生返工工作量，如果只通过手工的方式寻找想要的代码，效率如何可想而知。同时在产品发布时无法确定该版本所有的组件，或者向用户提供了错误的版本，势必会造成客户满意度低下，对组织的专业度认知给出负面评价。因为不同代码版本也会导致后期维护极其复杂，程序的可维护性也会越来越差。这些都会延长实施的周期，同时意味着人力、物力的浪费。
④ 配置库没有定期和异地备份。举个例子，之前服务过一家公司，配置管理整体做得还算基础，有兼职的配置管理人员，有一套配置管理工具，所有的一切都按照所规定的要求在做。突然有一天中了比较流行的勒索病毒，所有的文档和配置库文件都打不开了，项目组成员非常恐慌，一旦既成事实，带来的影响是巨大的。好在他们的配置管理要求比较严格，除了本地做了备份，在异地的分公司服务器上同步做了异地备份。这种备份成本的投入带来的收益有可能会一直沉默，但是只要发生一次，它就是功不可没。这家公司很快通过异地服务器备份，恢复到了中毒之前的代码和文档，给公司挽回了不少经济损失。如果这个事情发生在没有很好的配置管理的公司，损失必然是惨烈的，所以配置管理的工作我们不要小看每一步，每一步都不容小觑，都要足够重视。
良好的配置管理也提供了收集软件开发历史数据的重要来源。从以往的研发管理咨询经验来看，项目中有很多问题是由于配置管理没有做好导致的，根本原因是因为很多人不了解配置管理，不清楚配置管理的意义和作用。配置管理是可以覆盖到整个软件生命周期的全部重要产出，并且它还能解决很多其他常见问题，比如：配置管理可以通过协调项目中不同人员的工作产品，来帮助我们降低这些问题发生的风险；需求、设计等软件工程文档不一致性；无法还原或者找到工作产品的上一个版本；产品运维或交付后找不到之前的相关资料；文档和代码的权限管理，不让权限以外的人随意对文档有增、删、改、查的操作…….
当然，配置管理领域的知识还有很多，比如配置审计、自动化构建、持续集成等等，本文主要结合CMMI2.0的一些基本实践要求来阐述，希望能抛砖引玉带给大家一些思考。
最后我想说，做好配置管理需要有配置管理专员，也需要专业的配置管理工具。目前市面上可以选择的配置管理工具有很多，各个组织可以根据自身的实际情况去采购，同时这些工具也需要在全公司进行推广和培训，让整个项目组成员都能熟练地使用这些配置管理工具，真正做到工欲善其事必先利其器！
原创文章，如若转载请先联系我们。
关注微信公众号”赛希咨询“，了解更多精彩内容。
