發揮作用的過程改進(Process Improvement that Works）
Karl E. Wiegers
許多軟體開發組織正在趕上CMM軟體過程改進的遊行彩車， 但是太多的組織又掉了下來。如果你希望從你的軟體過程改進投入中得到零回報，請遵循以下程式：
1. 在過程評估、咨詢服務和教育訓練研究班上花費大量的金錢和時間。
2. 建立一個包含各種規程大夾子，然後告訴團隊成員他們必須馬上開始遵守所有的規程；
3. 接受高層上司的訓示：“照着去做！”；
4. 看着規程檔案的大夾子落滿了塵土，而團隊成員根本沒有改變他們工作的方式。
本文介紹從過程改進工作中的吸取的教訓，以避免無用的工作，提供關于如何進行軟體過程改進的實用技巧，以及基本過程改進的步驟描述。補充資料列出了一些資源和參考。
什麼是過程改進
從本質來講，過程改進很簡單：始終如一地應用那些帶來好效果的實踐， 改變那些導緻問題産生的實踐。這就需要坦率的内省和仔細的分析以前項目成功的地方和不足的地方背後的原因。你主要的動機應該是通過尋找的更好的軟體開發方法和管理方法以達到特定的經營成果。你可以使用已制定的軟體過程架構，如SEI的軟體過程成熟度模型（CMM），來指導軟體改進工作。但是需要記住的是你的目标決不是簡單地的滿足模型的要求。
過程改進周期
圖1說明了一個總體的SPI周期。定義你期望達到的商業目标後，通過過程評估來評價目前的過程，問題，以及項目成果。具備了評估的見識以及關于軟體産業最佳實踐的知識，你可以設定一個現實的改進目标。選擇能夠解決目前過程缺點并向目标前進的實踐的一小部分。确定一到兩個項目作為新的過程的試點并在正式推出之前進行調整。
圖 1 軟體過程改進生命周期
為實施新的工作方法進行策劃，将大大增加你成功的可能性。最艱苦的部分就是實際上實施一個行動計劃； 如果你不做這部分工作，什麼都不會真正改變。給新的過程一些時間，然後觀察行動計劃所緻力于解決的問題是否有所減輕。關于過程好處的硬資料比主觀感覺更有說服力。然後繼續過程改進生命周期來解決下一個最緊迫的需要。過程改進是一個旅程，而不是終點。
關注于痛苦
痛苦是改變人們工作方法的最好的動機。我說的并不是外部的和人為引發的痛苦， 而是在我們現在的工作方法中遭遇的非常真切的痛苦。告訴人們變革會帶來一個美好的未來，是鼓勵人們變革的一個方法。更有說服力的方法是告訴人們，如果不變革，馬上就要處于危險之中。
評估可以幫助揭示痛苦的地方和項目面臨的主要風險。評估可以采用一個簡單的頭腦風暴會議，你的團隊成員可以找出影響提高生産率和品質的障礙。或者呢，可以花錢請外部的咨詢顧問來進行半正式的評估， 還可以按照已有的過程模型（如CMM），進行嚴格的正式過程評估。當然，正式的評審需要花錢而且耗費時間，但是他們可以對比者過程标準來徹底地目前的過程實踐。
根據我的經驗，過程評估很少揭示出特别出乎意料的問題。很多開發組可能已經覺察到了他們的問題和習性，由外部人員進行評估隻不過正式的揭示這個問題。因為外部人員遠離開發組織的辦公室政治， 曆史上的沖突和特别人物。評估會讓你直接面對不安的問題情形。 評估絕對不應成為尋找過去問題的過錯和責備個人的論壇。
進行評估可以表明管理層對于過程改進的一種決心和承諾。切記，要對評估所發現的問題和建議進行到底，否則，你就在浪費評估上投入的金錢和時間，并失去挫敗的團隊成員們的信任，他們會得出結論管理層對進行變革根本不認真。
評估通常識别了一大堆的改進機會，比你能夠着手解決的要多的多。“焦點”就是過程改進中最關鍵的詞彙。設計一個更好的過程并且将其變為團隊日常工作方式的一部分所花費的時間比你想象的時間要長的多。我曾經遇到一個鬥志昂揚的由20人組成的項目團隊，在七個改進領域裡同時推進改進。資源平均地配置設定在七個領域中，沒有清晰的優先級，盡管很狂熱， 但幾乎沒有成效。
按照你期望的經營成果來陳述過程改進的目标， 比如說，目标可能是“消除從開發階段傳遞到系統測試階段的不正确的構造版本”，而不是寫成“軟體構造版本遞增規程”。SPI活動
而是達到某個目标的手段， 而不是以SPI本身為目的。你的經理應該能夠清楚的表達，希望從SPI計劃的成功中，看到小組成員的行為和結果發生什麼樣的改變。
對于那些最高優先級的目标，開始先選擇兩到三個目标進行改進。如果你很快地完成了這幾個目标，很好，在從評估報告中選取下一步改進的領域。一次步子不要邁得太大，不要在剛剛起步時嘗試太多事情。大的開發組織可以在多個項目中同時進行若幹領域的改進，但是每個項目一次僅關注于很少的領域。
溝通，溝通，溝通
當要求人們變更他們熟悉的工作方式，他們通常感到不情願，因為對于熟悉的方式（即使效率不高）感覺到舒适，而對于未知感到擔心。考慮到繁重的過程負擔會影響到創造性和和軟體的按時釋出也是普遍的，但是，這種擔心常常超過了現實所帶來的。你的團隊成員也許會有一種挫折感，即使他們已經盡了最大努力，評估結果還是找出了過程的不足之處。客戶和其他外部組也會認為SPI計劃給他們從程式員那裡擷取所需要的東西增添了障礙。
要解決上述問題，溝通應該貫穿于過程改進活動。應該清楚有力地說明目前過程的不足所付出的代價。 代價可能包括：包括膨脹的進度表、功能的遺失、大量的加班，高的産品支援成本、不高興的客戶、和士氣低下等；向懷疑論者們解釋過程改進活動對于個人、項目團隊、公司和客戶有什麼好處。為了減輕對勢不可擋的變革的擔心, 強調新的過程将被深思熟慮地挑選，是由團隊成員自己建立的，并将循序漸進地推行的，尋找那些願意嘗試新的規程和檔案模闆并提供資訊回報的“同盟軍”，幫助為成功變革作基礎工作。
向團隊成員和相關人員宣揚取得的成就。公開的承認對每一個成功變革做出貢獻的人，表明建設性的參與SPI計劃是一個期望的行為。分析不成功的變革嘗試來了解為什麼很艱難并調整你的做法。
一個關鍵SPI操作原則是，“溫和而持續不懈的壓力”。保持過程改進的目标和狀态對整個團隊可見。強調改進目标如何與企業的業務目标統一的。在小組會議上留出時間來評審改進活動的進展，階段性地向管理層報告改進工作取得的成功以獲得他們的對工作的支援。
災難的事情是，在年初虛張聲勢地啟動過程改進計劃，卻再也不提起，直到年底時檢查是否達到了目标。當然沒有達到目标。對于大多數項目成員來說，在項目活動中工作總是比為過程改進作貢獻更加重要。經理應當不斷向團隊強調過程改進工作是重要的和有價值的。
為過程改進建立組織保證
認真對待過程改進的組織，通常設定一個三層的組織架構來確定過程改進工作的成功（圖2）。但是你應當根據你的組織的情況調整這個思想，組織結構不應過于複雜。隻要能夠保證知道的改進行動被識别、啟動、實施和取得效果。管理指導委員會（MSC）提供資源并且設定方向和優先級。它也可能為每一個過程改進領域識别出一個“過程的所有者”， 一個負責達成過程改進并在工作組更疊時提供連貫性。
通常管理指導委員會的成員包括組織的進階經理，過程改進經理，上司SPI工作的個人，挑選的的項目經理和部門經理。管理層的不同級别積極參與到MSC中，表明組織對于改進工作的非常認真。MSC的職責包括：
l 設定改進領域的優先級；
l 特許設立工作組從事與特定改進領域；
l 監控改進活動與狀态；
l 評估已完成的改進活動的影響；
l 管理過程改進風險和消除障礙。
圖 2 典型的軟體改進組織結構
軟體工程過程小組或SEPG（發音為“S-E-P-G”，“sep-gee”或“see-peg”），協調各種過程改進活動。SEPG擔當管理層的代理來實施過程改計劃。一個大型組織的SEPG應當有一個全職經理，一些專職的軟體過程專家，一些輪換地參加的兼職人員。
過程專家經常來自測試和品質保證人員，但是至少有幾個SEPG成員應當具備堅實的開發經驗。項目管理經驗也是需要。相對于一幫不知道真正的軟體是怎麼開發的理論家，這些資格提供SEPG更多的可信度給開發人員和管理人員。
SEPG學會了大量關于評估，過程改進架構，如何編寫好的過程和規程檔案，如何影響變革的知識。變更管理的人性群組織方面至少和過程改進的技術方面一樣重要。有效的SEPG成員應是有條理的, 耐心的, 靈活和有效的溝通者， 他們可以根據個人情況改變他們的方法。他們是娴熟的促成者，能夠和不同的參與者，一些參與者可能根本不信SPI和不願參與，在敏感話題上引導有成效的讨論，。
對于所有過程改進計劃有關的人員來說，SEPG是一個資源。他們的專長，資源和外部關系加速變革活動，因為參加過程改進的人知道有一個可以尋求幫助的地方。SEPG成員通常履行以下職能：
l 開發戰略的和戰術的過程改進的計劃；
l 上司或參與過程評估；
l 協調和促進各個過程改進工作組；
l 收集業界最佳實踐的資訊和文獻；
l 積累組織的過程财富，如規程、模闆、檢查清單、工作産品範例，并在組織範圍内共享；
l 評審工作組制定的新的過程、規程和模闆；
l 上司整個組織範圍内的過程改進活動，如度量和教育訓練計劃。
SEPG小組編寫所有的新規程，然後強加給項目組的做法不是一個好主意。這樣一種典型的“隔牆扔物，殃及他人”的方式，總是要失敗。通過專業人員參加工作組（過程改進工作組或過程行動團隊）的方法參與到現實可行的新的規程中。推薦的方式是，由與規程定義相關人員組成過程改進工作組（也稱為“過程行動團隊”或者“過程改進團隊”）來制定規程。
一個工作組由3到6名項目代表組成的特别小組，負責一個特定的改進領域。他們的可傳遞成果一般包括該領域目前過程的描述，新制定的過程以及過程财富。工作組的工作也許僅僅包括為一個項目實施新的過程，也許是為整個組織定義新的過程。
認真細緻的研究工作組目标的範圍，以便三個月内可以完成。如果延續時間太長，那麼工作成員們會失去熱情，人員也會有更疊。你可以重新授權給工作組，也可以召集一個新的小組進行下一輪的改進活動。盡量讓所有的項目成員和項目經理都在某個時候參與到一個工作組來（當然不必在一次完成），這将有助于給所有的團隊成員對新的過程的擁有感。SEPG成員可以發起每一個并促進工作組的首次會議。 然而, 成為過程改進計劃的主人并在SEPG撤走教育訓練動力後維持工作組成就，對于軟體開發組織來說是非常重要的。
策劃行動
把你的SPI計劃看作一個項目， 提供組織結構，資源，和其他開發項目一樣的需求。兩個有用的策劃成分，總體的戰略軟體過程改進計劃和每個工作組的戰術上的行動計劃。有些人不樂意作計劃，把制定計劃看作無用的繁文缛節和負擔。然而，制定計劃本身并不困難，困難的是思考、提問、聆聽、了解和磋商等工作。實際上，制定計劃隻是不過是把你思考的内容抄寫下來。即使簡單項目，計劃也能夠幫助項目按照規定的過程執行，并且提供了可以用以跟蹤進度的參照。
圖3提供了戰略SPI計劃的模闆，戰略SPI計劃指導組織的長期過程改進。組織的過程改進經理通常是戰略SPI計劃的主要作者，而SEPG成員和關鍵經理應當評審并準許戰略SPI計劃。使用這個模闆為你的SPI策劃所用。
每個工作組應該使用标準的模闆來編制行動計劃，描述工作組的要實作目标以及如何實作這些目标。行動計劃應該識别：
l 需要完成的商業和技術目标， 這些目标将與寫在戰略SPI計劃中的整體目标進行對比跟蹤
l 對過程變更是否達到預期效果的測量項
l 過程變更的組織範圍
l 參與者，他們的角色和承諾投入的時間
l 工作組報告狀态，結果和問題的報告機制
l 外部依賴或風險
l 所有活動完成的日期目标
l 行動條目的清單，對每項行動條目指明負責人、截止日期、目的、活動、傳遞成果和所需的資源等。
把每一個過程改進戰術計劃的行動條目限制在9條具體的、相當小的行動。這将幫助控制工作組的工作量在幾個月内，而不是對于參與者來說遙遙無期。
圖 3戰略性過程改進計劃模闆
向成功前進
過程改進的上司者是領路人，引導着組織首先認可需要更好的實踐，然後成功地實施新的實踐。這種指引要求穩定的目标和堅定不移的決心，不斷改變的目标會使得參與者感到困惑和沮喪，他們會撒手不幹，說“等你想清楚你真正想要什麼，再告訴我”。避免被追求更高的CMM級别而分心，而是專注于提升經營成果，通過選擇性和創造性地應用現有架構（如CMM）所提供的指導。
決定你對SPI的熱衷的程度并按此配置設定資源。一個組織，如果在軟體過程改進上投入的資金隻占總預算的3%－4%（包括教育訓練、評估、咨詢、SEPG人員支出、工作組人員等），那麼它的所謂SPI隻不過是随便試一試。如果資金投入比例達到7%－8%，那麼該企業對于SPI就是相當認真的；而10%的比例就意味着企業對于SPI巨大的投入。通過跟蹤花費在SPI活動上的時間，确定計劃的工作是否完成以及你目前的資源投入是否與你的目标相一緻。
| 生産率 |
| 初始狀态 |
| 過程改進開始 |
| 改進的未來狀态 |
| 不要在這裡退出 |
| 學習曲線 |
| 時間 |
圖 4 過程改進的學習曲線
認識到學習曲線存在的現實，短期的績效下降是因為你學習新的工作方法，并且和每人的個人過程結合起來。對于個人而言，吸收新的更好的工作方式會花費時間；對于組織而言，作為一個整體來，使好的工作方法制度化為操作規程也需要花費時間。你花在SPI上的時間和金錢都是在組織長期成功方面的戰略投資，那些資源也不能在目前的項目中所用。在小的勝利上感覺高興，并慶祝你的成功。不斷嘗試讓你明天的項目工作做的比昨天做的更好，
對于每個小的進步都應該感到高興，并且應該保持下去，讓明天的工作始終比今天做的更好，最終你将在競争中領先。這就是過程改進的真正所在。