近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,組織文化必須認同以下觀點
如果在推行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公司在改進之初,狠抓了測試,建立了測試隊伍,對系統進行了仔細的測試,這樣在其產品的下一個版本上就僅僅出了一次不重要的問題,公司上下對改進的效果都很認可。這樣他們借機進行了文檔的標準化,開發人員也很高興可以通過文檔從以前的項目脫身,在第二步成功的基礎上,他們又開始關注需求過程的改進……
文章來源于領測軟件測試網 http://www.kjueaiud.com/