[轉貼]：軟體過程改進：經驗和教訓

2001我開始慢慢關注起軟體工程和CMM，也對CMM進行了學習。並且對其中的一些KPA在自己單位中進行了試驗。可是一開始這些試驗的結果並不令人愉 快，甚至遭到了抵制和反對。開發和測試人員認為降低了開發速度和靈活性，加大了工作量，工作流程太煩瑣。而質量的提高也不是一時可以反映出來的。於是在進 行了2個小專案的試驗後，我被迫停止了CMM在公司的實施。
軟體過程改進：經驗和教訓

前言：
因為公司並不從事外包服務，所以CMM對其沒有生存的壓力。高層也只是想通過一個可行的過程管理，一個提高軟體質量，保證專案進度，有效控制專案成本。所以公司並不是要去過CMM等級，而是要一個有效的過程管理。

所以我此後開始以‘有效、簡易、可行、低成本’為標準探索起適合起我們公司的過程改進的最佳實際。現在，我很高興可以在文中和大家探討我公司在過程改進過程中的一些經驗和教訓，也許你會從中得到一些啟發，開發出適合你自己的最佳實際。

經驗和教訓：

在中小型的軟體企業當中，軟體過程的改進更容易半途而廢

中小企業，特別是開發人員小於40個人的企業。一般不會有專門的人員可以組建‘軟體過程組’，也很少會有專職的質量工程師和配置工程師。在進行過程改進 中，對於這些職位基本上都是由原來的人員兼職完成。這無形中增加了人員的工作量。一旦過程定義的不是太完善，或是在試點中不是太成功。很容易讓人去懷疑過 程改進本身的可行性。同時中小企業接到的專案也比較小，成本壓力是比較大的，而提高質量是必須以犧牲成本為代價的。所以有時從成本的角度出發，可能在高層 管理人員的心目中，對於過程改進也是有成本的顧慮的，一方面希望，可以通過過程改進提供質量，併為企業的發展提供基礎，另一方面，也面臨成本壓力，若過程 是改進了，可是成本也大幅度提高了，則本事企業的生存就成問題了。

而在大的軟體企業，一般可以有專職的人員進行質量保證和過程改進。同時由於大企業拿到的專案一般也比較大，專案組就比較大，客戶要求也高。這也為過程改進增加了必要性。

持續的改進很重要，但頻繁的改進會不利於過程的執行

CMM中定義了每個KPA的目標和一系列的KP，企業必須根據自己的實際情況去定義實現每個KPA的工作流程。但並不是每個企業都很幸運，在一開始就可以 定義一個自己企業的最佳實踐。一般的情況是，首先定義一個工作流程，並在一個試點專案中實行，而後對試點專案進行總結，並對此工作流程進行改進。再在其他 專案或整個企業中推廣，也許在推廣的過程中，又遇到問題，再對流程進行修改。整個的過程定義是螺旋上升的進行。這本身沒有問題，但有時當遇到問題時，不要 太急於就改流程，或加流程的分支。而要仔細分析後，慎重的進行。太頻繁的改動，給人一種不嚴肅的影響，似乎流程可以隨意的改動和定義。最後，沒人去遵守流 程了。 同時，根據不同的專案若定義了太多了流程分支，最後，實際人員也不知道要去實行哪一套了。

總之，頻繁改動的規矩，讓人無所適從。

過程制定後，一定要有選擇的進行試點。一個進度和成本寬餘的專案和一群對過程改進 有熱情的人是保證試點成功的組合

定義好一套流程，最好的驗證方式就是找個真實的專案去‘跑’一遍。並注意收集應用流程前後的各種情況的對比。由於在專案的進行中，還要試驗流程，所以需要 更多的培訓時間，讓專案組的成員瞭解熟悉新的流程。需要更多的評審，不但是評審專案本身，還要評審過程和進行必要的度量。

一群對於過程改進有熱情的組員是試點成功的保證。他們要有熱情去學習新的流程，要有熱情去溝通在執行新流程當中遇到的問題，他們要有熱情去克服進行中的困 難，而不是抱怨，他們要有熱情去總結和改進新的流程，使它更完善，最總要的是，他們要有熱情作為新流程的傳播者，把流程象星星之火一樣在組織中開展。


一個堅決支援過程改進的領導是必不可少的

象任何其他的變革一樣，一個堅決支援變革的領導是不可缺少的。在一切順利，大家贊成的時候，也許感覺不到什麼。但當變革遇到阻力，遭受暫時的困難時，這種堅決的支援就是變革是否可以繼續進行的保證。

因此，在過程改進的初期，於企業的高層進行溝通，讓其瞭解到過程改進的必要性和預期的前景是十分必要的。同時最好在過程改進的開始階段，一個誓師大會的舉 行也是鼓舞士氣的上佳方法。在過程改進的過程中也要注意及時的通報進行的過程，取得的成果。當然在遇到困難，或需要高層支援時，更要及時開口。（這對於技 術人員主持的過程改進尤為重要。）

要有選擇的對於KPA進行改進，不一定是最薄弱的KPA，最重要是選擇你可以控制的KPA

關於這點其實並不涉及CMM的技術問題，而是一個管理問題。這裡有個現實的例子，一家企業的管理有點亂，高層希望可以通過CMM的過程改進，來提高企業的 產品質量，理順工作的流程。於是任命了一個開發組的主管（代稱A），來主持這個過程改進。結果A在選擇KPA的時候，認為首先應該對於實行需求管理和變更 管理。因為開發組的同事們都抱怨，需求經常改變，造成的返工很多，在最終期限的壓力下他們不得不經常加班。這個本事沒有問題，可是需求管理和變革管理的發 起基本是在系統分析組，而這個組在行政上不歸他管。公司也沒有因為要進行過程改進而把他提高到一個高的級別（即使是暫時的）。


現在問題來了，雖然他花費了心思去設計的流程。並對於需求部門和相關部門組織了培訓。可是在進行試點的時候，他發現，當他去評審需求分析組的工作時，別人 很反感。而且對於有些需求的變革也推諉到銷售人員、客戶等因素。同時，流程中只要有一點不太合理的地方，就抱怨的很厲害。最後試點結束，他自己很累，試點 的結果也不好，改善的目標沒有實現。整個過程的改進處於一種微妙的處境。最後，試點的流程並沒有推廣。其他的KPA過程改進也不再進行了，隨著時間的推 移，過程改進在企業中也不在有人提起。

知道這位開發組的主管錯在哪裡嗎？他選錯了KPA，他選了一個不屬於自己管轄範圍的KPA作為起點。他跑到一個不屬於他的地方開始指手畫腳，他是個不受歡 迎的人。註定了，在一開始他就面對著對立和抱怨。這樣的團隊是無法經受一點點挫折和失敗的。若他一開始選擇配置管理，這個至於他管理範圍的KPA，他可以 利用手中的權利、資源和威信，組織試點。可能情況就好的多。又或者企業的高層給這個開發主管一個虛職，比如過程改進專案組組長，並任命其他組的組長為過程 改進專案組成員。情況也會完全不同。

對於過程的改進要有度量

不必一開始就是數字化的，也可以是感性的體會。但要把這些也要收集起來。一個有力的對比可以堵住反對者的嘴。不要因為度量管理是CMM4級的內容就在實施低階別的CMM時放棄度量。一套流程需要一系列度量的資料來說明它改進了多少。而度量的資料將會為它贏得預算和支援。

當然度量作為CMM4級的內容，也是有一定的道理的。收集一套完備、準確的度量是需要大量人力的。但是在一開始，也許我們可以藉助一些好的工具達到同樣的效果，而不必花費大量的時間和精力。

在我就自己做過一個簡易的BUG管理工具，並和資料庫相連。在專案結束時我可以輕易的瞭解專案中有多少BUG、BUG分佈如何，BUG的原因統計等度量資料。我只是用了幾個SQL語句就掌握了我需要的度量。

另一個例子是微軟推出的PROJECT SERVER（注：不是廣告）。以前專案經理要了解實際的專案進度並不是件輕鬆的事，專案經理要去問組員××模組，你開發的如何啦？然後收集好所有組員的 進度，填寫自己的專案進度。由於這相當的花費時間，過去進度基本上一週彙報一次。 可是有了PROJECT SERVER你只要按個‘請求進度’的按鈕，組員直接通過WEB填寫與他相關的進度就可以了。專案經理就可以得到整個專案的進度了。

不必拘泥於CMM的級別

這一點在CMMI中已經有體現了，CMMI不再只有一種級別的模式，還增加了持續改進的模式。即，可以按過程域進行改進，而不是過去按級別進行改進。

比如，CMM5級的技術革新管理。其實，在現在新技術層出不窮的當今，一個企業不會因為還沒到CMM5級就不需要技術革新管理。換一種資料庫，換一個開發工具，甚至是換一種開發過程等都是一直髮生的。若需要完全可以把這個KPA先實施改進。

不是每個人都喜歡改進的過程，特別對於要增加其工作量的過程。有時必須犧牲一些過程的嚴謹性，去簡化過程。畢竟有過程比沒過程好。

也許在看到了這條時很多人會不以為然，說：這樣做肯定過不了CMM評審。對，這樣確實肯定過不了CMM級別的評審，可是隻要可以對於過程有改進，對於軟體 質量有提高，就可以了。對於中小軟體企業，一個有效的（可以滿足高層對於過程控制的期望），簡易的（是所有基層工作人員可以理解的，無須大量培訓的），可 行的（不會大量增加基層人員的工作量，不會影響開發速度和效率的。名言是：‘我不要那種原先2天可以完成的專案，因為應用了過程，現在要5天才可以完成的 所謂的過程’。）和低成本的（公司一年才賺多少，我可不想把錢全用來採購工具軟體）過程才是最重要的。

選擇合適的工具，至關重要。好的工具不但使過程更流暢，也大大減少由於過程的引進而引入的工作量。


關於這點其實在前面介紹PROJECT SERVER時已經有介紹。這裡只是再作為一個觀點再提一下。不過雖然工具的使用可以提高效率，不過這方面的工具都不便宜。是否引進，何時引進確實對於中小型的軟體企業要好好考慮。

在這裡列一些工具供大家參考：

計劃工具：Microsoft Project

專案監督和跟蹤：Microsoft Project server 2003，SharePoint

需求管理：Rational RequisitePro, Borland CaliberRM, SYSBASE POWERDESIGN 11

變更管理：Rational ClearQuest

Bug跟蹤工具：Rational ClearQuest

配置管理工具：VSS, CVS, Rational Clearcase

一個強有力的執行和守紀律的企業文化，是推廣過程改進的保證

一個過程，在試點後，是要推廣的，在推廣過程中一個強有力的執行力是必然的保證，這個不用多言。

而對於守紀律的企業文化本來我並沒有太深的感受，直到有個朋友告訴我，他們公司的印度工程師如何的刻板。我突然意識到這也許就是國內軟體公司長不大的原因 了。是的，嚴格的遵守企業定出的過程，有時是顯得有些刻板。但在相當長的其他時期，也正是這種刻板，保證了公司的過程被嚴格執行。

有人說，什麼標準一到中國就變了味了。這雖然不太好聽，但你不得不承認，有時我們確實為了省力，為了趕工，確實在破壞公司的過程。

畢竟CMM只是軟體開發的過程改進的標準，但一個軟體專案的成功，並不侷限於軟體開發。用CMM的模式去改進一些前期專案計劃和後期系統實施的過程，將會對組織的軟體專案的成功事倍功半。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-142367/，如需轉載，請註明出處，否則將追究法律責任。