CMM/CMMI不是軟體企業唯一的選項

CMM/CMMI目前在國內似乎很熱，大大小小的公司都爭先恐後申請CMM評估並爭取政府在財力、人力和物 力上的支援，有個別公司只用了2年的時間就通過了CMMI 5級！

這是喜訊，還是噩耗？

這不是喜訊！

CMM/CMMI來到中國已經變質。只要花錢，只要招待，你就可能拿到一張認證。雖然拿到了這個認證， 但是軟體企業並沒有得到什麼實惠。舉例說來，軟體企業的效率、過程的能力仍然是跟以前一樣，因為 CMM/CMMI在做的同時，他們仍然在按照原來的方法在做，原來的體制在運行。這就造成了幾張皮的現象， 一邊按照CMM/CMMI做各種需要的文檔，一邊還在按照老傳統做什麼調研、方案設計、調試，跟CMM/CMMI並 不合拍。這是問題之一。

CMM/CMMI是一個評估的依據，也是一個流程改善的架構，並不是一個標準。但是國內卻把它用來做標 准。例如，資訊產業部標準SJ/T 11235和一些軍用標準。把CMMI作為一個標準本身就有問題，更不用說用 這個標準來評估企業能力成熟度等級，給他們發認證。況且，這種認證並不一定為國際上承認。關於這方面的 問題，可以參見《中國軟體企業遭遇CMM認證陷阱 CMMI、行標攪局 》一文。http://www.e- works.net.cn/ewkArticles/Category114/Article14098.htm ——這是問題之二。

CMM/CMMI來到中國水土不服。CMM/CMMI體現了西方的“三權分力”的思想。SEPG相當於立法機構，而 軟體項目組相當於行政機構，SQA人員相當於司法機構。三者相互制約。SEPG所出的規範需要得到軟體項 目組的認可，規範在執行過程中需要進一步與項目組的實際結合從而進行改進；而SQA人員則是需要監督 軟體過程是否按照規範來執行，從而決定是否開出不符合項NCI。另外，系統測試人員也需要具有相當的 獨立性，不能處於項目開發人員的控制之下。所有這些，在一個以技術能力決定一切的公司裡頭根本就不 可能做到。例如，軟體專案經理兼有需求分析、設計、編碼和測試的職責，對於專案計劃、進度、跟蹤的 工作則是能做到什麼程度就做到什麼程度。這種軟體專案經理和技術主管職位不分、職責不明的做法怎麼 能夠做好CMMI? 這是問題之三。

CMM/CMMI不是為軟體研究性項目設計的，而是為產品項目設計的。對於那些研究性的項目，搞上CMM， 等於把自己打進了死牢。研究性的項目需要創新的思想，需要更多的實驗與思維，給與研究人員更多的創 新空間，而不是能夠在短時間內出產品的，不是需要更多的文檔和過程。所以，需要搞清楚你的項目是研 究性的，還是產品性的，不要盲從CMM/CMMI。這是問題之四。

CMM/CMMI不可以以強權方式實施。按照正常的步驟，軟體企業做CMM/CMMI先從二級做起，先是各個項 目按照自己的實際形成項目的過程，因此，在二級不同的項目的過程可能“五花八門”。到了三級，才開 始將不同項目的過程分析總結，並形成一個組織的過程標準。所以，筆者認為二級不能少，不能越級做 CMM/CMMI，也不能以做三級的方法來做二級的過程，即先做一個企業的CMM2級規範，然後強行向項目組推 動，這顯然違反CMM/CMMI流程改善的原則。因此，需要收集不同項目的過程實踐經驗，體現一種“民主” 的思想，經總結分析才能形成組織的過程。用相反的方法來推動CMM/CMMI的實施，只能得到失敗的結果。 現在很多企業在做CMM/CMMI總是先成立一個SEPG組，首先制定一套企業的過程規範，強行向軟體項目團隊 推動；有時候，還直接越級評估，直接上三級、四級，操之過急，令人懷疑其實施CMM/CMMI的動機：到底 是為了改進，還是為了拿證。這是問題之五。

綜合以上的問題，筆者認為，不要對CMM/CMMI熱過了頭。軟體企業可以選擇CMM/CMMI，也可以選擇 6Sigma，也可以選擇ISO9001。小公司也不要急著上CMM/CMMI或者更多的流程改善架構，免得給自己上套 ，花了錢不算，束縛自己的手腳。