策略一：自低向上，主動改進
在進行軟件過程改善的時候，通常有兩種做法，我稱之為自頂下與自低向上。在自頂向下的做法中，企業成立一個推進小組，一般稱為SEPG(軟件工程過程組)，他們是企業里"開發大法"制定的組織者。SEPG組織一些開發人員成立各種任務小組，由這些任務小組根據進行過程改善參照的標準編寫各種各樣的企業的標準與規范，經過一系列的評審、培訓，然后讓開發人員去執行。在執行過程中最常見的阻力是來自于開發人員，他們往往會抱怨制定的企業開發規范不符合企業的實際情況，標準太高，無法達到。 這一種做法，費時費力不討好，大家的意見都比較大，標準定的比較完美，而且在評審時還要大家表面上都要認可，制定標準的人花費了很大的精力，對標準的評審浪費了大家的很多的時間，執行時還難以貫徹下去。這種方式98年、99年上半年我在企業里采用過，收效甚微。后來我們降低了要求，拋棄了各種標準與規范，采用了一種簡單易行的策略，自低向上的辦法，即由SEPG找開發人員、項目經理讓他們自我發現問題：你有什么缺點?你將如何改進?好，在開發人員、項目管理人員講自己的改進措施后，讓他們確保能做到。在這種辦法中，不需要管理人員花費太多的精力進行標準的制定，改進的推動，這些工作都是由開發人員自己去做的，管理人員僅僅是起到了監督的作用，只要開發人員自己說到做到就可以了。再做下一個項目時，管理人員同樣會問這2個問題：你有什么缺點?你將如何改進?然后管理人員監督開發人員說到做到。在這個過程中逐步完善形成標準與規范。
在上面的兩中方法中，我們可以從幾個方面進行比較：
當然采用第2種方法時，你一定要目標明確，你是要改進過程，而不是為了在短時間內通過評估。
策略二：循序漸進，由易到難，由粗到細，由松到嚴
CMM的一個核心思想是分級改進，在CMM模型中將軟件企業的過程能力分成了5級，有很多企業很可能違背了分級改進的思想，搞了一場革命，期望短時間內提高管理水平，那顯然是不現實的，我們要需要的是改良而不是革命。分級改進實際上就是要循序漸進，你能一步做到2級嗎?不可能的，對于2級的每個KPA，可能你先實現了每個KPA的一部分活動，穩定了，再實施另外一部分活動，如果你現在1級，想一下子將2級的所有的KPA的所有活動都滿足是不現實的。在實施CMM的過程中一定要根據企業的實際情況量力而行，千萬不要期望值太高，要一步一步來。先定出最基本的改進方案，然后逐步提高，要把握分級改進的思想。
要做到循序漸進，首先要對企業現狀有一個明確清醒的認識，在分析現狀時，下面的四個問題是必須要解答的：
當前我們存在哪些問題(當然，問題可能很多)?
哪些問題是我們迫切需要解決的?
哪些問題是我們目前能夠解決的?
哪些問題是我們當前無法解決，需要打好基礎后才可以解決的?
接下來要對照標準，提出解決方案。按照"力所能及，有所提?quot;的原則對問題排出優先級。
以SPP、SPTO這2個KPA來說，你可能可以采取5次循環達到CMM2級的要求：
第一次循環：從無到有，使項目組成員熟悉做計劃的過程，熟悉項目計劃跟蹤的重要性。
第一步：要求每個項目組都要用PROJECT 2000做項目計劃，該項目計劃要滿足一定的條件，如：
任務的顆粒度不能太大;
任務負載要均衡;
任務盡可能并行;
等等。
第二步：對每個項目組，按計劃進度進行跟蹤，在計劃執行過程中及時發現問題，解決問題。
第三步：總結本次循環執行過程中存在的問題，如：
項目計劃中任務識別不全;
計劃的任務工作量估算不準;
在項目進行過程中，發現問題后采取措施不及時等等。
第二次循環：增加完整的生命周期模型定義
生命周期模型是項目管理的管理的主線，定義一個好的生命周期是推行CMM2級的一個最關鍵的基礎工作。
第一步：要求每個項目組首先要定義出自己的生命周期模型，做出項目計劃模版
第二步：要求每個項目組按照項目計劃模版進行做項目計劃
第三步：進行項目計劃跟蹤
第三次循環：增加規模、工作量等的度量
第一步：要對項目的規模、工作量進行正式的估計
第二步：按計劃摸版做項目計劃
第三步：進行項目計劃跟蹤
第四次循環：增加風險分析
項目的風險管理對于國內的軟件公司而言，一般都是一個難點，可能風險很多，風險可以預見，但是沒有很好的規避措施。所以建議將風險管理放在較后的循環中來改進。
第五次循環：體系化，制度化
開始時要求不要太嚴，對文檔的要求要粗一些，要把握住實質而不是皮毛。
策略三：教育與培訓并重
任何一種標準的推廣總會將培訓放在一個很高的位置上，我不太喜歡用培訓這個詞，我更喜歡用教育這個詞，我們的一個關鍵目的不是告訴他技能，而是要改變他們的思想，因此，首先要做的工作是教育。要讓各個方面的人都能夠接受這些先進的思想，以便于主觀上認可，客觀上配合。進行教育有各種方式，需要配合起來使用：
觀摩學習：看看別的做的好的企業是如何做的?和別的企業的管理人員多溝通交流。尤其是對企業的高層管理人員這點很關鍵。
請外面的專家來講：俗語講的好"外來的和尚好念經"，這句話屢試不爽，企業內的人說多遍可能效果甚微，外面的專家講一句，一下就點透了，接受了。
自我反�。洪_發人員進行自我分析找出自己的不足，并提出改進意見，大家互相溝通交流這些經驗教訓，自己教育自己。
補上"教"：我們的很多軟件工程師、項目經理的經驗并不是很充分，也可能比較固執，不撞南墻不回頭，沒關系，允許他犯錯誤，但是要有人幫他記錄他的錯誤，提醒他認識自己的不足，加深他的印象。
培訓：培訓可以分成多種：技術型培訓與管理型培訓，這是最基本的工作，思想工作做通了，培訓起來效果就會比較好。 SPI不能僅僅定義為開發部門的工作，需要整個企業的所有人員的參與和重視，因此教育與培訓的對象比較多，不要有遺漏，如：
高層管理人員：為什么要進行SPI?在過程中會出現什么問題?對公司有哪些正面與負面的影響?需要領導配合做哪些工作?要認識到工作的艱巨性。
開發管理人員：技術與管理知識
開發人員：技術與管理知識
市場人員：要認識到SPI的重要性，對市場的影響，在此過程中如何配合?
客戶：對于一個項目而言，需要提出合理的進度、質量與投入的要求，并把握好需求的范圍。
策略四：測試先行
盡管測試在CMM中沒有作為一個單獨的KPA存在，但是，加強測試卻是我們實施CMM的一個很好的策略。在管理基礎薄弱的軟件企業里面，通過加強軟件測試，可以直觀地發現很多問題，從而使大家認識到質量的重要性，認識到進行過程改進的重要性，事實勝于雄辯;另一方面也減少了用戶發現錯誤的概率。在很多軟件企業里面并沒有專職的測試人員，測試一般是有項目組自己進行，而且往往也是在項目結束時才進行測試，在項目進行過程中很少進行測試，這就是現狀。
設立專職的測試，讓他們在開發過程中參與測試，可以發現項目開發過程中的很多問題，如：
項目組提交給測試人員的文檔太簡單，測試人員無法看懂;
項目組提交的文檔與實際做出來的軟件不一致，測試人員無法測試;
項目修改了需求與設計，沒有及時通知相關人員，測試人員按舊的設計測試，有的開發人員按新設計開發，有的開發人員按舊的設計開發;
不同的模塊界面風格差別很大，沒有統一的界面標準;
測試人員測試的版本與開發人員開發的版本不統一;
項目組成員的分工不合理。有的開發人員任務重，而他開發的軟件缺陷特別多，有的模塊缺陷就特別多，可能設計人員的能力比較弱;
項目組沒有按計劃提交測試，項目拖期;
軟件運行速度很慢，懷疑系統的設計有問題;
……… 通過對錯誤原因的分析，可以發現大量的管理問題、需求的問題、與設計的問題沒，這些實在的統計數字對我們找出最關鍵的改進點、說服反對派、教育軟件工程師、加快SPI的推進是一個有力的武器。
策略五："因材施教，各個擊破"
在一個企業內可能有個開發項目組或者開發部門，不同的組與部門原來就有不同的管理水平，在我們推行CMM時，不要一刀切，不要希望每個隊伍同時達到CMM2級或更高的級別，應該區分對待。比如說做產品的部門，經常進行大大小小的各種各樣的升級，產品的版本比較多，他們對版本管理的工作認識的很深刻，在工作中積累了一套行之有效的版本管理的方法，版本管理比較正規，對于這樣的部門可以實施配置管理KPA的要求，進一步提高管理水平，而對于其他做系統集成的部門這方面的工作可能就差一些，沒有很好的版本管理的基礎。因此，如果一刀切，要求大家都在3個月內達到CMM2級的要求，這個目標對系統集成的部門講，就定的太高了。當然通過一場運動來提高管理水平是可以嘗試的，但往往是不能持久的。
所以在進行改進時應針對不同的項目組、不同的部門定出不同的改進計劃，如可以采用下表的方式來定義不同項目組、不同KPA的階段計劃：
策略六：充分利用管理工具
管理工具可以做為思想、方法的載體，他可以將管理有形化、客觀化，降低勞動強度，解決手工無法解決的問題，易于為開發人員、管理人員所接受。充分利用管理工具來推行SPI的一個很好的策略。
很早我們就引進了MKS SI配置管理工具，Poject 98計劃工具，SQA 測試工具以及QA monitor等其他的一些管理工具。開始引入的時候是有些難度，畢竟是對工作方法產生了改變，一旦熟練了，就習慣了，目前它們已經成了大家在工作中必不可少的工具。
對工具的選擇與購買需要把握好"夠用既可"的原則。軟件開發管理工具一般比較昂貴，如果一次性投資購買了比較昂貴的軟件，可能軟件的80%的功能用不上，等企業的管理提高到工具軟件可以支持的較高的管理水平，已經是2年以后的事情了，而2年以后的版本也需要升級更新了，所以，沒有必要為用不到的80%的功能提前投資。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
