cmm/cmmi是中國軟體外包走向世界的不二法門？——自欺還是欺人？
能夠幫助中國的軟體外包企業走向世界一直是諮詢公司們不遺餘力推廣cmm/cmmi的乙個重要的說詞，那麼果真是這樣嗎？
目前外包市場上主要分為「對日外包」和「歐美外包」，日本人對我們中國人好像從來就不怎麼相信，給我們的外包絕大多數都是比較初級的編碼工作，有些甚至將厚厚的偽碼都拿來過來，我們做的基本上都是些體力活，同時承接對日外包的公司大多有日資的背景，且大多都延習了日本企業的那一套管理和協調機制。
相對來說歐美人對我們國人的期望要高一些，不過本人曾經有幸在境外參加了乙個旨在為國外發包商和國內軟體企業牽線搭橋的科技展會，接觸了不少有意向中國軟體公司發包的外商，他們最關心的是兩個事情，乙個是對智財權的保護，另乙個則是人力資源上是否具備和甲方進行有效溝通的能力。關於開發的管理，有乙個老外的話讓我感到深深的悲哀，他說，如果在美國，乙個企業如果拿出任何能夠證明其公司管理能力的資料，他都不會有任何懷疑，而在中國："no，i only believe my eyes!"
有乙個很有趣的事例是，國內有一家非常知名的cmm諮詢公司的老闆的乙個美國朋友應邀來到中國，希望為其在美國的乙個大專案在中國尋找開發商，該公司擁有大量的實施過cmm/cmmi的客戶，其中不乏專門從事軟體外包的，按說在其中尋找乙個滿意的開發商應該是唾手可得，然而事與願違，所有的嘗試都在第乙個環節就不得不終止，原因非常簡單，因為所有的候選企業都沒有派出乙個能在技術、業務、管理和商務層面和美方有效溝通的人來，更有甚者，有些公司乾脆拿了一大堆的中文資料就來和老美溝通，結果可想而知。最後，這位老美不得不放棄了這個計畫。
顯然這一切都和cmm無關。
軟體過程改進及其基礎構建——我們在空中樓閣中舞蹈
所謂的「軟體過程改進」，應當按照在乙個循序漸進和有序的過程進行，當初sei制定cmm的應用物件都是非常大型的航天和軍工軟體的承包商，這些企業基本都具有相當的規模和良好的規範化基礎。顯然，對這樣的企業實施基於cmm/cmmi的軟體過程改進是有意義的。反之，如果是乙個完全缺乏規範管理的軟體公司來說，連基本的軟體工程規範和質量理念都不存在，盲目追求所謂cmm的某個級別只能是空中樓閣。
不幸的是，這種完全管理無序的公司在國內實施cmm/cmmi的企業中還不是少數，顯然，這也並不是sei當初制定cmm所考慮的範疇。
對於這樣的企業，首先應該進行的並不是去執行什麼基於cmm/cmmi的軟體過程，而是紮實的完成軟體過程的基礎構建(這也是過程躍遷的乙個重要組成部分)，甚至非常有必要在實施cmm/cmmi前在企業內部引入psp/tsp，然後在循序漸進的進行有針對性的軟體過程改進。
然而，非常遺憾的是，本人看到不少這樣的企業在短短不到一年的時間裡就能通過所謂的cmm或cmmi**（現在，國內企業對二級大多已經覺得不過癮了，往往一上來就直接上**）評審，效果如何可想而知。實際上這只不過是一場由諮詢公司導演，軟體企業主演的「評審」秀而已。
cmm/cmmi中有乙個最為核心的思想就是：只有好的過程才能導致好的結果，上述的現象倒是該思想的乙個非常好的反面例項。
好的過程＝好的軟體？——瞎子摸象故事的現代軟體工程版演繹
cmm/cmmi最原始的出發點是重過程管理而輕工程方法，這對於最初的cmm應用物件－－美**方軟體的承包商或許是有其合理性的，但是對於其他眾多的軟體企業，由其是國內的軟體企業就並不是那麼的合理了，個人認為國內的軟體的特點是規模有限，業務領域較廣，技術週期較短，軟體工程基礎較差，對於這樣的企業，有效的工程方法往往比有效的軟體過程更能讓企業獲得即時的效果。
軟體開發管理是乙個非常複雜的系統工程，其涉及到企業技術和管理的方方面面，而且其各個因素又是相互關聯和制約的，不均衡的過分強調其中的某乙個或某幾個方面都是不科學的，也是難以取得良好效果的。
cmm實施——削足適履的痛苦旅程
cmm/cmmi的初期培訓往往是最令人愉快的，參與者們在了解了大量以前沒接觸過的知識後往往對cmm燃起了高昂的熱情，但是隨著進入過程定義和專案的試執行就會漸漸發現身陷沒完沒了的文件編寫和無休無止的各種會議，加班成了家常便飯。這時候，早先的熱情早已蕩然無存，而早先諮詢公司宣稱的能為企業帶來無比效益的「先進過程」也成為了一件非常不合尺寸的緊身衣.....等咬緊牙關挨到了預評估，結果往往是當頭一棒——和要求相距甚遠，而正式評估的日子又已經迫在眉睫，怎麼辦？於是乎大家發揮國人的應試特長，將cmm正式評審變為一場期末考試，這時候,諮詢公司往往扮演"槍手"的角色,將評估中可能遇到的問題及其答案羅列出來，而軟體公司中的相關人員則將這些答案牢記於心。最後，在通過一場大家心照不宣的所謂「評估」，終於大功告成。
cmm評審——對皇帝新衣的自我陶醉
在上海某個高科技園區，有乙個軟體公司的外牆上高高的懸掛著一塊牌子——"cmm5級企業"，這在專業人士看來恰恰是對cmm本質的曲解，非常遺憾這種曲解竟然是發生在乙個通過5級評審的企業。
cmm本身只是乙個可以被用來評估企業能力成熟度的過程框架，而並不是什麼「標準」，cmm的重點在於軟體過程的改進而不在於什麼「評審」，至於所謂的「認證」那更是扯不上邊的事情。
所以當我們捨本求末，將cmm作為一塊可以證明其高貴身份的金字招牌到處炫耀時，令我們不由得聯想起安徒生筆下的那個酷愛新衣的光屁股的皇帝
結論cmm/cmmi本身是一套非常有價值的過程模型，但簡單的將其圖騰化卻是整個中國軟體行業的悲哀，反觀cmm/cmmi的發源地——美國，除了和軍方有業務往來的軟體企業會尋求通過cmm/cmmi評審外，其他多數的企業並不怎麼在乎是通過了cmm/cmmi的**還是四級，象是著名的微軟、甲骨文等知名企業都沒聽說過和cmm/cmmi沾過邊，但這也絲毫不影響以他們為代表的美國軟體企業在整個行業中獨領**。
所以，我們認為，只有有效的而不是最權威的，才是最好的。
程式設計師特區
敏捷和CMM的異同 專家觀點
q 雖然敏捷技術在國內出現的時間並不長，但是最近越來越多的開發和測試人員關注並熱衷於此。甚至有人說過 cmm已經落伍了，敏捷才是王道 之類的話。您怎麼看？能說說cmmi與敏捷式開發的異同嗎？a 如果有人說敏捷式開發優於cmmi，那麼首先他一定不了解cmmi的真正含義。如果乙個企業敏捷式開發流程符合公...
CMM和CMMI過程域的比較分析
級別 cmm過程域 cmmi過程域 說明與比較 2 需求管理 軟體專案規劃 軟體專案追蹤與監控 軟體子合同管理 軟體質量保證 軟體配置管理 需求管理 專案計畫 專案監督和控制 商合同管理 過程和產品質量管理 配置管理 度量和分析 專案過程管理的基本內容，實際是組織中某個或某幾個團隊的過程能力，可以說...
基於CMM和CMMI的配置管理（一）
本文主要從cmm和cmmi的要求出發，介紹了標準主要涉及的配置管理內容，並對相應內容進行初步地說明，最後提供了乙個配置管理在專案實施的指南和乙個在組織中部署配置管理的模型。1配置管理內容的邏輯關係 在cmm和cmmi中，將配置管理的目的定義為 建立和維護產品的完整性 這個目標沒有提到對專案管理的支援...