我前後在 6 家 IT 公司工作過, 這些公司有 2 家已取得 Level-3, 另有 2 家已取得 Level-2, 現在工作的公司是 Level-3.

CMMI 的 Configuration Management 有說明要執行 Configuration Control Board (CCB), 我們公司從未舉行, 但在輔導公司輔導下都能夠產生表單. 問過以前的同事, 也都是有表單, 但都不知道 CCB 的運作程序. 國內輔導公司的顧問也語焉不詳. 國外的 LA 也僅能照 CMMI 再說一次.

誰可以告訴我 Configuration Control Board 如何運作? 國外的 CMMI Level-3 公司也跟國內一般運作嗎? 有Level-3, 卻是軟體版本一團亂. 且公司並無 Configuration Management 專業人員. 一切只有 CVS 而已.

P.S. - 以下是我的二位同學的心聲:

(1) 同學 1 目前在 CMMI Level-3 公司. 他的總經理在品保部門成立佈達時召集所有品保部門主管與工程人員訓話時直接表明: " 我(總經理)做軟體 40 年, 沒有 QA 與 CM 一樣可以將軟體交給政府部門, 所以 QA 與 CM 是隨時可以裁撤的, ... ". 同時他參與的專案的專案經理對於專案品質也曾經表達"這個案子政府有營運時程壓力, 所以既使公司做的再怎麼爛, 政府非用不可...", 所以他們公司的 QA 與 CM 是做給 CMMI 評鑑員看的, 公司沒有人管 QA 與 CM 的.

(2)同學 2 目前在 CMMI Level-5 公司上班, 10 年前看好公司遠景時以 35.5 買入股票, 通過 Level-3 時股價 11.2, 今年通過 Level-5 時股價 6.5, 今天股價是 6.51, 還好 CMMI 只定到 Level-5, 如果擴張到 Level-10, 按照這個比例以 MA 來估算股價, 那真不敢想, 所以公司就算有人在管 CM 與 QA, 但對公司無任何效益. 公司在經驗分享中表述缺陷率大幅降低, 品質大幅提升, 軟體版本管控效益卓著, 為何對利潤沒有任何提升. 好像我們的CMMI大有問題.

3Q, ORZ

有關於CCB的運作，容個人以後較不忙的時候再詳細說明。
但是您所提到的CMMI-ML5的公司，在民國91年執行國防OA案期間，在個人的要求及引導下，曾經執行過CCB，包括提出ECP，並召集由該公司、其下包商與我的團隊成員、使用者代表，共同召開的CCB。這是一個聯合審查會，目的在核准這個ECP，然後付諸執行。當時參與的成員，仍然有部分在該公司內任職。

至於股價下跌，似乎不太適合與所得到的CMMI的成熟度等級聯想，但是有件事卻是要注意到的：
在CMMI架構下，不能裁適的是PA的Goal，其他的都可以裁，因此，要做到既符合CMMI的要求，又能夠獲利賺錢，對的經驗非常重要，另外人才也很重要，公司的人員應該確實瞭解到品質管理制度的真義(這個意思不是讓公司要求每個人都能把CMMI這個框架背熟，而是了解這些process的意義，他們的異同。不清楚的話，可以研究一下CMMI文件後面所列的參考文獻，這裡頭列了不少ISO的標準、IEEE的標準及EIA的標準)；盲目地追求CMMI而不懂得如何在CMMI的框架下裁適出適合公司，適合專案的processes，只是會覺得專案更亂、事情更多、更難執行、人也更累而已。

----------------
引文:

為何通過 CMMI Level-5 股價卻只有 6.5 元 ? -- 問題是在市場，不是在 CMMI 啦 !

大家應該去拜讀 5/11 程家麒理事長的討論文章 : [ 台灣軟體業的出路 ] ，就會明白啦 !

或者，看看 6/21 [ CMMI Level 2/3 公司前進國際市場練兵時間到了] 的討論文章，應該也會有所醒悟吧 !

在CCB重要的工作就是對於變更的審議與決定(不說「核准」，因為結果可能是「駁回」)，其中一項重要的標的物就是工程變更建議書(Engineering Change Proposal)。

工程變更建議書(ECP)是一項管理工具，它是用來在獲取過程中，對CI、訂為基準的績效需求與構型文件提出構型變更建議。儘管內容項目似乎繁多，不同的標準有不同的內容要求，但基本上這個工程變更建議書就是一個構型項目的維護計畫(maintenance plan)，它會包括像變更的範圍、相關技術考慮、風險、對於原專案基準(品質、時程、成本等基準)的衝擊分析、所需的資源、工作時程分析，何時完成、何時交付。(可以遵循一些標準來提例如：MIL-STD-973、MIL-STD-2549、MIL-HDBK-61、EIA-836等等標準，當然甲乙雙方也可以自行定義，但千萬別太鬆散，否則可能會面臨考慮不夠周延的問題)。

工程建議書會由乙方根據變更要求(書)(change requests)提出，變更要求甲乙雙方均可提出，當然甲方提出有可能是系統相關的工作流程改變、規範版本更新等等，乙方則有可能因為技術風險或者成本因素，在經過價值工程(VE)分析後，提出對於原已經過核准並訂為基準的設計提出變更。

完成分析後，ECP併同被變更之構型項目的文件及參考資料，交由變更管制委員會(Change Control Board)或構型管制委員會(Configuration Control Board)(以上均簡稱為CCB)祕書(或者就是Configuration Manager)做初審(看看該完成的分析是否都已經完成)，然後依據變更的範圍選擇相關的stakeholders與會，準備相關資料及議程。會議準備事項：
1. 審查目標說明
2. 工程變更建議書
3. 變更範圍內的相關資料(含各種圖表)
4. 資源的狀態，包括財務(專案成本結構)等
5. 相關的審查報告(工程變更相關分析所舉行之walkthrough、Inspection及其他相關review的記錄與報告)
6. 據以評估的規定、標準、指導綱要、計畫書或程序
7. 審查程序文件

CCB秘書(或SCM)發布會議通知，並將前述資料(1-7項)送交與會人員。視需要舉行會前會，由乙方的ECP撰寫人員，對參加CCB會議的人員做概要說明，以便讓參與的人員對ECP所涉及問題有一定程度的理解。

會前會的會後，CCB與會人員實施ECP預審，同時對於內容提出意見或建議，或者需改進的缺點事項，然後回饋給CCB秘書，以免規劃會議時間分配。

開會當天，即就議程進行會議，此一會議由甲乙雙方的指定代表擔任共同主席。

會議期間，由乙方負責逐次提報ECP的內容，然後大家就相關議題提出討論此一會議會從專案時程、成本、產品面與技術面衝擊、風險影響評估等角度、以及變更後相關事項的調整(例如，教育訓練的作法、維護程序步驟、維護所需的服務水準變化等等)交換意見，以期獲得結論。這些結論會有下列幾種狀況：
1. 通過，由乙方按照專案變更流程完成變更項目。
2. 駁回。本項變更不實施，但必須說明駁回的理由，以免後續造成爭議。(也許有一天，甲方突然發現本來就應該改，於是回頭修理乙方，這時候紀錄就很重要了)
3. 有條件通過。只是一些枝微末節的細項(例如，不影響理解、工程或成本的錯漏字)，修正後通過，乙方按照專案的變更流程完成變更事項。
4. 修改後擇期再審。因該變更案具有可行性，但是仍需再做進一步分析。

會議中的重要討論經過及論點、最後的結果應做成記錄，並由雙方代表簽署。

以上是CCB會議召開相關事宜，敬請參閱。

以上這些描述，大家看了一定覺得很害怕，小專案或者人力有限的狀況下，不會很難做嗎？

其實在小型的專案裡，專案經理就可以擔負起CCB的職能。尤其是組織自己內部的產品開發專案，可以由專案經理一個人主導與做決定。但是如果是為客戶客製化的產品，那麼，在人少的狀況下，由專案經理擔任SCM經理，但還是要與客戶的代表一起開會決定工程變更事宜，不能獨斷獨行，否則衍生的時程、成本、產品品質的衝擊，其責任可能不是專案經理可以自己一肩扛下的。

----------------
引文: