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，由項目經理評估後确定。

本文整理自：

1、CSDN《項目變更控制委員會(CCB)》作者：hqml

2、博客園《需求變更管理》作者：PetterLiu

3、百度文庫《需求變更管理(模闆)》

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!