基於CMM實施軟體流程改善的成功策略

基於CMM的軟體流程改善已經被越來越多中國的軟體企業所接受，目前，在中國已經掀起了一個CMM評估的小高潮， 但是，通過評估不是企業的最終目的，對軟體企業而言其根本的利益是通過實施軟體流程改善，提高企業的管理水平。CMM作為美國軍方評價軟體流程能力的一個模型，他是在研究了美國的一些較大的管理基礎較好的軟體企業提出來，針對中國軟體企業的實際需要靈活裁剪，而且，在CMM中也沒有告訴企業如何按照此標準進行企業的過程改善。筆者從98起開始主持一個企業的軟體過程改善項目，在這3年的時間裡，積累了大量的經驗教訓，現概括出6條策略，供正在或準備實施CMM的軟體企業參考。

策略一：自低向上，主動改進

在進行軟體過程改善的時候，通常有兩種做法，我稱之為自頂下與自低向上。在自頂向下的做法中，企業成立一個推進小組，一般稱為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級的一個最關鍵的基礎工作。

第一步：要求每個項目組首先要定義出自己的生命週期模型，做出專案計劃模版

第二步：要求每個項目組按照專案計劃模版進行做專案計劃

第三步：進行專案計劃跟蹤

第三次迴圈：增加規模、工作量等的度量

第一步：要對項目的規模、工作量進行正式的估計

第二步：按計劃摸版做專案計劃

第三步：進行專案計劃跟蹤

第四次迴圈：增加風險分析

項目的風險管理對於國內的軟體公司而言，一般都是一個痛點，可能風險很多，風險可以預見，但是沒有很好的規避措施。所以建議將風險管理放在較後的迴圈中來改進。

第五次迴圈：體系化，制度化

開始時要求不要太嚴，對文檔的要求要粗一些，要把握住實質而不是皮毛。