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的職責方面，有 一些經常被誤解的地方：
- CCB只負責審批基準變更，不需要審批基準建立。抱有這種想法的朋友只從字面上理解而未深入思考，基準建立是從無到有的過程，難道不同樣是一種變更嗎？
- CCB不僅僅負責基準建立和變更的審批，還會負責合約、資源、成本、技術等方面的審批。
合約、資源、成本等都會反映在售前立項及專案計劃、設計方案中，對專案計劃等內容應該進行基準管理，對於已經實施基準管理的項目/組織，無論何種審批/決
策，最終都要走到基準建立和變更這一步驟。因此，對CCB職責的描述是高度概括的。
- CCB的作用範圍是組態管理。一些朋友看到CCB只在組態管理過程中被描述，所以認為
CCB的作用範圍是組態管理，實際上CCB的作用範圍是整個項目。那為什麼CCB只出現在組態管理過程中呢？因為過程的設計和描述要遵從“高內聚、低耦
合”的原則，盡量的使一種職責不在多個過程中重複描述。
【CCB的組成】CCB應由來自不同領域的項目利益相關者的代表組成，而且有能力在管理上作出承諾。 CCB一般由部門管理者、商務人員、項目雙方專案經理、開發負責人、測試負責人、品質保
證工程師、組態管理工程師組成。對於不同類型不同層次的項目，CCB的成員不盡相同，如高技術型項目會包括技術負責人、系統整合類項目一般會包括系統工程
負責人、硬體產品類項目一般會包括硬體負責人、對於重要項目可能會包括項目雙方的高層管理者。有些朋友肯定會問，那麼多人肯定都很忙，難道所有的基準建立/變更都要提交CCB審批
嗎？如果是大的變更還有必要，如果很小的變更還要提交CCB，那不是效率很低嗎？這也是很多組織中疑惑的地方，為了定對這種情況，我們一般採用對CCB進
行劃分層次的方式，使得不同層次的CCB成員關注不同的變更。 【CCB的層次】CCB的層次一般都是有必要的(規模很小的項目一般不必要)，有些組織對於應該劃分幾個
層次的問題比較疑惑，CCB層次的多少不應該統一而是應該根據項目實際情況決定(作為組織標準規範，可以對CCB層次劃分做出建議，但不應強制項目執
行)。一般情況下CCB的劃分一般從以下步驟來考慮：
- 項目涉眾分析：先考慮此項目與哪些人有關係
- 涉眾影響分析：再分析與項目有關係的人中能影響項目各類決策的人，這些人即是CCB成員
- 決策內容分析：對需要CCB進行決策的內容進行分析並分類
- 決策匹配分析：將需要決策的內容與CCB成員進行匹配，得出大致層次
- 層次匹配分析：上一步中得到的大致層次中會出現很多人員及決策內容的重疊，如項目進度計劃的變更，影響較小的變更專案經理就可以決定，影響較大的變更需要部門管理者決定，影響更大的變更甚至需要項目雙方高層管理者決定，因此需要對不同層次的決策內容進行分析。
有兩種常用的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會議記錄不是出於形式上的目的而是為了記錄內容的清楚和完整。人們經常在結束會議時對會議結果進行推辭或者還對所同意的問題有不同的觀點，這種混亂無序的結果是很危險的，會議記錄避免了這種情況。
