查看完整版本: 如何摆脱配置管理的尴尬局面

如何摆脱配置管理的尴尬局面

这篇是在平常搜索的时候发现的,觉得写的很不错!!特地转过来了!

     在质量体系的诸多支持活动中，配置管理处在支持活动的中心位置，它有机地把其它支持活动结合起来，形成一个整体，相互促进，相互影响，有力地保证了质量体系的实施，配置管理是质量管理和项目管理的基础，是联系项目活动的纽带，然而现实的配置管理一直在项目中处于尴尬地位：

   n         很少项目组有专职配置管理员；

   n         配置管理常常作为“配角”存在项目组，如果出现进度或者工作量出现偏差时常常损失配置管理活动；

   n         项目中的配置管理注重代码的版本控制，忽视整个配置管理体系；

   n         项目组认为有了配置管理工具就等于搞好了配置管理；

   n         配置管理活动没有和项目组形成互动，感觉是在自弹自唱，没有项目组附和；

     那么如何使得配置管理在项目管理和质量管理中成为“主角”？很多理论上或者文章上并没有针对性的解决方案，而通过个人的经验，我认为配置管理只有深入到项目中，参与到项目管理以及质量管理活动中，这样才能是我们的配置管理活动做有声有色：

   n         匹配项目计划的配置计划

    在这个标题中很强调两个字“匹配”，原因是我们很多的配置管理计划是为了计划而计划，是脱离项目总体计划而杜撰出来的计划，例如配置项识别不是依赖任务来识别，配置项验收准则和任务完成标准不匹配等等。我的建议：

   1.       配置计划作为项目计划的从属计划，必须依赖在项目计划中有所反映；

   2.       需要明确的是配置计划是项目经理，非配置管理员（很多项目组一说到配置计划就说是配置管理员的事情，而配置管理员往  往又不与项目经理交互信息）；

   3.       配置计划的相关任务以及属性需要和项目任务的属性进行匹配；

   4.       配置管理任务的责任人应该是非配置管理员，而是相应任务的责任人，配置管理员是任务的“验证人”和“审核人”。

        只有这样配置计划和项目计划同呼吸，配置活动才能活起来。

   n         生命周期映射配置基线

     基线的逻辑是来自项目中采用的生命周期以及子生命周期，有些项目经理和配置管理员对基线产生逻辑不清晰，往往把项目的里程碑点作为基线的识别标准，对于一个很单一的瀑布模型的项目来说可能这样方式是可以的，但是如果遇到多个生命周期模型叠加使用，这种识别基线的方式可能就会造成基线缺失，从而配置管理也就变得无意义，我的建议：

   1.       配置管理员自身学会看懂和熟悉项目的生命周期，从生命周期看项目版本发布策略；

   2.       项目组要有正式基线发布活动，活动责任人应该是项目经理，现在很多项目基线发布总感觉无声无息，没有人知道，基线化前后对项目组的工作没有影响；

   3.       基线后慎重看待变更，基线化后的配置项需要执行变更过程，但是不要让变更成为基线的瓶颈，抓住变更的关键点，简化变更过程对现有项目工作的影响和冲击；

   n         变通的变更控制

    变更无处不在，现在很多项目中变更过程非常复杂，一个变更要填写很多的表格，好像不填写文档就是完整的变更，认为变更就是写文档，造成这种情况的一个重要原因就是很多人包括配置管理员对变更过程不了解，我的建议：

   1.         成立虚拟的CCB组织，CCB建议一定要把项目经理/QA需求人员以及项目中部分资深人员纳入到组织中，并定义好活动的 方式；

  2.         根据变更引发的原因和涉及范围，分级制定变更过程；

  3.         注重变更过程的实质，而简化变更形式，变更的实在动作包括：变更评审；变更记录；变更信息周知项目组；使用版本一致；

4.         变更记录建议注重信息本身而非信息的载体，例如变更的原因分析，变更的影响记录以及修改的主要内容需要细致化，而对使用什么类型的文档来记录就不要太多关心。

n         全新的配置审计

很多公司常常把配置管理划分到质量管理范畴，其一重要原因是配置审计存在，一个充分和有效的配置审计可以折射出很多的质量管理上的问题，所以可以说配置审计是质量管理是非常重要的手段，对于如何做好配置审计，我的建议：

1.         加强配置项纳入基线库时的配置审计，重点在于配置项是否符合验收标准，相关的活动是否到位，信息是否完完整；

2.         对变更过程的审计，一方面审核全过程的记录，另一方面审核变更评审的有效性上；

3.         功能审计，学会把配置项和需求结合起来，通过需求来审核需求和配置项的一致性；

n         透过配置看项目管理

在项目管理理论中配置计划属于项目计划的从属计划，也就是说配置计划的受到项目计划的约束，同时也说明配置活动能力也折射出项目管理能力，通过对配置计划的跟踪参与到项目管理活动，协助项目识别偏差，我的建议：

1.         通过配置项纳入基线库的延迟情况，可以直接反映项目任务的完成情况；

2.         通过基线创建的延迟情况，可以直接反映项目生命周期偏差情况；

3.         识别配置项的数量，可以直接反映的是项目的任务分解的颗粒度；

[[i] 本帖最后由 果蛋子 于 2007-8-2 17:27 编辑 [/i]]

收益匪浅::em60::

写的不错，学习！

确实能反映现在配置管理过程中很多存在的问题，也希望在以后的工作中能逐渐改正这些问题。

::em42:: 看后非常有收获

能写出这么多的收获，你们的配置管理工作一定会有希望！