小型軟體企業實施CMMI流程改善案例

文章目錄

•  

 

本文案例對象是一家小型軟體組織A1，有員工12人，其中10人從事軟體開發，2人從事管理、市場和銷售等其他事務。A1細分為兩個部門：生產部門和研發部門。這個組織屬於典型的CMM層級1的組織，沒有明顯的過程支援，靠的是精英，沒有品質控制和度量資料。按照CMMI模型提出一套簡單可行的實施過程和模型，給出簡單可行的操作步驟，大大減輕了企業的流程改善壓力，充分利用兼職和全職資源，並同時提供“小型軟體企業流程改善支援環境（SSE-PISE）”流程改善支援軟體來支援其流程改善。

一. 剪裁過程和原則

CMMI剪裁過程的目的不是重新編寫CMMI，而是根據小型軟體企業的特點對其文檔、實踐、評審、資源、培訓和管理等進行改造，同時保持CMMI的精粹和結構。由於各個軟體企業的具體改進方向不同，採用的改進策略不同，使用的模型不同（連續式或者階段式），本文不逐個解釋如何剪裁KPA，這樣做不容易抓住主題，而且容易陷入細節中，我們討論剪裁文檔、管理、評審、資源、培訓等的普遍做法和原則。

1. 文檔剪裁

CMMI過程模型包含大量文檔，包括策略、計劃、規程、標準和報告等，如果嚴格按照CMMI實踐來做，小型軟體企業的有限資源會被文檔所淹沒，而喪失對改進本質的掌握。我們採用的策略是合并或者擴充文檔，減少產生文檔的負擔，並藉助於“小型軟體企業流程改善支援環境（SSE-PISE）”來實現文檔的快速產生、分發、合并和管理。主要剪裁策略包括：

文檔合并。 文檔合并是符合CMMI主旨的，CMMI也定義非形式化計劃作為形式化計劃的一部分。我們可以擴充之，項目級文檔可以是其他項目級文檔的一部分，組織級文檔可以是其他組織級文檔的一部分，前提是保證文檔的可識別性。

可以充分利用資訊系統的存取控制機制，實現文檔的更大程度合并，比如每個項目的項目級文檔只有一個，比如專案計劃，對於不同角色，只能看到相應的資訊段，進行自己許可權範圍內的輸入、修改、閱讀、轉寄等操作。

對於相關性較強的文檔，尤其是某文檔是其他文檔的簡化版本，則完全取消前一個文檔，或者藉助於資訊化系統來實現自動產生。

文檔消除。 對於沒有涉及到的文檔，則完全刪除，不必提供，但是要在項目級文檔中解釋所採取的措施。對於資訊冗餘的文檔，則完全刪除；對於有價值資訊量很少的文檔，則刪除本文檔，然後把有價值資訊量合并到相關度最強的文檔中。

資料項目抽取。 對於不同文檔中的公用資訊，利用資訊系統從公用資料來源抽取，保證資料的正確性、一致性，同時減少重新輸入的工作量。

在本文討論的案例中，我們充分利用Lotus R5的多媒體文檔有關機制，組織級文檔只保留一個；每個項目只保留一個項目級文檔。對於組態管理（SCM）等KPA，基本上也限制在每個項目一個配置計劃文檔。當然，這個系統提供有關機制，能夠保證可以從同一個文檔衍生、列印輸出多個子牡擔腫韃煌『鮮褂謾?/p>

2. 管理剪裁

CMMI中任務分工非常細，涉及到的角色也非常多，但是對於小型軟體企業來說，根本沒有那麼多人力資源來分工承擔這麼多管理工作。比如CMMI中的資深經理在小型軟體企業中很可能就是公司總經理或者CEO，但是很多細節性任務他又不可能，也沒有時間自己來做。而且，在小型組織和小型項目中，很多角色實際上是重複的，比如在小型項目中，任務領導、軟體經理、項目軟體經理，以及專案經理的角色時重複的，沒有必要單獨設定。鑒於CMMI的管理結構與小型軟體企業存在較大差距，有必要對管理活動和管理角色進行剪裁。主要剪裁原則如下：

剖析KPA和管理工作，把相關的，不必要保證獨立性的KPA綜合起來，把相關管理職責分配給單個經理進行管理。

除非在絕對需要資深經理承諾的情況下，一般不設定資深經理這個管理職位。

合并管理工作，沒有必要重複設定經理職位，可以把相關職責交給有關技術人員或者管理員來實施。

在本文討論的案例中，我們把KPA進行分類，保證“過程和產品品質管理”過程域的獨立性，其他KPA進行實施時都實施一人承擔多個職責，並把權利和職責合并和下放，每個項目只設立一個專案經理和一個SQA經理，專案經理負責項目的計劃、實施、部署和維護。KPA經理負責對項目實施進行監控，安排評審、擷取度量和分析資料，以及提出改進建議。

3. 評審剪裁

CMMI實踐中涉及很多類型的評審活動——管理評審、同行評審、SQA審計/驗證/評審、正式評審，以及技術評審，幾乎對所有項目相關的關鍵決策和關鍵文檔和活動都需要進行相應的評審，以建立公用基準。對於小型項目和企業而言，如果按照CMMI模型所有評審活動都實施的話，評審所花費的時間會嚴重影響開發時間，因此很有必要對評審活動進行剪裁。主要剪裁原則如下：

適當合并評笫導０湊誄MMI模型，進階管理層需要參與的評審太多，但是經理和具體實施者經常是在一個辦公室工作，溝通非常方便，很多評審活動可以簡化和合并，甚至取消。

實踐證明，評審頻率與項目是否關鍵，以及項目期間，關係非常密切。比如在非關鍵的和短期項目中，評審頻率應該不影響專案生命週期，相應的管理評審、軟體風險評審，以及SQA活動評審的頻率應該降低。

把評審實踐非正式化。充分利用其他會議或者碰頭機會解決評審需求。

SQA評價、審計和評審沒有必要對所以產品都及時進行，應該只進行抽查。SQA評審被證明會嚴重增加小型項目的工作量。應該在SQA計劃中明確SQA抽查活動和工作產品。舉例說明可以抽查進行評審的活動或者工作產品：

（1）對KPA中活動和工作產品的SQA評審和審計；

（2）關於軟體基準的SCM審計；

（3）子承包商的SQA計劃和活動的評審；

（4）子承包商執行情況的評價。

大型項目和小型項目的一個主要區別是在狀態報表方面經理和員工之間工作關係不同。在小型項目中經理通常把主要精力放在技術層面上，因此在小型項目中實施大規模的狀態報表機制是不必要和不合適的。為瞭解決這個問題，需要剪裁和合并很多CMMI評審實踐，尤其與高層專案管理層和SQA聯合進行的項目跟蹤評審。在本文討論的案例中，我們只對關鍵工作產品和裡程碑進行正式評審，其餘評審進行合并，或者進行抽查評審，或者非正式化，降低評審工作量，充分利用小型項目的溝通便利、合作緊密的優勢。

4. 資源剪裁

CMMI模型規定很多執行管理和工程任務的角色，但是在小型組織和小型項目中根本沒有那麼多人能夠全職執行CMMI要求的角色。實際情況是，工程師和管理員可能同時執行多個角色，甚至跨越多重專案。比如，專案經理也許管理多重專案，也許同時從事管理和技術工作。SQA人員也許來自於其他項目，或者來自於其他組織和公司，SQA和SCM人員也許同時負責多重專案，並且個人也許參與到多個工程科目。同時，對於小項目而言，實現諸如SQA、SCM、培訓和SEPG的人員全職化也是不現實的。通常是，這樣的團隊經常包括多個兼職人員，以及一個全職人員

在小型項目中，人員不是唯一受限的資源，每個KPA中“執行能力”部分提到的工具資源通常指的是自動化工具。在小型項目或者小型組織中，很多自動化工具不僅昂貴，而且不適合。對於不成熟的軟體過程，通常不能有效地使用大型CASE自動化工具。為瞭解決小型軟體組織和小型項目中有限資源問題，我們需要對CMMI進行剪裁，主要剪裁策略如下

個人可以執行項目或者組織中的多個角色；承認兼職角色和職責；可以利用組織之外的資源。

向外延展群組（group）的概念，，使之可以包含兼職人員。

根據項目和過程成熟度等級需要選擇合適的自動化工具。在小型項目中，應該綜合使用基本的自動化工具和人力。

在本文討論的案例中，要求對資源進行分類，不僅按照人力資源、自動化工具等進行分類，而且進行進一步細化，比如人力資源根據專業方向、領導才能、溝通能力等進行分類，提出一個簡單的分類和評估方法；對CMMI的資源和組概念擴充，不再局限於部門的概念，使之能夠容納各種全職和兼職人員，而且沒有規模和其中職位的限制。基於不同成熟度等級的項目或者組織，對不同KPA提出不同的建議工具，尤其是“小型軟體企業流程改善支援環境（SSE-PISE）”能夠對這些工具提供介面，促進自動化工具的使用效率。

5. 培訓剪裁

CMMI模型KPA的“執行能力”公用特性包含很多不同類型的培訓需求，包括管理和技術方面的。由於培訓是非常耗費資源和資金的事情，小型組織通常僱用已經被培訓或者具備相關知識的人才。CMMI的培訓程式KPA允許放棄培訓，但是大多數企業沒有認識到這個問題，仍舊堅持認為對所有員工進行培訓是必不可少的。必須對CMMI進行剪裁以澄清這種誤解。主要剪裁原則如下：

已經具備相應實踐經驗或者類似領域培訓曆史的員工可以免除培訓。

培訓可以當作以前培訓的擴充，並且可以合并相關活動的培訓。

可以擴充培訓實踐，消除不必要的內部培訓，接收來自於外部資源或者方法的培訓。

在我們討論的案例中，我們對相關培訓記錄和人力資源培訓技能和培訓曆史非常重視，並基於此來決定是否使用培訓免除機制。如果使用這種機制，必須保證有當事人的簽名。我們剪裁多個培訓實踐以合并或者擴充培訓需求。比如，同行評審領導者培訓可以與同行評審者培訓合并。有些高等級成熟度等級KPA的活動是低等級成熟度等級活動的擴充，因此支援高等級成熟度等級活動的培訓是支援低等級成熟度等級活動的培訓的擴充，比如整合化軟體管理KPA的專案管理培訓。

6. 剪裁無關實踐

CMMI是面向於大型軟體企業的，其中很多實踐是與小型企業不相關的，尤其很多過程實踐不適合於小型項目，小型項目實施這些過程實踐會花費比項目本身更多成本，並且由於部分項目的短時效性使得重新計劃或者調整活動變得沒有實際意義。

在組織流程焦點、組織流程定義、整合化軟體管理，以及定量過程管理等KPA中，很多過程實踐涉及到建立和維護項目已定義過程。但是在只有一個項目的組織中，項目過程和組織過程是完全相同的。如果組織的項目具備類似的特性（比如領域知識、規模和開發迴圈等），則所有小項目可能使用一個過程。並且這個過程是小型項目的組織標準流程。無論何種情況，那些剪裁組織標準軟體過程作為項目已定義過程，以及整合項目已定義過程的變更到組織標準流程的實踐都不適合。同時，對於那些開發時間很短的項目，則根本沒有時間來實施項目重新計劃、風險計劃，以及流程調適等活動，那麼這些實踐對於這種項目來說也是沒有用處的。

二. 總結

中國的軟體企業80%都是小型企業，人員規模在15人以下[10]，而CMMI是面向於大型軟體企業的流程改善模型，怎樣使得小型企業和項目能夠充分利用CMMI模型的流程改善優勢，並獲得相關CMMI認證呢？作者參與一個只有12名員工的小型企業軟體流程改善項目，本文正是基於該項目總結而得的。

本文首先從企業組織圖、軟體流程改善模型、小型組織面對的市場需求等三個方面剖析小型軟體企業的流程改善面臨與大型企業不同的需求。然後分析為什麼CMMI的有關內容不適合於小型企業和項目的實際情況，並概括介紹如何在文檔、管理、評審、資源和培訓等方面進行剪裁和改進，使之適合於小型企業和項目的實際情況。

參考http://www.uml.org.cn/cmm/200809023.asp