CMMI软件成熟度模型评估之七：配置管理与变更控制

1、看似最不起眼，实则最容易翻车

配置管理和变更控制，在成熟度模型里属于“基础建设”。它们不像战略对齐那么高大上，也不像技术方案那么炫酷，但恰恰是这两个看似不起眼的领域，最容易在评估中暴露出大问题。

我见过太多企业，需求管理做得像模像样，开发过程也有板有眼，但一到配置管理就原形毕露——版本混乱、基线不清、发布随意，整个研发体系就像建在沙滩上的城堡，一推就倒。

2、配置管理：别让“版本地狱”吞噬你的团队

配置管理的核心就三件事：识别、控制、审计。识别是把所有配置项梳理清楚——代码、文档、数据库脚本、配置文件、第三方组件，一个都不能漏。控制是建立基线管理机制——哪些代码属于哪个版本、哪个版本对应哪个发布，条理清晰。审计是定期检查配置项的完整性和一致性。

很多团队之所以陷入“版本地狱”，是因为在这三件事上打了折扣。最常见的场景是：紧急修复了一个生产问题，但修复的代码只部署到了生产环境，没合并回主干，也没同步到测试环境。下次发版的时候，这个修复又丢了，生产问题再次爆发。这种情况反复几次之后，整个团队的士气就被拖垮了。

2、建立规范的配置管理，没有那么复杂。

核心就两条：

第一，建立唯一可信源，所有变更都通过版本控制系统管理，主干始终处于可发布状态；

第二，建立发布流水线，从代码提交到部署上线的每一步都自动化、可追溯。

3、基线管理，让“乱成一锅粥”成为历史

基线是配置管理中最重要的概念。简单说，基线就是一组配置项在某个时间点的“快照”，经过评审和批准后，作为后续开发的基础。需求基线、设计基线、代码基线、发布基线，各有各的用途。

建立基线最直接的好处是“有据可查”——你随时可以知道，某个版本的系统包含了哪些需求、哪些代码、经过哪些测试。项目出了问题，回溯也快。很多企业没有基线管理的意识，开发到后面连“上线的是什么版本”都说不清楚，评估的时候自然没法过关。

4、变更控制：不是拦路虎，而是安全带

变更控制常常被误解为“阻碍变更的流程”，这是大错特错的。变更控制的目的是让变更有序、可控，而不是阻止变更。

我做咨询时帮企业设计的变更控制流程非常简单：变更请求提交-影响分析-决策审批-变更执行-验证确认。核心在“影响分析”这一步——评估变更对进度、成本、质量、风险的影响，让决策者掌握充分信息后再做决定。流程简单了，大家就愿意走；流程搞得太复杂，大家就会想办法绕过去。

5、变更控制委员会的设置

高成熟度的组织会设立变更控制委员会（CCB），由项目各方代表组成，负责审批重要变更。CCB的组成和权责要在项目启动时就明确，而不是变更来了现凑人。

对于紧急变更（比如生产环境严重故障的修复），可以设立紧急审批通道，由授权人在规定时间内快速决策，事后补录完整记录。这样既保证了灵活性，又保证了可追溯性。

6、配置状态报告，让你的体系“看得见”

最后说说配置状态报告——这是很多人忽略的一个环节。配置状态报告定期发布，告诉项目组和干系人当前配置项的状、基线状态、变更状态。一份清晰的配置状态报告，是项目管理透明度的直接体现。

评估的时候，我只要翻一翻配置状态报告，就能大致判断这个项目的配置管理水平。如果连报告都拿不出来，那说明配置管理基本处于“无政府状态”。

厦门格略咨询，企业资质一站式服务平台。13年专业咨询公司，3000+服务案例累计；服务内容：各类ISO体系辅导，CMMI辅导，DCMM辅导，FSC辅导、IATF16949辅导，各类补贴项目申报。

地址:厦门火炬高新区软件园三期集美大道1997号608室

联系电话：0592-6270869

公司官网：www.fjgelue.com