面對中國的現實，我們不得不承認，中國的軟體工程水平和軟體生產力水平還是處在較低水平。這裡一方面有素質問題，中國軟體科研和教育水平的滯後，對於國際上先進的軟體工程的實踐和理論的研究和傳播的不足，導致了軟體從業者素質和觀念的落後。而另外一方面則是管理者對建立組織級別的軟體開發管理框架缺乏理論和實踐經驗，更缺乏必要的緊迫感。

近2~3年來，軟體能力成熟度模型在中國得到了廣泛的重視，也進行了一些實踐，但是總體效果並不令人滿意，一些已經通過了CMM評估的企業的情況並沒有得到應有的改變，其中的原因，讓人深思。就來看，這其中固然有一部分守舊的軟體開發和管理人員對於先進管理模式的排斥。但是，更多情況下，是CMM

在此總結了一下，結合案例和大家探討。

1.實施CMM是公司層面上的戰略行動

認為，CMM是典型的“一把手工程”，必須由企業的負責人親自主持。這不僅僅因為需要一個權威來克服CMM的實施中遇到的重重阻力。更深層次的原因是，CMM的實施將對公司的整體經營以至於核心競爭力產生影響，需要企業的負責人全面考慮。

企業實施CMM，從整體上來說，無疑將提高研發能力，降低缺陷，縮短產品週期。但是在具體實施的時候，卻並非一定如此，或者說在每一個階段都是如此。有研究證明，企業在實施CMM2級的時候，會出現不同程度的產品週期加長，客戶滿意度下降的情況，到了

而且CMM所規定的僅僅只是一些抽象的條文，企業在具體實施的時候，有許多靈活的選擇，這就需要結合企業的實際來進行，否則將會產生我們所不期望的後果。

以下就是一個案例

案例1：V公司和競爭對手相比，在技術上並不佔有優勢，於是V公司採用了“快速響應”的策略。無論是面對瞬息的市場，還是多變的使用者需求。V公司總能夠搶先於競爭對手推出產品，為此受到了市場的肯定。但是V公司在實施CMM的時候，卻錯誤地選擇了“瀑布式”的開發模型，加上相對複雜的實施流程，如果研發體系嚴格按照要求去做，那麼對市場的響應速度必然大大降低，企業的核心競爭力受到威脅。但是如果H公司堅定

V企業實施CMM並沒有錯，錯的是他們在實施CMM的時候並沒有考慮到企業的核心競爭力和總體戰略，採用了錯誤的生命週期模型和相對複雜的實施流程，最後導致了這樣的結果。

對公司的戰略影響是一個方面，另外一個方面是，CMM的實施涉及到機構的重組，如果我們不能在組織架構，薪酬待遇，績效考核等方面輔助以適當的政策的話，CMM的實施不可能順利進行。

下面的案例可供參考

案例2：W公司為了推行CMM，組建了獨立的QA部門。儘管在W公司的內部宣傳材料上對QA的作用進行了大肆的宣傳，認為其對於CMM的推行和專案管理都具有重要作用，但是實際上QA人員的資歷都相對較淺，對開發過程，技術和工具都缺乏必要的瞭解。只能夠照搬一些條文來要求開發人員，開發人員對此並不認賬，認為QA人員是沒事找事。另外，QA這個崗位在薪酬和升遷方面毫不吸引人。

為了避免QA部門成為新手和專案組淘汰人員的集中地，QA部門經理設法推行專案經理鍛鍊制度，讓專案經理到QA部門鍛鍊一段時間，然後繼續擔任專案經理或者升遷。但是因為此項制度沒有得到有效的支援，專案經理在QA部門工作一段時間以後竟然沒有開發部門願意接收，就更談不上升遷了。QA部門在W公司的威望江河日下。

QA人員對於質量保證和CMM的實施至關重要，如果我們認可QA人員對於公司的價值，那就必須在人才和待遇上向QA部門傾斜。

2.CMM的實施要求行為習慣和企業文化的轉變

經常給別人進行CMM的培訓和諮詢，通常諮詢者所關心的都是一些技術性和文件性的工作，諸如“我要編制如何的文件才能滿足CMM的要求？”“你能否給我提供設計文件的檢查表以及模版？”之類的問題，他們把CMM看作是條文規範一類的東西。

但其實呢，CMM要求的是企業行為的轉變，是企業文化的變革。條文再精美只是條文，如果沒有人去執行，它就一錢不值。

一般認為，要想在企業中很好地推行CMM，組織文化必須認同以下觀點

但是在很多不成熟的軟體企業中，人們更加認同以下觀點：

如果在推行CMM的時候，不輔助以文化改變的策略和行動，改革將會遇到阻力。

案例3：S公司在推行CMM 2級的時候遇到了極大的阻力，專案經理對估計和計劃過程根本不感興趣。其原因在於S公司有“倒排計劃”的習慣做法。

專案經理對專案的進度安排沒有決定權，當專案經理接受任務的時候，專案的釋出日期早已確定，而且專案經理做出的人力資源請求一般也不會得到滿足，專案經理被迫在一個資源短缺的環境下開展工作。既然Deadline已經確定，增加人手又不可能，專案經理怎麼會對估計和計劃有興趣呢？

與此相對應，S公司的內部宣傳材料在不斷地表彰在資源短缺的困難情形下做出成績的經理和開發人員，對“無原則服從命令”行為的讚許，已經成為了公司文化根深蒂固的一部分，並且得到管理層的默許和鼓勵。

S公司的文化和CMM的要求是抵觸的。CMM要求專案經理對任務的合理性進行分析，要求在理性的基礎上做出判斷，而不是盲目地服從。如果S公司不能夠改變他們的文化，CMM就不能夠得到有效實施。

3.避免官僚主義的陷阱

CMM最初來源於美國國防部，從SW-CMM到CMMI，幾乎都是按照軍火商量身定做的。眾所周知，武器研製專案一般都是大型專案，人數眾多，預算高昂，對可靠性要求極高。在這種專案上產生的實踐，必然有很多是不能應用到商業企業，特別是中小企業上面的，雖然SW-CMM的條文具備足夠的靈活性和抽象性，但是一個沒有經驗的諮詢師會很容易地受到誤導，建議企業實施一個官僚氣十足，步驟繁瑣的管理框架。

案例4：A公司是一個小型公司，但卻採用了一個步驟繁瑣的CMM實施方案，而且沒有采用任何自動化的過程工具，大部分由紙面檔案傳遞來進行。比如在測試中如果發現了一個問題，必須由測試人員找到檔案模版，填寫好缺陷的種類和描述，打印出來，交給相關人員簽字，開發人員的修改結果就只好填寫在紙面上，最後還要找專案經理簽字。相關人員浪費在檔案傳遞上的時間可能比進行開發和測試的時間還要長。

以CMM為模型制訂管理框架，其本質是為了規範管理，減少錯誤的發生。而執行這些管理規程，就其本身而言，並不是我們的目的，而僅僅是一種手段。對這些規程的執行也不創造任何價值。在條件許可的情況下，我們要儘可能地簡化手續，提高效率。並適當地引入自動化工具。像A公司的情況，用一個缺陷追蹤工具就可以大幅度地提高效率。

4.技術和管理一樣重要

CMM不是萬能的，CMM針對的僅僅是過程管理中的問題，在軟體開發中有許多問題並不是過程管理方面的紕漏，我們在改進過程管理的時候，一定要輔佐以先進的軟體工程手段。中國實施CMM的特殊性在於，國內的軟體企業不僅僅在軟體過程管理上存在嚴重的不足，在具體的軟體工程的理論和實踐上也存在缺陷，一些軟體企業甚至沒有獨立的測試部門和專職的測試人員，在這種基礎上，如果僅僅建立一個軟體過程管理框架，其實並不能為企業帶來多少實質性的好處。

案例5：T公司M專案組的成員工作非常辛苦，但是回報和付出不成比例，M專案組在經歷了十幾輪系統測試之後，缺陷數仍然得不到收斂。QA人員試圖通過加強程式碼評審等方式來提高質量，但是收效甚微。

原因在什麼地方？M專案是在S專案的程式碼上修改的，而S專案的程式碼來自於C專案，C專案是H公司最老的專案之一。經過了幾輪開發人員的修改和增強，C專案原來的軟體架構已經千瘡百孔，開發人員在上面進行缺陷的修補和功能增強，要付出數倍於平常的代價，而且經常引發其他問題。專案經理一語中的，“這些程式碼太舊了!”

W專案面臨著“設計退化”（DesignDeterioration）的問題，在這種情況下，W專案組應該有針對性地對某些軟體架構的某些部分進行重新設計。而T公司也應當進行考慮，如果這個最早來源於C專案的平臺仍然有利用的價值的話，專門成立專案組對其“翻新”是非常必要的。

下面這個案例可能更有代表性：

案例6：H公司和Z公司都在研發相同型別的C產品。H公司在推廣CMM，採用了相對嚴格的過程規範，並且把相對重要的部分外包給了印度的CMM5級公司。這些手段Z公司都沒有采用，但是Z公司卻搶在了前面。

Z公司的“祕密武器”是一種形式化語言—SDL，Z公司採用SDL作為設計工具，這樣C產品的相當一部分程式碼可以由SDL工具自動生成，而且在設計階段就可以進行模擬執行，這樣就大大地提高了效率並減少了缺陷。H公司雖然採用了相對嚴格的過程規範，但是因為全部程式碼為手工編制，所以，無論是效率還是質量，H公司都落後了。

H公司顯然忽視了先進技術可能為生產率帶來的進步，通過了CMM高級別的評估，只能說明被評估的組織機構在過程控制上做得更加細緻，但是並不能夠保證你的開發過程是高效的。某些沉迷於CMM的組織機構忘記了先進的軟體工程技術的重要性。

5.重視企業自身的實踐，重視細節

CMM的實施者容易犯的另外一個毛病是不注重企業自身的實踐，尤其是一些細節。他們往往熱衷於參加各種講座和培訓班，希望從美國或者印度人那裡發現一些靈丹妙藥，以為照搬一些條條框框就能夠讓生產力突飛猛進。卻不去關注企業當前遇到的問題，不去傾聽一線人員的呼聲，不注意提煉和總結企業運作中的經驗和教訓。

案例7：G公司的B專案組是一個分散式系統，這種專案在G公司極為普遍，各個模組之間通過TCP/IP協議互相傳送訊息包。在高層設計階段，B專案組的兩個工程師發現，B專案組的子系統C和子系統M採用的訊息格式有很大的不同，子系統C採用位元組型（8位）作為訊息的ID。而子系統M採用短整型（16位）作為訊息的ID，在系統執行中必然會出現問題。兩位工程師通過電子郵件發出呼籲，要求重視這個問題，但是沒有引起關注。最終在幾個月之後，專案經理意識到了問題的嚴重性，專案組不得不花費一週的時間來進行修改和重新測試。

對於這個案例，大家通常會認同“傾聽和理解”的重要性。但是精明的過程管理專家會有更深刻的思索。既然類似專案在H公司極為普遍，那就有必要在開發規程中制訂條例，要求專案組在設計階段必須統一訊息格式，並給出指導，否則這種問題還會重犯。

這一點在下一個案例中體現得更為明顯。

案例8：H公司的B專案是一個龐大的專案組，技術相當複雜。名詞術語很多，而且對於同一件事物的表達方式也不盡相同。專案組非常有必要制定一個規範的術語表，既統一了說法，也方便專案組的新人查閱。但是事情的發展是很有戲劇性的。

專案組在起初並沒有重視術語表的編制，因為人少，產生的文件也不多，所以這件事情無人重視。但是到了專案進展了1/3左右，術語的混亂已經相當嚴重的時候。B專案組的一個工程師X自發地開發了一個小程式，用於查閱術語的名稱和縮寫。專案經理對X工程師的做法提出了表揚，並委任X開發和維護這個標準術語表。

專案經理和相關部門的始終沒有意識到：（1）開發和維護這樣的標準術語表是專案經理和配置管理人員的職責，不是某一個軟體工程師的任務。（2）類似的問題在別的專案組一定出現過，以後的專案組一定也會遇到，必須在開發規範上堵住這個漏洞，讓別的專案不會重蹈覆轍。

所謂的“管理無大事”，過程管理的真諦就在於這些看似細節的小事。基本的過程管理原則和規範只是“骨架”，而“血肉”是要靠這些看似細枝末節的小事來豐滿的。積沙成塔，集腋成裘，點滴持續地改進，其效果最終是巨大的。

對細節的忽視在國內的IT企業幾乎隨處可見，下面有個案例

案例9：Neco博士曾經審查過M公司的W專案，W專案是一個用Visual C++開發的專案。但是W專案組對於程式碼文字和目錄結構都相當漠視。W專案組所屬的部門有一個編碼規範，但是幾乎沒有人看過，也沒有人願意遵照執行。W專案的C++程式碼混亂不堪，不僅毫無美感可言，而且成為BUG滋生的溫床。M公司對開發人員使用的工具幾乎沒有什麼限制。在國內盜版氾濫的大環境下，獲取開發工具幾乎是免費。所以在M公司，選擇工具是很隨意的，開發人員甚至可以按照個人的好惡進行選擇。這造成了維護的極端困難，而且因為開發工具太多，公司無法集中資源進行培訓和指導，所以開發人員的技能無法獲得有效地提高。

6.總結和建議

瞭解企業的現狀，對症下藥

實施CMM其目的是為了解決企業目前存在的問題，為了增強企業的核心競爭力。要解決問題，那就首先要知道企業目前面臨的問題是什麼，要明白我們採用CMM這個工具能夠得到什麼。以下有個案例：

案例：H公司的C專案組是一個大型的專案，而且因為C專案是一個複雜的分散式系統，所以各個子系統之間的介面和訊息互動就顯得特別重要。

但是C專案組的配置管理人員卻不把介面作為一個單獨的配置項來管理。C專案組配置項僅僅是整篇文件或者一段程式碼，這樣就為介面的變更帶來了極大的麻煩，為了避免麻煩，開發人員只有在介面發生了足夠多的變更之後才會更改配置庫中的介面定義文件。這樣就影響了相關人員獲取資訊的及時性，而且他們要查閱整個介面定義文件才能夠確定和自己有關的介面是否得到了修改。

專案組的成員僅僅把配置管理庫作為一個“檔案庫”來使用，而採用郵件通知的的方式私下協商和通知介面變更情況。那麼實際上等於介面變更失去了控制。

循序漸進，不可操之過急