轉載自:http://blog.csai.cn/user2/50889/archives/2010/43047.html

在筆者之前的《配置管理漫漫談》系列文章中多次提到了CCB，那么CCB究竟是什么？CCB的職責和權力分別是什么？CCB有哪些人組成？CCB如何影響項目？許多朋友對此的理解并不很清晰。 【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的職責方面，有 一些經常被誤解的地方：

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會議記錄不是出于形式上的目的而是為了記錄內容的清楚和完整。人們經常在結束會議時對會議結果進行推辭或者還對所同意的問題有不同的觀點，這種混亂無序的結果是很危險的，會議記錄避免了這種情況。

?

轉載于:https://blog.51cto.com/tonyty163/516021

總結

以上是生活随笔為你收集整理的配置管理漫漫谈之CCB的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。