現在的軟件行業競爭激烈，生存環境也極惡劣，為了提高自身的競爭力，提高生產效率和產品質量，不少軟件企業開始想辦法過CMM了，或者根據CMM和自身的經驗制定類似的過程。我曾經研究過一點點CMM皮毛，也經歷過一些公司如何理解及實施CMM的，現在的公司已經過了CMM3，準備過CMMI5。有一組同事專門從事此項工作，并建立了公司的過程，我們也在實施這些過程，也有一些感觸。
首先說文檔吧，公司制定的過程采納了CMM的很多建議，文檔的建立和使用尤其多。從需求到設計再到編碼，然后是測試，發布（典型的瀑布模型），每一步都會有許多的文檔產生。我所在的項目組只有兩個開發，一個項目經理，兩個高級工程師（基本上不編碼），三個測試，僅僅從人員構成上就可以看出文檔占總工作量的比重。需求階段，先寫需求文檔，寫完后大家一起做PeerReview，在會議上發現的問題作為BUG全部記錄到BugTracking中，會議之后除了把問題修改完還要把BugTracking中的記錄全部更新（一條一條地）。這么做的理由是過程組要使用這些數據來分析和提高我們的產品質量。測試人員同時也在寫他們的測試設計和案例，寫出來的比我的設計文檔要多很多，讓我感覺很不好意思。后果是我做完一部分模塊之后叫他們先測試一些，他們說沒時間，因為文檔還沒有寫完。最近去了幾次，幾個人都在埋頭苦寫文檔，我建議他們先寫得簡單點，邊測邊補充，但被拒絕，理由是CMM是這么規定的，搞得我很郁悶。難道CMM會規定我們寫文檔必須要寫成這樣?!其實最失望是做PeerReview，大家精力集中在文檔本身，而不是它所表述的內容上面，會議結束后我的善后工作是要寫成另個一種格式，，內容沒大問題，只花了五分之一的時間來討論。會上很多人要求設計文檔應該再細化，最好是連文件名定好，編碼的人比較方便，以后想查這部分的資料看起來也方便。又是為了以后！這個借口只比“CMM規定”要少。
CMM的作用是有限制條件的，文檔的作用是有限的，你做得越多，最后被拋棄的可能性也越大。CMM中提及的方方面面很多，如果全部采納，公司無法長期承受因此而帶來的成本壓力，CMM也不是短期內就帶來效應的。最后的結果只能是放棄。文檔也一樣，你的文檔越詳細，維護的成本也越高，代碼的小小改動都要修改文檔，維護文檔的時間超過了代碼的維護時間的時候，我們都會選擇不修改文檔。一旦有了第一次，后果顯而易見，文檔最終被拋棄，而不是為后來者提供盡量多的信息。因為你根本無法從文檔中獲取正確的信息，說不定還會誤入歧途。
這段時間我感觸最深的是CMM和實際工作相結合的難度超乎想像，你真的很難說做到這個程度就是合適的。不會過分，也不會不足。CMM比較全面地定義過程，各個公司應該要根據自身的特點改造和擴展CMM，因為大家的目標都一樣，就是要提高產品的質量，提高企業的生產效率。