CMM實施中容易被忽視的方面

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

近2~3年來，軟體能力成熟度模型在中國得到了廣泛的重視，也進行了一些實踐，但是總體效果并不令人滿意，一些已經通過了CMM評估的企業的情況并沒有得到應有的改變，其中的原因，讓人深思。就Neco博士來看，這其中固然有一部分守舊的軟體開發和管理人員對于先進管理模式的排斥。但是，更多情況下，是CMM的實施者不了解這個變革的艱巨性和複雜性，忽視了對CMM實施至關重要的一些方面。

Neco博士在此總結了一下，結合案例和大家探讨。

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

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

企業實施CMM，從整體上來說，無疑将提高研發能力，降低缺陷，縮短産品周期。但是在具體實施的時候，卻并非一定如此，或者說在每一個階段都是如此。有研究證明，企業在實施CMM2級的時候，會出現不同程度的産品周期加長，客戶滿意度下降的情況，到了3級，這些情況才會得到解決。那麼企業如何協調各方面的資源來度過這個難關，或者如何選擇最合适的政策讓企業受到的沖擊最小，這都是第一決策人必須考慮的問題。

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

以下就是一個案例

案例1：

V公司和競争對手相比，在技術上并不占有優勢，于是V公司采用了“快速響應”的政策。無論是面對瞬息的市場，還是多變的使用者需求。V公司總能夠搶先于競争對手推出産品，為此受到了市場的肯定。但是V公司在實施CMM的時候，卻錯誤地選擇了“瀑布式”的開發模型，加上相對複雜的實施流程，如果研發體系嚴格按照要求去做，那麼對市場的響應速度必然大大降低，企業的核心競争力受到威脅。但是如果H公司堅定“快速響應”的政策，現有CMM的實施就無法有效進行。V企業走入兩難的境地。

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 的實施要求行為習慣和企業文化的轉變

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

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

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

1	在大規模的複雜系統中建構品質，工程紀律是必需的
2	個人不可能關注所有細節，如果他的工作成果被其他人檢查，将會有助于發現更多的缺陷。
3	我們的成功依賴于其他項目組和客戶
4	組織通過過程定義來改變組織文化中的品質觀念
5	項目通過過程定義來展現組織文化中的品質觀念。
6	過程使得活動品質和産品品質差別開來。
7	組織要想在商業世界上幸存，必須進行不斷的變革，這要求不斷的适應和學習。

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

1	紀律限制創造力的發揮。
2	我們沒有足夠的時間和資源來遵照流程做事
3	隻要有高品質的人員，沒有流程一樣做得好
4	隻要我們盡早把産品送出測試，我們就能夠盡快地推出産品，我們可以通過測試建構品質
5	我們的項目特殊，流程對我們不适用，我們為了遵守流程而付出的額外勞動将會扼殺我們的項目

如果在推行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項目面臨着“設計退化”（Design  Deterioration）的問題，在這種情況下，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項目組配置項僅僅是整篇文檔或者一段代碼，這樣就為接口的變更帶來了極大的麻煩，為了避免麻煩，開發人員隻有在接口發生了足夠多的變更之後才會更改配置庫中的接口定義文檔。這樣就影響了相關人員擷取資訊的及時性，而且他們要查閱整個接口定義文檔才能夠确定和自己有關的接口是否得到了修改。

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

循序漸進，不可操之過急 案例

：Q公司在實施CMM的過程中，采用了合适的政策，那就是針對目前重點，循序漸進。Q公司的産品用于比較關鍵的場合，但是因為不重視品質，是以出了幾次事故，影響了公司形象。Q公司在改進之初，狠抓了測試，建立了測試隊伍，對系統進行了仔細的測試，這樣在其産品的下一個版本上就僅僅出了一次不重要的問題，公司上下對改進的效果都很認可。這樣他們借機進行了文檔的标準化，開發人員也很高興可以通過文檔從以前的項目脫身，在第二步成功的基礎上，他們又開始關注需求過程的改進……