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