ccb的全称是什么， 需求变更管理 定义、流程、模板

CCB的全称是Configuration Control Board，即配置控制委员会。

CCB是CMM(I)中提出的概念，某些组织中也许不叫这个名字而是叫决策委员会之类的。

网络上有一种说法认为CCB是变更控制委员会(Change Control Board)，这两者说法不同，但是概念和作用是一致的。CMMI-V1.2中对两者的描述原文如 下：“Configuration control boards are also known as change control boards ”。

【CCB的职责】

CCB的职责主要是 负责审批基准的建立和变更。

在CCB的职责方面，有 一些经常被误解的地方：

1. CCB只负责审批基准变更，不需要审批基准建立。抱有这种想法的朋友只从字面上理解而未深入思考，基准建立是从无到有的过程，难道不同样是一种变更吗？
2. CCB不仅仅负责基准建立和变更的审批，还会负责合同、资源、成本、技术等方面的审批。合同、资源、成本等都会反映在售前立项及项目计划、设计方案中，对项目计划等内容应该进行基准管理，对于已经实施基准管理的项目/组织，无论何种审批/决 策，最终都要走到基线建立和变更这一步骤。因此，对CCB职责的描述是高度概括的。
3. CCB的作用范围是配置管理。一些朋友看到CCB只在配置管理过程中被描述，所以认为 CCB的作用范围是配置管理，实际上CCB的作用范围是整个项目。那为什么CCB只出现在配置管理过程中呢？因为过程的设计和描述要遵从“高内聚、低耦 合”的原则，尽量的使一种职责不在多个过程中重复描述。

【CCB的组成】

CCB应由来自不同领域的项目利益相关者的代表组成，而且有能力在管理上作出承诺。

CCB一般由部门管理者、商务人员、项目双方项目经理、开发负责人、测试负责人、质量保 证工程师、配置管理工程师组成。对于不同类型不同层次的项目，CCB的成员不尽相同，如高技术型项目会包括技术负责人、系统集成类项目一般会包括系统工程 负责人、硬件产品类项目一般会包括硬件负责人、对于重要项目可能会包括项目双方的高层管理者。

有些朋友肯定会问，那么多人肯定都很忙，难道所有的基准建立/变更都要提交CCB审批 吗？如果是大的变更还有必要，如果很小的变更还要提交CCB，那不是效率很低吗？这也是很多组织中疑惑的地方，为了对这种情况，我们一般采用对CCB进 行划分层次的方式，使得不同层次的CCB成员关注不同的变更。

【CCB的层次】

CCB的层次一般都是有必要的(规模很小的项目一般不必要)，有些组织对于应该划分几个 层次的问题比较疑惑，CCB层次的多少不应该统一而是应该根据项目实际情况决定(作为组织标准规范，可以对CCB层次划分做出建议，但不应强制项目执 行)。一般情况下CCB的划分一般从以下步骤来考虑：

1. 项目涉众分析：先考虑此项目与哪些人有关系
2. 涉众影响分析：再分析与项目有关系的人中能影响项目各类决策的人，这些人即是CCB成员
3. 决策内容分析：对需要CCB进行决策的内容进行分析并分类
4. 决策匹配分析：将需要决策的内容与CCB成员进行匹配，得出大致层次
5. 层次匹配分析：上一步中得到的大致层次中会出现很多人员及决策内容的重叠，如项目进度计划的变更，影响较小的变更项目经理就可以决定，影响较大的变更需要部门管理者决定，影响更大的变更甚至需要项目双方高层管理者决定，因此需要对不同层次的决策内容进行分析。

有两种常用的CCB层次类型：

• 按照配置项类型，如需求相关的变更由1级CCB负责，设计相关的变更由2级CCB负责，代码相关的变更由3级CCB负责
• 按照变更影响，拿项目进度计划举例，工期变更超过50%由1级CCB负责，工期变更超过20%由2级CCB负责，工期变更不超过20%由3级CCB负责。

CCB的层次及分别负责的内容应在配置管理策划/计划期间完成，并需经过评审方可作为正式内容指导相关工作。

【CCB的决策】

建立了CCB之后，需要考虑的问题是如何决策，一般来讲，有以下三种方法可以考虑：

1、多数意见决策：通过投票的方式使所有的成员平等的参与决策过程。优点是充分调动了成员参加会议和提出建议的积极性，缺点是少数服从多数难以定义，2/3算多数？绝对多数相对多数？还有一个严重的问题是这种机制可能产生政治上的斗争(拉帮结派)，可能严重影响项目决策。

2、权利集中决策：将决策权交给一个人。优点是鼓励了决策中灵活考虑各种意见的优先级，如买方项目经理作为项目最终责任人进行决策；缺点是压抑了其他成员的积极性。

3、一致意见决策：寻求大多数参加会议的成员的非正式(非投票)的统一意见。优点是速度 快而且能让所有人的观点都得到表达和考虑；缺点是如果成员之间不能达成一致就无法做出决定。因此，应提供一种跳出机制，当无法在合理时间内达成一致，则由 买方项目经理决策(因为是买方投资)。

【CCB的领导者】

与CCB构成同样重要的是谁来担任CCB的领导者。CCB的领导者不是行政领导者而是职责领导者，只是进行主持会议，确保不偏离会议主题。

CCB的领导者可优先考虑下列人员：

• 买方项目经理：最终对产品的用户负责、对项目投资
• 卖方项目经理：负责技术上开发和维护
• 配置管理工程师：CM是他的主要职责，CCB是配置管理的焦点所在
• 质量保证工程师：作为协调者而非决策者，对任何决策的实施不负任何责任

【CCB会议】

CCB会议一般在需要对变更、发布等情况作出决策时召开。

对于CCB会议，需要进行会议记录以便为CCB的决策提供可视性。CCB的会议记录还通 过记录何时发生了什么事情提供对项目的可跟踪性，会议记录应是准确和具体的，不能存在让人误解的地方。无论采取任何行动，会议记录都应该记录谁是执行者以 及行动何时完成等信息，还需包括会议出席和未出席的人员。会议记录不仅要呈给出席会议的人员还要呈给买方和卖方的高层管理者，以便其对项目进行追踪。

CCB会议记录不是出于形式上的目的而是为了记录内容的清楚和完整。人们经常在结束会议时对会议结果进行推辞或者还对所同意的问题有不同的观点，这种混乱无序的结果是很危险的，会议记录避免了这种情况。

遵循如下原则：

(1)建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

(2)制定简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

(3)成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

(4)需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

(5)需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

需求变更管理 模板：

1. 本文档发布之后，要求对本文档内容进行增加、修改或删除等操作，须经需求变更控制。
2. 变更申请及审核使用以下表格：

1. 需求变更经“申请、评估、审批、执行、确认”等五个步骤。
2. 变更控制委员会（CCB）由项目相关方高层人员共同组成。对系统范围基线造成重大影响的变更，上报CCB审批。是否上报CCB，由项目经理评估后确定。