越來越多的軟件開發組織開始努力趕上CMM這趟馬車，但是其中大多數最后又還是從這架馬車上摔了下去。如果希望從你的軟件過程改進活動得到零回報，請遵守以下秘訣：
1. 花費大量的金錢和時間用于過程評估、咨詢服務和各種形形色色的CMM培訓班；
2. 按照咨詢顧問們開給你的軟件文檔模板，制定一大堆你想得到想不到的過程規范，然后告訴程序員們必須一個不漏地馬上開始實施；
3. 接受你的高層領導的指示：“照著CMM說的去做！”；
4. 你辛辛苦苦的收集一大堆數據，而程序員們的工作方式依然照舊。
1 何謂過程改進
過程改進的要義可以用一句話概括：對于效果良好的項目實踐要推廣應用，對于問題較多的項目實踐要變更調整。這就需要對于過去項目的成功之處和不足地方進行如實的內省和仔細的分析。過程改進最大的動機應該是通過改善軟件開發和管理的方式來打到企業的某個業務目標。CMM可以作為一個框架來引導你的過程改進活動，但是你的目標卻不是簡單的滿足這個模型的要求。
2 過程改進周期
圖1說明了一個完整的SPI生命周期。首先，定義你期望達到的業務目標；然后，通過過程評估了解當前過程的問題，以及實施過程改進的可能結果。有了在評估中獲得的對本組織現狀的深入了解，以及業界的最佳實踐知識（CMM），你可以設定一個現實可達到的改進目標。下一步，選擇可以解決當前過程不足的合適的最佳實踐，可以是這些最佳實踐的一個很小的子集，來接近改進目標的最后實現。確定一到兩個項目作為新過程的試點，在取得成功后可以適當調整然后全面推廣。
如果對新工作方式的實施作一定計劃，無疑能夠大大增加成功的可能性。最困難的部分就是實際開始實施一個行動計劃，如果這部分工作被忽略了，那么一切努力都相當于白費。新的過程要發揮作用需要一些時間，你應該耐心觀察改進行動所針對的問題是否得到了解決或者癥狀得到了緩解。用定量數據來表示過程改進帶來的好處，總是比主觀的認識要更有說服力。
如果這一次改進活動成功了，那么再繼續這個過程改進的循環，開始解決下一個最緊迫的需求。記住，過程改進沒有終點，而是一個不斷延續的旅程。
3 集中精力于那些讓你頭痛的部分
人們日常工作方式中那些讓他們頭痛和感到麻煩的部分，是促使他們改變現狀最強的動機。我在這里指的并不是外部的和假想的痛苦，而是有些時候我們在目前的工作方法里所感覺體會到的實實在在的“痛苦”。許諾一個更美好的將來，可以是鼓勵人們作出變更的一個方法。但是，也許更有效的方式是指出他們現在正處于危險之中。
評估可以幫助揭示那些讓你感到頭痛的部分真正原因所在，也可以揭示項目潛在的巨大風險。評估的形式可以不拘一格，既可以是一個簡單的“頭腦風暴”會議，所有的小組成員都參與討論究竟什么阻礙了生產率和質量提高；也可以是一個半正式的邀請外部的咨詢顧問參與的評價；還可以是一個嚴格的參照CMM標準的正式評審。當然，正式的評審需要一定資金投入，但是可以參照一個業界統一的標準對企業當前實際作出徹底的全面評價。
根據我的經驗，過程評估很少揭示出特別出人意料的問題。很多開發團隊可能已經意識到了他們的問題所在，外部的咨詢公司所作出的評估只是使這個問題得到正式的確認。因為，作為外部的第三方，可以置身事外于這個組織的遺留問題、人際糾紛和許多“特殊人物”。評估讓你直面那些尷尬的問題情勢，而絕對不應該是提供一個對過往問題進行刻意挑剔或者歸罪某人的講壇。
執行評估的另一層作用，就是顯示管理層對于過程改進的一種決心和承諾。切記要按照評估所發現的問題和提出的建議進行改進，否則不但對于企業投入評估的金錢和精力是一種損失，而且也在團隊成員們的心中失去了信任。這些在評估中花費心血的人們，會認為管理層對于變革實際上并沒有嚴肅對待。
評估經常是確認了一大堆的改進機會，而你不可能一口全部吃下�！熬劢埂本褪沁^程改進中要注意的關鍵之處，因為，設計一個更好的過程并且將其變為團隊工作方式的一部分，所花費的時間往往超過你的設想。我曾經遇到一個20人的開發團隊，他們雄心勃勃，企圖同時在七個領域實施改進活動，雖然精神可嘉，但是收效甚微。
過程改進的目標，應該用所期望的業務成效的術語來敘述。舉個例子，目標不應該寫成“制定軟件構建版本遞增規程”，而應該寫成“減少從開發階段傳遞到系統測試階段的不正確的構建版本”。SPI的活動其自身并不是目的，而是達到某個目標的方式手段。項目經理應該清楚明白的說明，如果改進活動成功，那么期望開發團隊成員的行為方式會有怎樣的改變。
從優先級比較高的那些目標中，一開始僅僅選擇兩到三個實施改進。如果你很快的完成了這幾個目標，很好；再從評估報告中選取下兩個目標繼續改進。每次步子不要邁得太大，不要在剛剛起步時嘗試太多事情。大型開發組織可以一次在多個項目中同時進行若干領域的改進，但是，對于每個單獨的項目仍然應該一次集中精力做好一件事。
4 溝通極端重要
當要求人們變更他們熟悉的工作方式，他們通常感到不情愿，因為對于熟悉的方式（哪怕效率不高），人們總是能感覺到某種舒適，而對于未知總是感到不安。同時，對于過程改進可能帶來的一些額外的程序化的工作量，人們也普遍擔心這會影響到創造性的發揮和軟件的按時發布。但是，這種擔心經常是不現實的。團隊成員也許會有一種挫折感，因為哪怕他們已經盡了最大努力，評估結果仍然表明過程有不足之處�？蛻魰J為過程改進活動給他們平添了不少障礙，使他們的需求不容易達到程序員。
要解決上述問題，溝通應該貫穿于過程改進的全過程。應該明確的說明當前過程的不足之處所造成的代價：包括不斷推遲的進度表、功能的缺失、經常性的超時工作，超額的產品支持費用、客戶的不滿意、和士氣的低下等；應該給那些懷疑論者們細致的解釋過程改進對于個人、團隊、公司和客戶的好處；有人可能會擔心變更接踵而至、疲于應付，應該強調新的過程是經過深思熟慮選擇的，是團隊成員共同創建的，也是循序漸進、逐步推廣應用的；應該積極尋找那些愿意嘗試新的過程和新的文檔模板的支持者，提供反饋，為成功的變革奠定基礎；應該公開的表揚對于每個成功的過程變更作出貢獻的人員，來傳達一個信息：建設性的參與過程改進活動是企業所期許的；應該仔細分析不成功的過程變更，查明為什么無法堅持定義的過程，最后不得不改變目標。
過程改進的一個關鍵的運作原則是，“平緩而持續的施加壓力，盡一切努力來應用”。應該保持過程改進的目標和狀態始終清晰，強調改進目標與企業的業務目標是如何統一的。應該在小組會議上留出時間來檢查改進活動的進展，階段性的向管理層報告改進工作取得的成功以獲得他們的支持。
我們經�？吹�，有的開發團隊在年初對過程改進工作滿腔激情，而在整個一年中卻不再提及，直到年底開始檢查是否達到當時定下的目標，結果當然是失敗。對大多數團隊成員而言，具體的開發工作總是比投入過程改進更加重要。項目經理應該經常提醒和強調，過程改進工作是重要的和有價值的。
5 要有和過程改進相應的組織機構設置
認真對待過程改進的企業，通常設置一個三層的組織架構來確保過程改進工作的成功。不同的企業可能要根據實際情況作出調整，總的原則是不必過于復雜，夠用就行�！眽蛴谩暗臉藴适�，有形的改進活動可以被有效的識別、啟動和實施。管理層決策委員會（MSC），設定過程改進的方向，優先級和保證改進活動所需資源。它某些時候會為每個改進領域制定一個”過程負責人“，保證改進目標的達到和團隊的穩定性。一般來說，管理層決策委員會的成員包括企業的高級經理（首席執行官或技術總監），過程改進經理，各改進領域的過程負責人，部分慎重選擇的項目經理和部門經理。管理層的各個級別積極參與到MSC中，表明組織對于改進工作的重視態度。
MSC的職責包括：
（1）設定過程改進領域的優先級；
（2）為特定改進領域的工作組建立章程；
（3）監控改進活動與狀態；
（4）及時評估以完成的改進活動的影響；
文章來源于領測軟件測試網 http://www.kjueaiud.com/