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