前不久我跟一個軟件公司的副總聊天。他說他們公司發明了一種新的概念和方法，工作得很好，叫缺陷委員會（bug council）。這是一個變更請求和bug評審的例會，會議討論并決定增加、修改、放棄哪些功能特性。
我笑著問他：“如果我告訴你，我們已經在用相同的方法工作了15年，只不過我們叫配置控制委員會（configuration control board），你會有什么反應？”
“哦”他說，“那我可能會不理你！”
我繼續問他，希望能給他一些幫助，“我有15年的經驗可以跟你分享，這樣你的公司就不需要自己創造發明什么自己的方法，而是快速地借鑒其他公司的做法”
回答是：“我都不清楚�！�
最后我問：“你知不知道CMM或者其他軟件開發指南能提供很多好的做法？”
“知道，”他說，“但是那些東西對于我們來說都不適用，我們公司是很不一樣的�！�
具體上下文中的CMM
我是CMM的主要編寫人之一，參與了1.0版本的CMM的全部評審。自從CMM1.0在1991年8月發布后，我就必須要處理很多關于CMM的誤解。我發現CMM是在技術文獻中最容易讓人誤解的其中一個。
CMM還有很多IEEE標準和指南都嘗試從軟件開發產業中的有限部分收集各種最好的智慧。但是由于它的規模和密度，我發現人們很難掌握CMM。
CMM反映的是大公司的軟件開發環境、CMM只是涉及到軟件開發的一小部分好的做法、CMM的語言很難懂，這些我都同意。
在我幫助一些選擇CMM作為改進開發過程的工具的組織時我會面對很多挑戰。
如果CMM真的是為大公司而寫的，那么我作為作者之一有責任讓其他人也理解。
我在咨詢和教授CMM的時候，總是想辦法弄清楚我的聽眾都是從什么樣的公司來的，我嘗試使CMM通俗易懂，使用他們自己的語言。
當我與他們一起的時候，我們會去找尋CMM的本質，CMM帶給他們的好處。
可重復級：穩定項目
我聽到很多人說他們的項目的軟件開發是“失控”的。例如：
1、 不知道哪個版本的文件是“正式的”
2、 一個人修改了問題，卻引發了另外一個人的問題
3、 在某個版本的特性沒有很好地保留到后面的版本
4、 用戶與開發人員對功能特性的理解不一致（通常是沒有很好地理解最終用戶的需求）
5、 功能特性在最后一刻還在改變，并且變更請求是以即興的方式進行
6、 當開發人員認為不能滿足開發任務的要求時不能“回退”
7、 不清楚離完成開發任務還有多少工作要做
8、 不同開發人員開發出的模塊或產品顯著不同，導致在集成或重寫時的混亂
9、 重寫或修改比重新開發還要多的時間
導致其他的情緒問題：士氣低下、缺乏激情、害怕等等。
這就是CMM在可重復級要處理的問題：把一些基本的東西控制起來，這樣開發人員可以專心地開發軟件。這就是CMM在可重復級的本質：
1、 控制產品的發布、控制處于開發階段的產品組成部分（CMM的軟件配置管理關鍵過程域）
2、 定義特性集合，保證用戶的需求被開發理解，控制特性集合以便變更影響被充分理解（需求管理關鍵過程域）
3、 使用特性集合來評估工作（確保所有承諾的功能特性都得到提供），使用評估來創建進度表和其他計劃（軟件項目計劃關鍵過程域）
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
