之前寫(xie) 過幾篇吐槽CMMI高成熟度在軟件環境下的硬傷(shang) 的文章。將製造業(ye) SPC(統計過程控製)的應用照搬在軟件工程中屬實驢唇不對馬嘴，1萬(wan) 個(ge) 水杯的製造過程都是完全一致的，但沒有兩(liang) 個(ge) 軟件係統的開發的過程是完全一致的。在軟件環境中導致變異的特殊原因實在太多，強製將不同團隊開發的不同係統的數據放在一起做控製圖，用SPC（統計過程控製）方法識別所謂“異常點”，做有遠見的分析改進，將隱患防患於(yu) 未然，不僅(jin) 強人所難，也不符合使用SPC的前提。另一個(ge) 是模型硬性要求使用具備統計意義(yi) 的過程性能模型，管控變異，做“what-if”的分析以實現開發目標，更是將複雜軟件開發想簡單了。

這些製造業(ye) 中流水線模式的思維明顯不適用於(yu) 充滿不確定性，業(ye) 務和技術創新是常態的軟件世界。十幾年來，在許多場合我表達了我的觀點，然而回應不多，我自己也有乏力感。最近，兩(liang) 個(ge) 重量級人物的聲音讓我有了認同感，也許是重塑CMMI高成熟度的時候了。

當被問到如何評價(jia) SPC應用到軟件開發時，Donald Wheeler（當今SPC應用第一人）的回答直截了當，“軟件開發用SPC純屬扯淡！” 他認為(wei) 軟件開發中的特殊原因實在太多，SPC無的放矢。

這個(ge) 月標誌著CMMI正式問世30年（1991年8月，CMM1.0正式發布），我特別想知道，如今，30年前群星璀璨的CMM製造團隊是怎麽(me) 看待CMMI高成熟度的，很可惜，我們(men) 已經無法聽到Humphrey的聲音了，但他的接班人Bill Curtis在這個(ge) 月初做的一個(ge) CMMI高成熟度演講中，明確給出了自己的結論：

“I am part of the group that got it wrong.” 

“我是把這件事搞砸了的團隊一員。”

這讓我想起一句話——智者看到證明自己信念是錯的證據時，都有能力改變自己的觀點。Curtis就是這樣一位智者， 也讓我對他多了一份敬意。

CMMI改變了軟件世界，成為(wei) 了軟件工程中的智慧和經驗的載體(ti) ，高成熟中的不足不影響它在軟件發展曆史中的地位，我們(men) 應該把這些不足當做後人改進完善的機會(hui) 。在這方麵，Bill Curtis給我們(men) 做出了榜樣，在指出CMMI高成熟度不足後，他也給出了今天他眼中的高成熟度的模樣（見下圖）。

他認為(wei) 四級應該是優(you) 化級，他所說的優(you) 化是讓組織內(nei) 部的重要過程做到極致，變得穩定，可預測。而五級則應該是創新級，如果當前做法已無法滿足公司發展要求時，不破不立，通過革命性創新，改變組織的業(ye) 務、研發、管理模式，讓自己立於(yu) 不敗之地。他對2級和3級組織特征的描述和之前沒有大的變化，隻是換了個(ge) 新詞描述三級組織的能力：可信賴。

我20年的評估、谘詢經驗發現，成功的CMMI組織有一個(ge) 共同特點，他們(men) 對自己遵循過程開發出來的東(dong) 西會(hui) 越來越有自信，敢於(yu) 應用於(yu) 後麵的產(chan) 品和項目中，複用率會(hui) 越來越高。過程混亂(luan) 、處處走捷徑的團隊開發出來的東(dong) 西，恐怕連自己都沒信心。所以Curtis給出的三級組織特征是可信賴，也就是對自己對通過過程自律開發出來的東(dong) 西有信心。

參考Bill Curtis的思路，我認為(wei) 軟件高成熟度的度量分析從(cong) 過程角度應該關(guan) 注端到端的價(jia) 值鏈的分析和中間過程的關(guan) 聯關(guan) 係，同時也應做好產(chan) 品分析，如複用度，可信度，質量債(zhai) 務等。分析方式可以包含各類統計或其他量化分析技術，關(guan) 鍵是能引導我們(men) 找到改進的關(guan) 鍵點。所以模型關(guan) 注的不應是具體(ti) 用什麽(me) 樣的分析方法，而是如何讓這些量化分析能夠真正發揮作用。這樣一來，過程性能模型也隻是一個(ge) 可選項：一個(ge) 實施的選擇，而非模型的硬性要求。

其實美國一些被作為(wei) 標杆的高成熟度組織用的SPC分析，也不是100%遵循純粹的控製圖的分析規則，而是根據性價(jia) 比（易用、低培訓成本、有價(jia) 值）做了重大調整。

高成熟度的組織應該具備高成熟度的自動化程度，如果可自動化的過程還在手工折騰，不同平台之間沒有打通，那麽(me) 不能說你的過程已經做到優(you) 秀。其實Humphrey在30多年前已經告訴我們(men) 軟件過程自動化的重要性，把它作為(wei) 高成熟度組織的一個(ge) 特征。有興(xing) 趣的朋友可以再讀一遍《管理軟件過程》一書(shu) 中的第十八章。

在軟件世界裏，不需要做任何數據分析，我們(men) 都知道人是造成過程能力差異的最大原因。所以如果沒有成熟的軟件團隊，不可能有高成熟度的組織。在強調推動自我管理團隊的同時，也不能忽略如何讓管理層對團隊有信任和信心。我很認可Bill Curtis的理念：讓領導放心的團隊必須是一個(ge) 有能力打硬仗的隊伍，同時又是一個(ge) 過程自律的群體(ti) 。軟件高成熟度在這方麵也應該有相關(guan) 的要求。

上麵這些想法雖然不夠成熟、全麵，但是如果不跳出舊思維，很難解決(jue) 這個(ge) 至今存在的舊問題。換個(ge) 思路，也許我們(men) 可以找到更加適合軟件、在頂級中外IT企業(ye) 經過驗證的高成熟度實踐。

意識到高成熟度的不足對企業(ye) 導入CMMI4級和5級實踐也至關(guan) 重要，以模型意圖和價(jia) 值為(wei) 抓手，我們(men) 完全可以有創意的建立一套簡單、輕量、有價(jia) 值的高成熟度體(ti) 係，也可以通過替代實踐讓高成熟實踐在組織活動中常態化，而不是隻為(wei) 評估做些數字遊戲。

客觀說來，CMMI 2.0還是多少忽略了高成熟度的改進，失去了一次突圍機會(hui) 。希望5000和CSMM的團隊和實踐者，在建立、完善自己的模型過程中，可以走出困局，重塑軟件高成熟度。也歡迎朋友們(men) 積極轉發，大家一起討論如何讓高成熟度實踐變得不再高不可攀，而是能帶來實實在在好處。

本文轉載自老叢(cong) 講桌。