软件配置管理中的10个常见错误

文章来源：临沂软件开发添加时间：2024-5-11 11:12:03 浏览人数：

什么是配置管理？配置管理是通过技术或其他手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。

配置管理的主要目的是进行工作产品管理，为了见证产品的演化过程，确保产品开发在软件生命周期中的各个阶段都能得到良好的产品配置。其中包括：各类文档、源代码、规范、bug等等。配置管理的主要活动包括：制定配置管理计划、配置项识别、建立基线、建立配置管理系统、版本管理、变更管理、配置状态报告和配置审计等等。

从上面的描述，我们可以看到配置管理在日常工作中的重要性，它贯穿了整个项目的实施周期，也涉及大量的组织干系人。配置管理的成功使用，可以大量降低研发因为代码或文件版本问题造成的沟通成本。

配置管理能够完整覆盖整个软件生命周期，以及所有重要的工作产出，可见配置管理并不是配置管理员一个人的事，而是与所有项目成员息息相关。它通过工作产出，将过程管理与人员管理关联起来。

不同的组织在实施配置管理活动中常常会产生一些错误认知或错误的行为，今天我们主要就来看一看这些问题：

项目经理兼职配置管理员

很多公司存在这样的情况，为了节约成本，多人兼职，甚至让项目经理兼职配置管理的工作，其实这是得不偿失的。配置管理工作中除了一些事务类工作外，也有一些周期性的工作，这要求对配置管理工具要熟悉。

项目经理的时间本身也被各事务分摊，需要集中主要力量解决项目的主要工作，例如，对接客户需求，执行项目计划，保证项目质量等，如果太多配置管理繁杂的事情让项目经理来处理，会得不偿失，精力也很难顾及，最终影响项目的交付进程。

配置管理方案不完善

很多组织认为有了配置管理员，有了一套配置管理系统，就可以开展配置管理工作了，实际上这远远不够。配置管理需要一整套完善的方案，包括执行计划，权限设置，配置审计，基线建立，变更管控，备份机制、主干分支方案、构建方案等。这些方案都需要被完善的定义，并且被真正地执行，同时所有的执行都需要有完备的记录和检查机制。

配置管理版本管理混乱

规模较大、周期较长的项目，可能存在配置管理版本混乱的问题，甚至由于文档缺失、人员更替而连代码的历史版本也不清楚，这会直接加大变更分析及确定变更后版本管理的难度。从根本上解决结构混乱问题，需要整理配管理结构，清晰定义多版本、多分支的配置管理，定义清楚编码与测试d等人员的角色职责、工作流程等。

项目无基线，前后端无法对应

基线是下一阶段的工作指南和重要参考，没有基线就没有比较。例如，每次更新进度计划表或版本计划的时候，就要与之前的版本进行逐一比较，查看存在的差异，分析为什么会出现差异并将问题记录下来，下次再出现类似的情况就会把这个差异考虑进去。

再如，每迭代一次的代码，通常也会建立不同的基线和分支，其目的是不仅分清不同阶段的代码。基线可以帮助项目经理管理好需求、代码版本等，达到进行整体监测和控制的目的。

因此，当重大计划更改时，项目经理需要保存新的基线。建立变更控制管理流程，一旦出现变更，需要对原来的基线进行备注说明，例如变更内容，影响等。

基线变更流程未做严格控制

基线一旦建立，一般情况下我们不随意进行变更，如果基线需要变更，需要对变更进行详细的影响分析和判断，不能仅仅评某个项目组成员或者项目意愿就进行变更，需要组织CCB进行综合评估，充分判断其变更原因，做好影响分析及后续的影响评估，一旦确定基线需要变更，同步通告相关干系人。当然变更的流程应该制定的更加便捷快捷，同时又能确保变更流程的科学性和合理性，以响应需求的变化。

CCB人员配置不合理

CCB即配置控制委员会，在CCB人员定义的时候，重要的是考虑人员覆盖，而不是追求人数。在组织过程改进中，CCB不仅要负责基准建立和变更的审批，还要负责合同、资源、成本、技术等方面的审批，它的作用范围不是仅局限在配置管理上，而是整个项目，CCB应由来自不同领域的项目利益相关者的代表组成，而且有能力在管理上做出承诺。

CCB一般由部门管理者、商务人员、项目经理、开发负责人、测试负责人、质量保证、配置管理人员等成员组成，不同层次、规模的项目，CCB人员构成也不尽相同。

变更控制混乱

配置管理活动中，不管是文档的开发，还是代码的编写，都需要跟踪执行变更管控流程。在一些组织里面经常看到“人性化”的一幕，一些系统代码的修改有时候靠得是“哥俩好”，内部这种传话式的沟通和工作安排，在没有严格执行变更流程的前提下都是不被认可的，也是不允许的。

有的变更控制，修改哪些，增加哪些，减少哪些，都需要科学执行管控流程，不能因为我们关系好，就可以直接跳过流程，由此产生的所有问题都要被记录NC，严重时需要记录NC并执行上升机制。

文档与系统不对应

我们经常也看到这样的场景，系统马上要交付了，但是找不到与之匹配的用户文档，或者在给客户培训的时候，发现培训的文档版本与实际交付物存在明显的区别，这些都是因为文档与系统对应关系没有做好。对配置管理熟悉的都知道，系统和文档通常都是一一对应的。所有系统的变化，与之对应的系列文档都需要同步进行更新，同时也需要备注修改履历，其主要目的是能够在需要的时候进行追溯，保证使用正确的文档版本。

回归测试入库无确认

代码管理是配置管理环节中的重要一环，组织要求所有代码入库都需要经过严格的测试，需要编写测试用例，有严格的进入退出准则。但是也有很多组织忽视了一个重要环节，那就是回归测试。一些回归测试完成的代码被直接入库，这里缺少了重要一环就是与代码、需求人员的确认，没有关注回归测试之后是否产生了关联问题，忽视了最终回归测试代码入库也需要经过确认这个环节。

持续培训不到位

公司配置管理的相关培训不是一劳永逸的，很多组织在实施过程改进初期有很多培训，技术的，流程的，制度的，工具使用的等，但是到了改进中后期，培训就停滞了。大多数公司里面一定会有部分人员离职，也会有新人入职，新旧血液的交换，同样需要我们不间断地进行这些通用类技能和工具的培训，以保证公司的制度、流程改进是被有效宣贯和持续执行的。

良好的配置管理是项目成功的重要保证。从以往的研发管理咨询经验来看：项目中有很多问题是由于配置管理没有做好导致的，根本原因是很多人不了解配置管理，不清楚配置管理的意义和作用，配置管理是可以覆盖到整个软件生命周期的全部重要产出，并且它还能解决很多其他常见问题，最重要的是要规避上述的这些常见错误。

想要了解更多详情欢迎来电咨询18678812288，或登陆网址www.rzydkj.com。联系人：王经理。

新闻中心