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