我不知道的CMMI

 可能是因為掛在我頭上多年的高級別主任評估師和講師頭銜，讓不少朋會認為我對CMMI的了解儼然如宗師。憑心而論，我不反感這樣的誤解，因為它能給我帶來不少好處。

 這篇文章，我想誠懇的承認自己的不足和弱項，但愿從某方面給CMMI正面推進。而觸發這篇文章的動機是最近看到推特上火熱進行的Senior程序員和新手的差異的討論，看到一些軟件大神毫無保留的告訴全世界他們也有許多軟件編程的盲點，鼓勵軟件新人不要迷信所謂人間大神。

 首先，CMMI覆蓋的領域之全令人生畏，CMMI的功夫在CMMI之外，敢于說“不知道”的同時，努力學習探索。和許多所謂資深軟件人員在考慮設計方案一樣，在CMMI改進咨詢過程中，我非常依賴搜索引擎所指向的相關鏈接，也會請教一些朋友。

 其次，對于幾乎所有的CMMI改進者、咨詢師來講，碰到的問題、環境、打交道的人、不同的時間點等因素都可能讓他們在膨脹和怯懦之間翻轉。有時候資深的CMMI實踐者真誠展示自己的不安全感，對于新人也許是種更好的鼓勵。 

  再有，不要對咨詢師抱有不切實際的幻想，真正解決問題好要靠自己。

  下面列舉一些我不知道的CMMI。

  從端到端的考慮，如何確定雙向需求跟蹤的顆粒度；沒有工具支持，大顆粒度的需求跟蹤還有意義嗎？雖然也能給客戶一些建議，但總感覺許多時候沒有幫助團隊找到有效做法，通過需求雙向跟蹤在產品生命周期中使之在動態變更中保持一致、完整。

   缺陷分析在軟件過程改進中扮演重要角色，不同技術文檔的評審和各類測試能幫助我們發現不同類型的問題，這些質量活動的優化往往依賴于缺陷分析。缺陷分析離不開缺陷分類，因為通過類別分析團隊可以對找到共性問題（2-8原則），確定植入階段，揭示過程環節的欠缺。從30年前IBM發表了其缺陷分類的方法和例子后，實施CAR的組織都會照貓畫虎做一些ODC缺陷分類。如何根據團隊能力，業務和技術特點，在一套具備較好指導力的方法幫助下，建立、完善易理解、清晰、可操作、滿足缺陷分析目的的缺陷分類，我還是經常需要去Google，Google再Google。 （CMMI3認證）

   雖然能看到6西格瑪框框下CMMI高成熟度的問題，一些統計技術應用于軟件場景時的游戲世界，但如何跳出這個困境，在統計思維、技術匱乏的環境下，另辟蹊徑，找出有效有價值、可持續、常態化的做法，目前沒有找到具有普遍性的方法。 

  CMMI 2.0明確要求計劃監控應覆蓋運維支持（Operation and Support），眾多要做benchmark評估拿成熟度級別，但其場景又和運維支持毫無關系的組織面臨需要找到等價替代的挑戰。如何找到能實現類似價值、意圖的實踐，我有時也是一頭霧水，給出的建議也是雞肋，其價值僅限于評估。 

   在看CMMI 2.0高成熟度實踐時，我希望誰能清楚的告訴我，項目中的SPC（統計過程控制）到底應該在哪些PA的高成熟度實踐中體現？過程性能模型在項目中的應用又體現在哪里？CMMI 1.3的QPM到底跑到哪里去了？相關的分析方法當然可以在許多僅到三級實踐的PA中體現，但2.0高成熟實踐的系統性、組織和項目的區分真是模糊啊。 

   都知道裁剪讓過程適用的重要性，但如何解決它對工具導入帶來的問題呢？我也百思未到優解。 

   我常常說“不要做僅僅為了評估而做的事”，但在識別一些具體替代實踐，在度的把控方面，真的還有好多事情要學習。  

  在項目中應用CMMI 2.0的CAR實踐時，考慮到項目資源問題、進度壓力、其他一些約束條件，如何實現CAR的要求，讓其在項目中執行常態化，我往往把握不好恰當的度。在領導5級2.0評估時，如何讓隨機選中的項目足夠體現所有實踐，特別是4級和5級的實踐，讓我有時在矛盾中搖擺。（CMMI認證）

  上面這幾條是我可以立刻想到的，并不完全囊括我的盲點，不知和淺知的東西還有很多。

  羅列自己的不足，呈現自己的才疏學淺總是有幾分抱歉自責。但我還是要負責任的告訴你，所謂專家在一些方面并不如你，你也一樣可以做某領域的牛人。 

   當然，作為資深的CMMI實踐者，我的最大價值是經驗。我殺過的豬也許不多，但看過的豬絕對是頗為壯觀。正視自己的短板，虛心求教，我希望做更好的自己,不斷彌補知識的不足。

文章來源叢斌博士