在CMMI主任評估師圈子裏有個(ge) 讓大家一直頭疼的問題：如果一個(ge) 組織既要CMMI的級別但又不願意做一些模型中對自己無價(jia) 值的實踐時，該怎麽(me) 辦？幾乎所有評估師的傾(qing) 向是：如果你要級別證書(shu) ，不得不做一些對組織無價(jia) 值的事情是必須跳進去的評估陷阱。 沒有所謂的CMMI陷阱！借2.0的東(dong) 風，讓CMMI真正變成價(jia) 值驅動器，讓CMMI落地有聲！

一位我認識多年資曆頗深的CMMI評估師是這樣說的，“當你決(jue) 定要追逐成熟度級別時，你已經沒有選擇了，會(hui) 導入並實施一些對組織無價(jia) 值的實踐。在這種情況下，你會(hui) 定義(yi) 一些不會(hui) 帶來業(ye) 務價(jia) 值的過程，它們(men) 唯一目的就是為(wei) 評估提供一些文檔證據。”

我一直不太能接受這個(ge) 論調，總感覺它有點在鼓勵評估變成遊戲，也很難想象這些過程在沒有參加評估的項目裏會(hui) 被使用。逼著一群高智商的人做無價(jia) 值的事情，不應該是Humphrey的初衷。 如何正確打開CMMI開發模型？它給出的是產(chan) 品開發全過程的重要考慮點以及提升過程能力的通道，模型中的每一條實踐都有其目的：或者要規避一些潛在問題，或者要強化一些對實現高效、高質量開發有意義(yi) 的活動。由於(yu) 各個(ge) 組織有不同的場景，在建立實現這些目的的過程時，一定會(hui) 有性價(jia) 比的考慮，很有可能有些要規避的問題在某個(ge) 組織內(nei) 不是大問題，而有些強化活動同樣意義(yi) 也不是很大，如果評估組不能很好的區分模型要求（意圖和價(jia) 值）和實施選擇，帶著一套預期的“實踐做法”參加評估，就會(hui) 掉入了CMMI的評估陷阱，逼著企業(ye) 披上兩(liang) 張皮。

這真的是個(ge) 跳不出來的CMMI評估陷阱嗎？我不這麽(me) 認為(wei) 。當年Humphrey規定的，今天我們(men) 還在遵循的一條評估準則是：評估準備階段評估組必須充分了解評估組織的context（場景），其目的就是要理解組織的特殊性，理解一些特殊做法的合理性，從(cong) 而完成一場有價(jia) 值的評估。這就是說，因為(wei) 場景不同，同樣一條實踐意圖的實現方式是可以多種多樣的。

從(cong) 我開始做CMM評估師開始，就一直努力摸索破解這個(ge) 評估陷阱之法。這確實不是一件容易的事，但20年的時間也積累了一些思路。

首先，真正理解模型中實踐的意圖價(jia) 值是基礎，確定這個(ge) 意圖價(jia) 值在具體(ti) 企業(ye) 中的體(ti) 現則需要站在他們(men) 角度看問題，隻有這樣才能對無明顯價(jia) 值實踐找出替代實踐。

比如說，一些CMMI五級的對日外包組織，他們(men) 的項目範圍僅(jin) 僅(jin) 是V模型的下半身，團隊隻和日方技術團隊溝通，工作範圍可能僅(jin) 覆蓋詳細設計到單體(ti) -部件測試，他們(men) 沒有機會(hui) 麵對真正用戶或客戶。那麽(me) 我們(men) 如何實施RDM中操作場景的要求呢（RDM3.2）？如何確認需求在目標環境下實現客戶要求呢（RDM3.7）？顯然用傳(chuan) 統僵化模式的話，我們(men) 隻能跳入CMMI評估陷阱了，做一些脫離場景的評估怪事了。但是如果我們(men) 真正理解3.2和3.7的意圖，真正理解外包場景，那麽(me) 找出價(jia) 值的替代做法也不是一件難事。比如可以通過Q&A確保團隊理解日方提出的輸入，同時讓日方明確確認我們(men) 的編程、測試思路。成熟的日本客戶往往也會(hui) 要求你這樣做，這些替代做法形成的過程既有價(jia) 值，也實現了RDM相關(guan) 實踐在外包場景的目的。

兩(liang) 年多前寫(xie) 了一篇文章，題目是“Formalizing Informality——非法的存在也可以合理合法！”我自認為(wei) 那是最重要的一篇CMMI的文章，卻沒有什麽(me) 反響。 而最近寫(xie) 的一篇風清揚的CMMI的文章，也想表達類似的意思，抄錄其中一段如下：

“以需求為(wei) 例，它是讓眾(zhong) 多軟件組織頭疼的問題，CMMI給出了14條實踐幫助大家破解需求難題。但是不同的項目有不同需求問題，隨便舉(ju) 幾個(ge) 場景：一些研發項目需求十分模糊，連客戶也說不出個(ge) 道道；有些升級項目需求則包含了客戶、開發一致認為(wei) 應該完善之處，所以十分明確；有些對日外包項目需求就是一些描述清晰的任務包；有些新技術、新領域（如環保）的項目客戶根本不熟悉，也不知道如何引入；有些財大氣粗、但不了解技術局限的客戶對需求會(hui) 獅子大開口；有些項目跨越多產(chan) 品，牽扯多接口，多團隊；有些項目僅(jin) 覆蓋單係統、單團隊。如果做個(ge) 問題接龍遊戲，相信我們(men) 可以玩幾個(ge) 小時。

那麽(me) 如何用CMMI給出的14條破解之術呢？顯然大而空的標準會(hui) 處處碰壁，最終一定是評估花瓶項目的點綴，不參加評估的項目會(hui) 各行其是。以風清揚之“道”模式打開：先了解14條實踐覆蓋的點；逐步悟出其中之意，經驗決(jue) 定悟性；根據具體(ti) 場景，不拘泥固有模式，當繁則繁，當簡則簡，當無則無，當變則變，無有固有，隨機應變，時刻抓住重點，見招拆招，在約束範圍內(nei) ，爭(zheng) 取最大價(jia) 值。

所以學習(xi) CMMI也應由繁入簡，最終隻存其意。當然做到這一點，需要不斷的實踐，需要謙遜的請教，需要發揮自己的悟性，需要一點創新的精神。每家IT組織都有自己的痛點，每個(ge) 項目都有不同的場景，每個(ge) 具體(ti) 成功的CMMI落地都有其獨特之處，CMMI應用之妙，必然是無招勝有招。麵對幾百條實踐，我們(men) 這些CMMI傳(chuan) 播者更應該從(cong) “器”悟“道”，方得精髓。”

我觀察到不少CMMI評估組沒有真正理解一些重要的評估規則，比如，五級評估不是所有項目都要做到五級；不是有一些弱項實踐要求就一定沒有實現，我們(men) 還要看在評估場景下，弱項帶來的危害是否比較大。這裏我也呼籲下CMMI研究院，更加明確模型覆蓋要求，鼓勵CMMI的用戶追逐價(jia) 值，do more with less, 遠離CMMI評估陷阱。

不論是當年的SEI還是今天的CMMI研究院，都是非常鼓勵評估創新的。2004年SEI還沒有推出服務模型。雷神一個(ge) 提供技術服務的子公司組織希望達到CMMI三級，其場景和開發模型相差甚遠，我們(men) 當時做了極為(wei) 大膽的替代，甚至修改了部分PA描述，SEI對我們(men) 的做法極為(wei) 支持，不僅(jin) 審核通過了我們(men) 的評估結果，還將其作為(wei) 一個(ge) CMMI應用案例，後來的服務模型也參考了我們(men) 一些實踐。

2017年，我們(men) 在國內(nei) 一次四級改進評估中，跳出了傳(chuan) 統過程性能模型的做法，大膽嚐試了全新的思路，並在研究院年會(hui) 上做了分享，研究院的後續反饋讓我備受鼓舞和感動。

沒有所謂的CMMI陷阱！借2.0的東(dong) 風，讓CMMI真正變成價(jia) 值驅動器，讓CMMI落地有聲！

此文轉載自老從(cong) 講桌

編輯：陳吉美
審核：胡相富