在軟件工程發展的歷史進程中，人們為了解決軟件危機，嘗試了采用諸如形式化描述語言、結構化開發方法、CASE工具、構件化開發方法等等各種解決方案，但是效果并不那么顯著，CMU SEI提出了軟件過程能力成熟度模型（CMM）基于過程的角度來解決軟件危機。那么是否實施了CMM，軟件企業的開發能力就一定能提高，一定能帶來經濟效益呢？答案是否定的。如果企業里要帶來經濟效益必須要結合軟件過程、工具、開發方法、人員等多種因素一起提高，才能保證帶來經濟效益，因為人員、技術和過程是支撐軟件開發平臺的三條腿，少了那一條都不行。大家也都知道木桶原理，一個木桶可存櫧水的最大容量是由最短的那根木頭決定的。在企業的開發能力中過程、技術(含工具、方法)、人員都是主要的因子，都需要全面提高，只關注一個方面，而忽略了其他方面，都是有害的。
在開始實施CMM時，最容易犯的一個錯誤就是"唯管理論"或孤立地只抓過程改善，忽略了開發技術與人員的提高，過分強調管理的作用，實施了半年或一年后，發現企業的生產能力并沒有得到明顯的改善，這時反對的聲音就會成為主流，過程改善就難以繼續進行了。有的企業采用面向對象的開發方法進行軟件開發，但是企業內并沒有對面向對象技術真正了解的專家，雖然也采用RUP過程、也采用ROSE等開發工具，但是僅僅是形似，沒有做到真正的OO方法，沒有得到OO方法的精髓，這種問題僅僅依靠過程改善是無法解決的。還有的企業開發人員的積極性很差，工作熱情很低，企業的激勵機制沒有起到很好的作用，這種問題也是依靠CMM無法解決的。
管理就是預防，管理的作用是隱性的，不都是立竿見影的，大家要有耐心
在實施CMM時，企業的管理層在開始時往往會對過程改善期望值太高，希望短時間內效果顯著，上面我們談到了，效果顯著與否不是由一個方面的要素決定的，需要多個因素共同改善。而管理的最大作用是預防，防患于未然。
任何的管理的改善都是符合J曲線的，即在改善的初期企業的運行效率可能會下降，甚至可能會出現一些混亂的局面，不過渡過了這段時間就會看到效果。所以在改善的初期大家要有這個思想準備，要有耐心。
堅持活學活用，以我為主
機械照搬CMM的條文是在實施CMM時常犯的錯誤。在國內的軟件企業中，都是從作坊式的軟件組織逐步發展過來的，也沒有經過軟件工程化階段，甚至也沒有什么標準、規范。真正超過10年軟件工程經驗的人員更是比較少的，加上大家不愿從事管理，因而有的企業所組建SEPG的人員中可能在工程經驗方面是有欠缺的，又沒有真正的有實踐經驗的專家進行指導，所以對CMM的理解就不可能一下就很深刻，不敢裁剪CMM，容易機械照搬CMM條文，其實這恰恰違背了CMM的精神，CMM是軟件工程經驗的集大成，是從實踐中總結出來，用以指導實踐的，CMM本身也在更新版本，不斷完善。每個企業都有自己的特點，就象微軟的MSF，那是微軟自己內部的管理過程標準，是微軟的產品開發經驗總結，有些內容是CMM中沒有的，完全可以借鑒過來使用，所以只要可以提高企業自己的軟件管理水平，就應該大膽地來嘗試。
在推行CMM時，所以遇到的阻力，很大程度上是由于照搬CMM的條文，不切合項目組的實際，沒有具體情況具體分析。實際上，一線的管理人員、開發人員最了解實際。誰了解實際，誰有發言權。所以在制定CMM規程標準時，尤其是在制定大家要執行的操作規程、模板和記錄表樣時，一定要得到執行者的認同，否則就容易造成執行和溝通的障礙，你硬要推，表面上看來似乎大伙也照規程做了，其實是表面文章，對改善沒有實際幫助，以導致SPI工作受阻。
要改良式不要革命式
以革命的方式來實施CMM，期望通過一場運動來解決過程能力的問題，一種可能是不懂CMM，不曉得管理的改進是循序漸進的，一種可能是明知故犯，期望在短期內通過CMM評估，單純追求市場上的轟動效應。有的企業在短時間內雖通過了CMM幾級評估，我想恐怕由于沒有實效而得不到大家的認同而難以將這種"水平"持續下去。一個企業引入CMM之后會從本質上影響企業的文化，改變大家的思想與做事方法。有人曾形象得將過程改進比喻為減肥，你是可以依靠減肥藥在短時間內減輕體重，但如果不從根本上改善飲食、生活、運動的習慣，那么體重將會在短時間內恢復到原來，我認為這個比喻是十分形象的。
革命的方式與改良的方式我都曾經嘗試過，效果差異很大。所以我總結一條就是讓大家在"小步快跑"中接受變革，這樣風險最小，效果最好。
CMM與企業的創新文化是不矛盾的
軟件企業的有些管理人員，也包括一些開發人員往往抱怨或認為嚴格的管理會束縛他們的創新，他們認為在CMM中提倡的一種按部就班，什么活動都要做計劃、按規程標準來做，對企業的創新文化會起負面作用。在我遇到的開發人員中，越是技術鉆研越深的人持這種觀點的越多。我想形成這種觀點主要有二個原因：一是企業在推行CMM時，過分機械，沒有從實際出發，不能與實踐緊密結合，挫傷了開發人員的積極性。比如說在分析與設計階段，需要開發人員能夠發揮創意的成分更大一些，如果你要求他們一定就要按統一的文檔標準來寫文檔，甚至字號大小、縮進格式一點也不能差，這的確很難做到，可能你需要在項目組配備文檔支持人員，有他們來做這些完善工作，降低分析與設計人員的這些工作量。二是這類人員缺少真正的軟件工程經驗，做的大項目太少，經歷的失敗太少。關于這一點是不要爭論的，CMM是軟件工程經驗與教訓的集大成，我們無需再去重復那些失敗。
文章來源于領測軟件測試網 http://www.kjueaiud.com/