转给大家一起分享!
如何摆脱配置管理的尴尬局面(摘自《程序员》）
在质量体系的诸多支持活动中，配置管理处在支持活动的中心位置，然而现实的配置管理一直在项目中处于尴尬的地位。如何才能使得配置管理在项目管理和质量管理中成为“主角”？通过个人的经验，我认为配置管理只有深入到项目中，参与到项目管理和质量管理活动中，这样才能是配置管理做的有声有色。下面结合工作中的实际经验来谈谈怎样摆脱配置管理的尴尬局面。
匹配项目计划的配置计划
在这个标题中很强调两个字“匹配”，原因是我们的很多配置管理计划是为了计划而计划，是脱离项目总体而杜撰出来的计划，例如配置项识别不是依赖任务来识别的，配置项验收准则和任务完成标准不匹配等等。
对此，我的建议是：第一，配置计划作为项目计划的从属计划，必须依赖在项目计划中有所反映；第二需要明确的是配置计划是项目经理，非配置管理员；第三，配置任务的相关任务以及属性需要和项目任务的属性进行匹配；第四，匹配管理任务的责任人应该是非配置管理员，而是相应任务的责任人，配置管理是任务的“验证人”和“审核人”。只有这样配置计划和项目计划同呼吸，配置活动才能活起来。
生命周期映射配置基线
基线的逻辑是来自项目中采用的生命周期以及子生命周期，有些项目经理和配置管理员对基线产生逻辑不清晰，往往把项目的里程碑作为基线的识别标准，对于一个很瀑布模型的项目来说可能这样的方式是可以的，但是如果遇到多个生命周期叠加使用，这种基线识别方式可能会造成基线缺失，从而配置管理也就变得无意义，所以我的建议是：
1、配置管理员自身学会看懂和熟悉项目生命周期，从生命周期看项目版本发布策略；
2、项目组要有正式基线发布活动，活动责任人应该是项目经理；
3、基线后谨慎看待变更，基线化后的配置项需要执行变更过程，但是不要让变更成为基线的瓶颈，抓住变更的关键点，简化变更过程对现有项目工作的影响和冲击。
变通的变更控制
变更无处不在，现在很多项目中变更过程非常复杂，造成这种情况的一个重要原因就是很多人包括配置管理员对变更过程比了解。对此，我建议：第一，成立虚拟的CCB组织，CCB建议一定要把项目经理/OA需求人员以及项目中部分资深人员纳入到组织中，并定义好活动的方式;第二,根据变更引发的原因和涉及的范围,分级变更过程;第三,注重变更过程的实质,而简化变更形式.第四,变更记录建议注重信息本身而非信息载体,例如变更的原因分析,变更的影响记录以及修改的主要内容需要细致化,而对需要什么类型的文档来记录就不要太多的关心.
全新的配置审计
很多公司常常把配置管理划分到质量管理范畴,其一重要原因是配置审计存在,一个充分有效的配置审计可以折射出很多质量管理上的问题,所以可以说配置审计是质量管理非常主要的手段.对于如何做好配置审计可以参考如下建议:
1、加强配置项纳入基线库时的配置审计，重点在于配置项是否符合验收标准，相关的活动是否到位，信息是否完整；
2、对变更过程的审计，一方面审核全过程的记录，另一方面审核变更评审的有效性上；
3、功能审计，学会把配置想和需求结合起来，通过需求来审核需求和配置项的一致性；
以上概述了如何摆脱尴尬局面的一些建议，另外针对配置管理员还要是建议加强基本理论和概念的自我学习，下面介绍一下配置管理中几个关键概念与大家共勉：
基线
关于基线的概念，IEEE的标准定义是“已经正式通过复审核批准的某规约或产品，它因此可以做为进一步开发的基础，并且只能通过正式的变化控制过程改变”，在实际的项目中如何去理解基线？
配置纳入基线必须通过正式的审核动作，这种审核可以是正式的评审活动，例如需求规格书纳入基线必须通过评审，且评审问题关闭；也可以是正式的邮件批覆，例如某些项目组工作的约定；对于代码类的配置纳入基线可能就需要通过测试才可以了，所以如何审核需要根据情况而定，至于如何约定通常是在项目计划时完成这些约定工作；
那些配置项需要进入基线，首先说对于代码类的配置项，例如源代码、执行代码以及数据库脚本之类的肯定是需要纳入基线的，对于文档类配置项，我认为需要从以下几个角度考虑：
1、配置项是不是某些活动的输入或是输出，如果是可以考虑纳入基线；
2、配置项是否是第三方的输入或是输出，如果是可以考虑纳入；
3、配置项在项目生命周期过程中是否会发生变更，而且发生变更后对其他关联配置项产生影响，如果是可以考虑纳入基线；
如果纳入基线的配置项发生了变更怎么办，照基线的定义来看是需要通过正式评审，但是实际操作也并非全部如此，关键是定义好变更过程的触变条件。
从项目管理上考虑，基线是类似里程碑的概念，不同的是里程碑只是时间轴，基线不仅仅涵盖时间更包含了配置项集合；理解的基线的定义那么到底如何确定基线？从时间轴来看，基线时间点的衍化路线是这样的：项目SOW→项目里程碑→项目生命周期
→基线时间点；从配置角度来看，基线的配置项要看项目的版本发布策略即项目的生命周期的模型选择。
变更控制
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多， 因此变更控制显得格外重要。变更的标准过程无外乎包括以下四个环节： ①变更申请；②变更评估；③变更实施；④变更验证。但是如何使这个简单过程成为有效，可能需要考虑以下几个方面：
1、变更的原因，变更可以分成两类：第一类来自客户的变更引起的变更，例如客户需求发生变化等，第二类是在项目内部的变更，例如评审或者测试发现的缺陷导致的变更。针对第一次变更，最要防止客户直接向开发人员提出变更，所以在项目之初必须明确客户如何提需求，具体负责人是谁，提出的流程是什么的，具体要求是什么，对于项目组同样要设定专门的负责人，统一接受需求；对于第二种变更也制定内部提出和解决的责任人，接口越少出现问题的机会就越小。
2、变更流程的策划，虽然变更过程只有简单的四个环节，但是如何把四个环节串起来，不同的项目是不同的，即便在同一个项目中，不同的变更类型可能触发的流程应该不是一样的，例如需求变更，如果这个需求超出合同约定，那么需求就可能向总监甚至商务人员介入，如果这个需求只涉及到一些参数的修改，可能执行变更过程也不需要那么复杂吧。建议是我们的项目组在项目计划之时规划好不同类型的变更走那个类型的变更。
3、岗位与职责，执行这个流程需要设置那些岗位，赋予这个岗位什么样的职责。
4、变更控制的核心要素，很多软件企业的项目组一味照搬配置管理理论，没有真正理解变更过程，我认为变更控制关键要素是控制其中的几个关键要素就可以：变更过程有记录；变更的配置项和相关联配置项要周知相关小组或者个人;对影响和承诺进行要进行评估;确保基线库中的配置项版本和开发人员使用的版本一致.
只有配置管理员自身活动起来，配置管理自身过程形成体系,项目组的配置管理意识才能有所增强,配置管理过程才能被项目组接受,希望通过这篇文章能给与处于困境中的配置管理员以启示.
——摘自《程序员》2007年10月
转载请注明源自www.SCMLife.com,请保留版权. 本贴地址：http://bbs.scmlife.com/viewthread.php?tid=9496