CMMI 配置管理（Configuration Management）系列（2）角色职责
配置管理第二炮角色职责，在说在配置管理中各个角色职责之前首先要跟大家解释几个概念。本文是我在执行配置管理的时候的一些总结。对于官方的资料多多少少会有点出入。但整个方向是正确的，无需担心会产生误导。
先说一下配置管理策略与基线。这两个概念或许有些抽象。我们开始吧。
配置管理策略
实用、有效配置管理的核心是基于业绩、约束确定配置管理的目标,需要基于组织、项目的具体特点选择策略和实践,并基于产品和过程度量来改进。
配置管理、版本管理和工作产品管理
基于配置项的重要性及发生变更的可能性制定适当力度的控制策略。配置管理指严格执行变更控制流程,适用于重要且相对稳定的配置项。版本管理则对变更的决策过程相对弱化,重点管理配置项的版本变更历程,适用于比较重要且变更较频繁的配置项。工作产品管理适用于那些不是由项目直接产生的且几乎不会发生变更的配置项。
CCB的组织及决策机制
基于产品、配置库的规模及团队合作经验等要素确定适当的变更决策方式。变更控制委员会(Chang Cont rolBureau ,简称CCB) 的基本组织方式包括统一或分散两种,前者由一个统一的CCB 来审批所有配置项的变更,后者为各类配置项分别建立CCB。CCB 的决策机制包括少数服从多数、一票否决、主席裁决等方式。
配置项的粒度划分
粒度是指配置项的规模。配置管理的粒度越细,看起来可视性越清晰,但配置项的数量会增大。粒度粗则大粒度的配置项可能因为多个局部变更而频繁整体变更,难以形成相对稳定的基线;相关涉众在变更分析时难免需要关注整个配置项,从而加大分析工作量。当有良好的配置管理工具支持和熟练的配置管理人员时,可以优先考虑细粒度管理;否则,可以考虑对可能较频繁变更的工作产品采用细粒度管理,相对稳定的工作产品采用粗粒度管理。
配置管理的力度投入
配置管理是一种管理活动,管理活动存在适度投入、过投入和欠投入等可能性。理想状态当然是适度投入,但具体怎样把握“度”需要实践和学习,往往不容易确定。投入要重视实效,抓住关键目标。如果在过投入和欠投入之间难以决策,则可以优先选择欠投入策略。欠投入可能使工作做得不到位,但毕竟没有投入,经过实践、度量、分析后再改进、再增加投入,在心理上相对容易接受,容易达成共识
基线
在下篇文章里会详细提到关于基线
项目管理（Project Manager，PM）：
项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。其具体职责为以下几项：
- 制定和修改项目的组织结构和配置管理策略；
- 批准、发布[配置管理计划]；
- 决定项目起始基线和开发里程碑；
- 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项： 定制开发子系统；
- 定制访问控制；
- 制定常用策略；
- 建立、更改基线的设置，审核变更申请；
- 根据配置管理员的报告决定相应的对策。
配置管理员（Configuration Manager，CM）
配置管理员根据配置管理计划执行各项管理任务，定期向CCB提交报告，并列席CCB的例会。其具体职责为以下几项：
- 软件配置管理工具的日常管理与维护；
- 提交配置管理计划
- 各配置项的管理与维护
- 执行版本控制和变更控制方案
- 完成配置审计并提交报告
- 对开发人员进行相关的培训
识别软件开发过程中存在的问题并拟就解决方案
系统集成员（System Integration Officer, SIO）
系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：
- 构建版本；
- 完成对版本的日常维护；
- 建立外部发布版本。
在我接触的配置管理中，一般会把配置管理员与系统集成员的工作都交给配置管理员。下文看到关于系统集成员的时候你会觉得系统集成员的工作太简单也就是因为简单有的公司或许把他的工作划分给配置管理员，或者测试员。这份工作是比较频繁的有时候因测试需要一天会发布多次，甚至每小时都会操作几次。不过依系统集成员与配置管理员的工作来看，他们是有交集的。所以这里我还是会提倡把他的工作交给配置管理员。
开发人员（Developer，DEV）
开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型（版本管制清单.doc）来完成开发任务。
下图是对所有角色的一个总结，希望能帮助我们对整体的一个流程有个深刻的了解。
看完本文不至于会让你对精通配置管理。当你实际操作的时候你会发现束手无措。关注下文吧。
