变更管理 变更控制委员会 (CCB)

laofo · 2009年05月27日 · 11 次阅读

  CCB 是变更控制委员会(Change Control Board)的简称。项目范围变更很可能需要额外的项目资金、额外的资源与时间,因此,应建立包括来自不同领域的项目利益相关者在内的变更控制委员会,以评估范围变更对项目或组织带来的影响。这个委员会应当由具有代表性的人员组成,而且有能力在管理上作出承诺。

CCB 需要界定以下几个问题: 范围变更发生时要确定项目经理能做些什么以及不能做些什么; 规定一个大家都同意的办法,以便提出变更并评估其对项目基准的影响; 说明批准或者不批准变更所需的时间、工作量、经费。

许多变化控制系统都包括一个变化控制委员会(英文简称 CCB),负责批准或抵制变化要求。控制委员会的权力和责任应该仔细地界定,并且要取得主要参与者的同意。在一些大的复杂的项目中,可能会有很多控制委员会,他们负有不同的职责。

laofo 于 2009-5-27 10:11 发表
  CCB 是变更控制委员会(Change Control Board)的简称。项目范围变更很可能需要额外的项目资金、额外的资源与时间,因此,应建立包括来自不同领域的项目利益相关者在内的变更控制委员会,以评估范围变更对项目或组织带来的 ... [/quote]

配置管理员在 CCB 中是个什么角色呢?具体都做些什么?

记下将要对什么做变更? 会对哪里进行修改? 可能涉及到的 Source Control 系统权限分配?

对这一块一直很模糊,不知道哪位有什么经验来分享一下。

关于变更管理我简单的画了一个变更管理的流程图,不知道理解的是否正确

这里涉及到一个主管这些 Bug 或者 CR 的经理,他肯定是 CCB 的成员,而且是很重要的一个人员,他来协调,驱动这个过程的进行。虽然没有在上图明确标示出来,但是这是一个不可忽略的角色。

那么配置管理员呢?哪位来分享一下啊?

这个图例可以看成是一个打补丁的流程, 但是变更并不是只有 bug 的修复. 我之前的帖子里面有提到过, 变更大致可以分为, 需求变更, 设计变更, bug 修复等等.

举一个很简单点的例子, bug 修复. 如果之前的配置管理做的非常的到位, 在为某个客户修复 bug 的时候, 这时肯定是基于某个版本 (或者之前的某些 patch). 那这个时候就需要配置管理员创建一个分支出来,用来 for developers fix bugs. 在 bug 修复完成后, 分支是要消亡或是继续保留? 这些都要通知配置管理人员, 以便对配置库进行操作.

这几天大病, 快死人了, 先说这些.

你哪个帖子?给个链接,我去学习学习。

patpat,小朋友,注意身体啊。。。。 by the way,难道是传说中的 H1N1??

我得找找是哪个....找到了发链接在这里.

你还别说, 我一开始还真以为是 H1N1 呢. 但是上天不眷顾我啊,不让我得那个病:(

你要是得了 H1N1,上级就该派人专门保护你了。呵呵

scmroad 于 2009-9-17 15:08 发表
你哪个帖子?给个链接,我去学习学习。 [/quote]

找不着啦, 只是提过那么几句,不怎么详细.要不哪天我再整个详细点的来耍耍?

嗯, H1N1 了可以住郊区医辽院, 还有工资拿. 我也想啊.

xiaoxiang7788 于 2009-9-17 14:04 发表
这个图例可以看成是一个打补丁的流程, 但是变更并不是只有 bug 的修复. 我之前的帖子里面有提到过, 变更大致可以分为, 需求变更, 设计变更, bug 修复等等. 举一个很简单点的例子, bug 修复. 如果之前的配置管理做的非常 ... [/quote]

配置管理员在 CCB 中是个什么角色呢?具体都做些什么?

CM 在 CCB 会议上就是

听听会议决定, 有可能涉及到的权限分配 可能需要做构建 (build) 的情况 什么时候会出 build 最终的 build 发布日期

还有其它的么?

CM 应该不需要出现在 CCB 会议上,我的感觉……

你说的那些 “听听会议决定, 有可能涉及到的权限分配 可能需要做构建 (build) 的情况 什么时候会出 build 最终的 build 发布日期”
项目经理完全可以在接到项目任务后,通知 CM 要做什么。

需要 登录 后方可回复。