越來越多的軟體開發組織開始努力趕上CMM這趟馬車，但是其中大多數最後又還是從這架馬車上摔了下去。如果希望從你的軟體過程改進活動得到零回報，請遵守以下祕訣：
1. 花費大量的金錢和時間用於過程評估、諮詢服務和各種形形色色的CMM培訓班；
2. 按照諮詢顧問們開給你的軟體文件模板，制定一大堆你想得到想不到的過程規範，然後告訴程式設計師們必須一個不漏地馬上開始實施；
3. 接受你的高層領導的指示：“照著CMM說的去做！”；
4. 你辛辛苦苦的收集一大堆資料，而程式設計師們的工作方式依然照舊。

1  何謂過程改進
   過程改進的要義可以用一句話概括：對於效果良好的專案實踐要推廣應用，對於問題較多的專案實踐要變更調整。這就需要對於過去專案的成功之處和不足地方進行如實的內省和仔細的分析。過程改進最大的動機應該是通過改善軟體開發和管理的方式來打到企業的某個業務目標。CMM可以作為一個框架來引導你的過程改進活動，但是你的目標卻不是簡單的滿足這個模型的要求。

2  過程改進週期

   圖1說明了一個完整的SPI生命週期。首先，定義你期望達到的業務目標；然後，通過過程評估瞭解當前過程的問題，以及實施過程改進的可能結果。有了在評估中獲得的對本組織現狀的深入瞭解，以及業界的最佳實踐知識（CMM），你可以設定一個現實可達到的改進目標。下一步，選擇可以解決當前過程不足的合適的最佳實踐，可以是這些最佳實踐的一個很小的子集，來接近改進目標的最後實現。確定一到兩個專案作為新過程的試點，在取得成功後可以適當調整然後全面推廣。

   如果對新工作方式的實施作一定計劃，無疑能夠大大增加成功的可能性。最困難的部分就是實際開始實施一個行動計劃，如果這部分工作被忽略了，那麼一切努力都相當於白費。新的過程要發揮作用需要一些時間，你應該耐心觀察改進行動所針對的問題是否得到了解決或者症狀得到了緩解。用定量資料來表示過程改進帶來的好處，總是比主觀的認識要更有說服力。

   如果這一次改進活動成功了，那麼再繼續這個過程改進的迴圈，開始解決下一個最緊迫的需求。記住，過程改進沒有終點，而是一個不斷延續的旅程。

3  集中精力於那些讓你頭痛的部分

   人們日常工作方式中那些讓他們頭痛和感到麻煩的部分，是促使他們改變現狀最強的動機。我在這裡指的並不是外部的和假想的痛苦，而是有些時候我們在目前的工作方法裡所感覺體會到的實實在在的“痛苦”。許諾一個更美好的將來，可以是鼓勵人們作出變更的一個方法。但是，也許更有效的方式是指出他們現在正處於危險之中。
   評估可以幫助揭示那些讓你感到頭痛的部分真正原因所在，也可以揭示專案潛在的巨大風險。評估的形式可以不拘一格，既可以是一個簡單的“頭腦風暴”會議，所有的小組成員都參與討論究竟什麼阻礙了生產率和質量提高；也可以是一個半正式的邀請外部的諮詢顧問參與的評價；還可以是一個嚴格的參照CMM標準的正式評審。當然，正式的評審需要一定資金投入，但是可以參照一個業界統一的標準對企業當前實際作出徹底的全面評價。
   根據我的經驗，過程評估很少揭示出特別出人意料的問題。很多開發團隊可能已經意識到了他們的問題所在，外部的諮詢公司所作出的評估只是使這個問題得到正式的確認。因為，作為外部的第三方，可以置身事外於這個組織的遺留問題、人際糾紛和許多“特殊人物”。評估讓你直面那些尷尬的問題情勢，而絕對不應該是提供一個對過往問題進行刻意挑剔或者歸罪某人的講壇。
   執行評估的另一層作用，就是顯示管理層對於過程改進的一種決心和承諾。切記要按照評估所發現的問題和提出的建議進行改進，否則不但對於企業投入評估的金錢和精力是一種損失，而且也在團隊成員們的心中失去了信任。這些在評估中花費心血的人們，會認為管理層對於變革實際上並沒有嚴肅對待。

   評估經常是確認了一大堆的改進機會，而你不可能一口全部吃下。“聚焦”就是過程改進中要注意的關鍵之處，因為，設計一個更好的過程並且將其變為團隊工作方式的一部分，所花費的時間往往超過你的設想。我曾經遇到一個20人的開發團隊，他們雄心勃勃，企圖同時在七個領域實施改進活動，雖然精神可嘉，但是收效甚微。

   過程改進的目標，應該用所期望的業務成效的術語來敘述。舉個例子，目標不應該寫成“制定軟體構建版本遞增規程”，而應該寫成“減少從開發階段傳遞到系統測試階段的不正確的構建版本”。SPI的活動其自身並不是目的，而是達到某個目標的方式手段。專案經理應該清楚明白的說明，如果改進活動成功，那麼期望開發團隊成員的行為方式會有怎樣的改變。
   從優先順序比較高的那些目標中，一開始僅僅選擇兩到三個實施改進。如果你很快的完成了這幾個目標，很好；再從評估報告中選取下兩個目標繼續改進。每次步子不要邁得太大，不要在剛剛起步時嘗試太多事情。大型開發組織可以一次在多個專案中同時進行若干領域的改進，但是，對於每個單獨的專案仍然應該一次集中精力做好一件事。

4  溝通極端重要
   當要求人們變更他們熟悉的工作方式，他們通常感到不情願，因為對於熟悉的方式（哪怕效率不高），人們總是能感覺到某種舒適，而對於未知總是感到不安。同時，對於過程改進可能帶來的一些額外的程式化的工作量，人們也普遍擔心這會影響到創造性的發揮和軟體的按時釋出。但是，這種擔心經常是不現實的。團隊成員也許會有一種挫折感，因為哪怕他們已經盡了最大努力，評估結果仍然表明過程有不足之處。客戶會認為過程改進活動給他們平添了不少障礙，使他們的需求不容易達到程式設計師。
   要解決上述問題，溝通應該貫穿於過程改進的全過程。應該明確的說明當前過程的不足之處所造成的代價：包括不斷推遲的進度表、功能的缺失、經常性的超時工作，超額的產品支援費用、客戶的不滿意、和士氣的低下等；應該給那些懷疑論者們細緻的解釋過程改進對於個人、團隊、公司和客戶的好處；有人可能會擔心變更接踵而至、疲於應付，應該強調新的過程是經過深思熟慮選擇的，是團隊成員共同建立的，也是循序漸進、逐步推廣應用的；應該積極尋找那些願意嘗試新的過程和新的文件模板的支持者，提供反饋，為成功的變革奠定基礎；應該公開的表揚對於每個成功的過程變更作出貢獻的人員，來傳達一個資訊：建設性的參與過程改進活動是企業所期許的；應該仔細分析不成功的過程變更，查明為什麼無法堅持定義的過程，最後不得不改變目標。
   過程改進的一個關鍵的運作原則是，“平緩而持續的施加壓力，盡一切努力來應用”。應該保持過程改進的目標和狀態始終清晰，強調改進目標與企業的業務目標是如何統一的。應該在小組會議上留出時間來檢查改進活動的進展，階段性的向管理層報告改進工作取得的成功以獲得他們的支援。

   我們經常看到，有的開發團隊在年初對過程改進工作滿腔激情，而在整個一年中卻不再提及，直到年底開始檢查是否達到當時定下的目標，結果當然是失敗。對大多數團隊成員而言，具體的開發工作總是比投入過程改進更加重要。專案經理應該經常提醒和強調，過程改進工作是重要的和有價值的。

5  要有和過程改進相應的組織機構設定

   認真對待過程改進的企業，通常設定一個三層的組織架構來確保過程改進工作的成功。不同的企業可能要根據實際情況作出調整，總的原則是不必過於複雜，夠用就行。”夠用“的標準是，有形的改進活動可以被有效的識別、啟動和實施。管理層決策委員會（MSC），設定過程改進的方向，優先順序和保證改進活動所需資源。它某些時候會為每個改進領域制定一個”過程負責人“，保證改進目標的達到和團隊的穩定性。一般來說，管理層決策委員會的成員包括企業的高階經理（執行長或技術總監），過程改進經理，各改進領域的過程負責人，部分慎重選擇的專案經理和部門經理。管理層的各個級別積極參與到MSC中，表明組織對於改進工作的重視態度。
   MSC的職責包括：
   （1）設定過程改進領域的優先順序；
   （2）為特定改進領域的工作組建立章程；
   （3）監控改進活動與狀態；
   （4）及時評估以完成的改進活動的影響；
   （5）管理過程改進風險和消除障礙。
   軟體工程過程小組（SEPG，發音為"S-E-P—G”，或者“sep-gee”，或者“see-peg”），協調各種過程改進活動。SEPG相當於管理層的代表，負責過程改進活動的實施。一個大型組織的SEPG應該有一個全職經理，一些過程改進專職人員，一些每年輪換的兼職參與人員。過程改進專職人員經常來自測試和質保人員，但是至少應有部分過程改進專職人員有豐富的開發經驗，專案管理經驗也同樣重要。這些資格保證了SEPG成員比單純的缺乏開發實踐經驗的理論專家更具可信度。SEPG成員應該掌握大量的關於過程評估、過程改進框架、過程和規範文件的書寫、如何影響變更的知識。人員和組織因素方面的變更管理至少和過程改進的技術特徵同等重要。工作富有成效的SEPG成員應該是有組織性、有耐心、適應能力強的有效溝通者。他們可以根據溝通物件的不同個性來調整溝通方式，他們是富於技巧的促進者，能夠在敏感問題上引導不同的參與者通過討論得到預期結果，而這些參與者可能最初反對過程改進或者不要參與過程改進活動。SEPG對於過程改進活動的所有相關人員而言，都是一個巨大的資源。他們的專業技能，人際關係都能夠促進變更的發生，因為過程改進活動的參與者知道在遇到問題時應該到何處尋求幫助。
   SEPG小組的職責通常包括：
   （1）制定過程改進的戰略計劃和戰術計劃；
   （2）領導或參與過程評估；
   （3）協調促進各工作組；
   （4）收集業界最佳實踐的資料和著作；
   （5）積累組織的過程財富，如規程、模板、檢查清單、工作樣品，並在組織範圍內共享；
   （6）評審工作組建立的新過程、規程和模板；
   （7）領導組織範圍內的過程改進活動，如度量和培訓。
   並不推薦SEPG小組定義所有的新規程，然後強加給專案組執行。這樣一種典型的“隔牆扔物，砸中行人”的方式，總是不可避免的最後要失敗。推薦的方式是，由與規程定義相關人員組成工作組（“過程行動小組”或者“過程改進小組”）來制定規程。一個工作組由一群專案組代表臨時組成，通常是3－6人，負責一個特定的改進領域。他們工作的可交付成果一般包括該領域當前過程的描述，新過程的定義以及其他的過程財富。工作組的努力也許僅僅包括對一個專案實施新過程，也許是為整個組織定義新的過程。
   工作組的工作範圍應該限制在三個月可以完成的工作量以內。如果延續時間太長，那麼工作成員們會逐漸失去熱情，有可能出現反覆。在每一輪新的改進活動中，工作組可以重新組建或者再度召集原班人馬。儘量讓所有的專案成員和專案經理都有機會在某個時候參與到工作組來，當然不必在一次完成，這樣讓他們對於新過程有一種擁有感。SEPG小組成員可以建立工作組並負責工作組的第一次會議，但是，專案開發小組應該在SEPG小組的培訓階段結束後，自主管理過程改進活動並保證工作組的持續性。

6  計劃過程改進的行動

   一切工作皆專案，軟體過程改進活動也應該按照專案的方式來運作，應該與任何開發專案一視同仁，提供同樣的資源和結構。一個整體的過程改進戰略計劃，和每個工作組的過程改進戰術計劃，都是十分必要的。有些人不樂意作計劃，將這看成浪費時間的文牘主義和額外的負擔。然而，寫計劃本身並不困難，困難的是制定計劃中的思考、詢問、聆聽、理解和協調等等步驟。實際上，寫計劃只是抄寫而已。即使是對於最簡單的專案，計劃也能夠保持專案按預期路線執行，並且提供了可以用以跟蹤進度的參照。
   過程改進戰略計劃對組織的長期過程改進活動給出了指導，組織的過程改進經理通常是戰略計劃的主要作者，而SEPG成員和其他高層經理評審並且批准戰略計劃。
   每個工作組應該按照標準的模板來編制行動計劃，描述工作組的待實現目標以及如何實現的思路。行動計劃應該確認：
   （1）驗證過程變更是否達到預期目的的度量標準；
   （2）過程變更在組織內的應用範圍；
   （3）參與者的角色和他們承諾投入的時間；
   （4）工作組何時向何人報告；
   （5）外部依賴或者風險；
   （6）所有活動結束的目標日期；
   （7）行動條目的列表，對每項行動條目指明負責人、截止日期、目的、資源和交付成果等。
   每個過程改進戰術計劃的行動條目限制在9條以內，並且每條都應該是特定的、小規模的。這樣，可以幫助控制工作組的工作量在3個月內，而不是對於參與者來說是遙遙無期。
   過程改進戰略計劃模板：
1. 目的
1.1. 首字母縮寫詞
1.2. 參考文件
2. 概述
3. 執行概要
4. SPI啟動的業務事項
4.1. 商業基本原理
4.2. 指導原則
5. 過程改進目標
5.1. 短期目標
5.2. 長期目標
6. 假定、風險與障礙
7. 過程改進相關的組織機構
7.1. 組織範圍
7.2. 管理層決策委員會
7.3. 軟體過程改進經理
7.4. 軟體工程過程小組
7.5. 工作組
7.6. 過程經理
7.7. SPI顧問
8. 成功準則
9. 改進議程
9.1. SPI活動選擇
9.2. 當前SPI活動
9.3. 過程改進路線

7   運籌帷幄，決勝千里

過程改進的領導者應該擔負決策的功能，引導著組織首先承認需要更好的實踐方式，然後成功的實施新實踐。這種決策要求對於目標堅定不移，清楚知道自己的目的所在。不斷改變的目標會使參與者們感到困惑，他們會最後拒絕行動：“等你拿定主意後，我們再幹吧。”避免被CMM更高級別的目標所吸引分心，而集中精力於如何提升業務成效，集中精力於有選擇的創造性的應用當前CMM級別所提供的指導。認真的對待過程改進活動，並且保證所需的資源提供。一個組織，如果在軟體過程改進上投入的資金只佔總預算的3％－4％（包括培訓、評估、諮詢、SEPG人員支出、工作組經費等），那麼它的所謂SPI只不過是隨便試試、淺嘗輒止。如果資金投入比例達到7％－8％，那麼該企業對於SPI就是嚴肅對待的；而10％的比例就意味著企業對於SPI“只許成功，不許失敗”的一種承諾。跟蹤實際花費的時間，確定計劃的工作是否如期完成，現有的資源是否能夠滿足改進活動目標的需求。承認學習曲線存在的現實，短期內工作績效有可能下降，因為你需要學習新的方法，並且將新方法和個人的工作過程結合起來。對於個人而言，要把新的更好的工作方式真正吸收掌握需要時間；同樣，對於組織而言，要把新的實踐制度化並且成為企業的例行工作也需要時間。你在SPI上花費的時間和金錢都是一種長期的為組織成功的戰略投資，那些被佔用的資源也不能在當前的專案中使用。對於每個小的進步都應該感到高興，並且應該保持下去，讓明天的工作始終比今天做的更好。這就是過程改進的全部。