1、個人收集整理僅供參考學習軟件過程改進：經(jīng)驗和教訓前言：2001我開始慢慢關注起軟件工程和 CMM,也對CMM進行了學習。并且對其 中的一些KPA在自己單位中進行了試驗。可是一開始這些試驗的結果并不令人 愉快，甚至遭到了抵制和反對。開發(fā)和測試人員認為降低了開發(fā)速度和靈活性， 加大了工作量，工作流程太煩瑣。而質量的提高也不是一時可以反映出來的。 于 是在進行了 2個小項目的試驗后，我被迫停止了 CMM在公司的實施。因為公司并不從事外包服務，所以CMM對其沒有生存的壓力。高層也只是想通 過一個可行的過程管理，一個提高軟件質量，保證項目進度，有效控制項目成本。 所以公司并不是要去過 CMM等級，而是要

2、一個有效的過程管理。所以我此后開始以 有效、簡易、可行、低成本為標準探索起適合起我們公司的 過程改進的最佳實際。現(xiàn)在，我很高興可以在文中和大家探討我公司在過程改進 過程中的一些經(jīng)驗和教訓，也許你會從中得到一些啟發(fā)，開發(fā)出適合你自己的最 佳實際。經(jīng)驗和教訓: 在中小型的軟件企業(yè)當中，軟件過程的改進更容易半途而廢中小企業(yè)，特別是開發(fā)人員小于 40個人的企業(yè)。一般不會有專門的人員可以組 建軟件過程組，也很少會有專職的質量工程師和配置工程師。在進行過程改進 中，對于這些職位基本上都是由原來的人員兼職完成。 這無形中增加了人員的工 作量。一旦過程定義的不是太完善，或是在試點中不是太成功。很容易讓人去懷

3、疑過程改進本身的可行性。同時中小企業(yè)接到的項目也比較小， 成本壓力是比較 大的，而提高質量是必須以犧牲成本為代價的。 所以有時從成本的角度出發(fā)，可 能在高層管理人員的心目中，對于過程改進也是有成本的顧慮的，一方面希望， 可以通過過程改進提供質量，并為企業(yè)的發(fā)展提供基礎，另一方面，也面臨成本 壓力，若過程是改進了，可是成本也大幅度提高了，則本事企業(yè)的生存就成問題 了。而在大的軟件企業(yè)，一般可以有專職的人員進行質量保證和過程改進。 同時由于 大企業(yè)拿到的項目一般也比較大， 項目組就比較大，客戶要求也高。這也為過程 改進增加了必要性。持續(xù)的改進很重要，但頻繁的改進會不利于過程的執(zhí)行CMM中定義了每個

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

5、若定義了太多了流程分支，最后， 實際人員也不知道要去實行哪一套了。總之，頻繁改動的規(guī)矩，讓人無所適從。過程制定后，一定要有選擇的進行試點。一個進度和成本寬余的項目和一群對過程改進 有熱情的人是保證試點成功的組合跑一遍。并注意收集還要試驗流程，所以需需要更多的評審，不但定義好一套流程，最好的驗證方式就是找個真實的項目去 應用流程前后的各種情況的對比。 由于在項目的進行中, 要更多的培訓時間，讓項目組的成員了解熟悉新的流程。 是評審項目本身，還要評審過程和進行必要的度量。一群對于過程改進有熱情的組員是試點成功的保證。 他們要有熱情去學習新的流 程，要有熱情去溝通在執(zhí)行新流程當中遇到的問題，他們要有

6、熱情去克服進行中的困難，而不是抱怨，他們要有熱情去總結和改進新的流程，使它更完善，最總 要的是，他們要有熱情作為新流程的傳播者， 把流程象星星之火一樣在組織中開 展。一個堅決支持過程改進的領導是必不可少的 象任何其他的變革一樣，一個堅決支持變革的領導是不可缺少的。在一切順利, 大家贊成的時候，也許感覺不到什么。但當變革遇到阻力，遭受暫時的困難時, 這種堅決的支持就是變革是否可以繼續(xù)進行的保證。因此，在過程改進的初期，于企業(yè)的高層進行溝通，讓其了解到過程改進的必要 性和預期的前景是十分必要的。同時最好在過程改進的開始階段，一個誓師大會 的舉行也是鼓舞士氣的上佳方法。在過程改進的過程中也要注意及時

7、的通報進行 的過程，取得的成果。當然在遇到困難，或需要高層支持時，更要及時開口。（這 對于技術人員主持的過程改進尤為重要。） 要有選擇的對于KPA進行改進，不一定是最薄弱的 KPA,最重要是選擇你可以 控制的KPA關于這點其實并不涉及CMM的技術問題，而是一個管理問題。這里有個現(xiàn)實的 例子，一家企業(yè)的管理有點亂，高層希望可以通過 CMM的過程改進，來提高企 業(yè)的產(chǎn)品質量，理順工作的流程。于是任命了一個開發(fā)組的主管（代稱A）,來主持這個過程改進。結果 A在選擇KPA的時候，認為首先應該對于實行需求管 理和變更管理。因為開發(fā)組的同事們都抱怨，需求經(jīng)常改變，造成的返工很多，在最終期限的壓力下他們不得

8、不經(jīng)常加班。 這個本事沒有問題，可是需求管理和 變革管理的發(fā)起基本是在系統(tǒng)分析組， 而這個組在行政上不歸他管。公司也沒有 因為要進行過程改進而把他提高到一個高的級別（即使是暫時的）。現(xiàn)在問題來了，雖然他花費了心思去設計的流程。并對于需求部門和相關部門組 織了培訓。可是在進行試點的時候，他發(fā)現(xiàn)，當他去評審需求分析組的工作時， 別人很反感。而且對于有些需求的變革也推諉到銷售人員、客戶等因素。同時， 流程中只要有一點不太合理的地方， 就抱怨的很厲害。最后試點結束，他自己很 累，試點的結果也不好，改善的目標沒有實現(xiàn)。整個過程的改進處于一種微妙的 處境。最后，試點的流程并沒有推廣。其他的 KPA過程改進

9、也不再進行了，隨 著時間的推移，過程改進在企業(yè)中也不在有人提起。知道這位開發(fā)組的主管錯在哪里嗎？他選錯了 KPA,他選了一個不屬于自己管 轄范圍的KPA作為起點。他跑到一個不屬于他的地方開始指手畫腳，他是個不 受歡迎的人。注定了，在一開始他就面對著對立和抱怨。這樣的團隊是無法經(jīng)受 一點點挫折和失敗的。若他一開始選擇配置管理，這個至于他管理范圍的KPA,他可以利用手中的權利、資源和威信，組織試點。可能情況就好的多。又或者企 業(yè)的高層給這個開發(fā)主管一個虛職， 比如過程改進項目組組長，并任命其他組的 組長為過程改進項目組成員。情況也會完全不同。對于過程的改進要有度量不必一開始就是數(shù)字化的，也可以是感

10、性的體會。但要把這些也要收集起來。- 個有力的對比可以堵住反對者的嘴。不要因為度量管理是CMM4級的內(nèi)容就在實施低級別的CMM時放棄度量。一套流程需要一系列度量的數(shù)據(jù)來說明它改進 了多少。而度量的數(shù)據(jù)將會為它贏得預算和支持。當然度量作為CMM4級的內(nèi)容，也是有一定的道理的。收集一套完備、準確的 度量是需要大量人力的。但是在一開始，也許我們可以借助一些好的工具達到同 樣的效果，而不必花費大量的時間和精力。在我就自己做過一個簡易的BUG管理工具，并和數(shù)據(jù)庫相連。在項目結束時我 可以輕易的了解項目中有多少 BUG、BUG分布如何，BUG的原因統(tǒng)計等度量 數(shù)據(jù)。我只是用了幾個SQL語句就掌握了我需要的

11、度量。另一個例子是微軟推出的PROJECT SERVER （注：不是廣告）。以前項目經(jīng)理要了解實際的項目進度并不是件輕松的事, 開發(fā)的如何啦？然后收集好所有組員的進度, 的花費時間，過去進度基本上一周匯報一次。 只要按個請求進度酌按鈕，組員直接通過 項目經(jīng)理就可以得到整個項目的進度了。項目經(jīng)理要去問組員XX模塊，你填寫自己的項目進度。由于這相當可是有了 PROJECT SERVER 你WEB填寫與他相關的進度就可以了。5 / 5不必拘泥于CMM的級別這一點在CMMI中已經(jīng)有體現(xiàn)了，CMMI不再只有一種級別的模式，還增加了 持續(xù)改進的模式。即，可以按過程域進行改進，而不是過去按級別進行改進。比如

12、，CMM5級的技術革新管理。其實，在現(xiàn)在新技術層出不窮的當今，一個 企業(yè)不會因為還沒到CMM5級就不需要技術革新管理。換一種數(shù)據(jù)庫，換一個 開發(fā)工具，甚至是換一種開發(fā)過程等都是一直發(fā)生的。若需要完全可以把這個 KPA先實施改進。不是每個人都喜歡改進的過程，特別對于要增加其工作量的過程。有時必須犧牲 一些過程的嚴謹性，去簡化過程。畢竟有過程比沒過程好。也許在看到了這條時很多人會不以為然， 說：這樣做肯定過不了 CMM評審。對, 這樣確實肯定過不了 CMM級別的評審，可是只要可以對于過程有改進，對于軟 件質量有提高，就可以了。對于中小軟件企業(yè)，一個有效的（可以滿足高層對于 過程控制的期望），簡易的

13、（是所有基層工作人員可以理解的，無須大量培訓的）， 可行的（不會大量增加基層人員的工作量，不會影響開發(fā)速度和效率的。名言是： 我不要那種原先2天可以完成的項目，因為應用了過程，現(xiàn)在要 5天才可以完 成的所謂的過程）和低成本的（公司一年才賺多少，我可不想把錢全用來采 購工具軟件）過程才是最重要的。選擇合適的工具，至關重要。好的工具不但使過程更流暢，也大大減少由于過程 的引進而引入的工作量。關于這點其實在前面介紹PROJECT SERVER時已經(jīng)有介紹。這里只是再作為 一個觀點再提一下。不過雖然工具的使用可以提高效率，不過這方面的工具都不 便宜。是否引進，何時引進確實對于中小型的軟件企業(yè)要好好考慮

14、。在這里列一些工具供大家參考：計劃工具：Microsoft Project項目監(jiān)督和跟蹤：Microsoft Project server 2003, SharePoint需求管理：Rational RequisitePro, Borland CaliberRM, SYSBASE POWERDESIGN 11變更管理：Rational ClearQuestBug 跟蹤工具：Rational ClearQuest配置管理工具：VSS, CVS, Rational Clearcase一個強有力的執(zhí)行和守紀律的企業(yè)文化，是推廣過程改進的保證一個過程，在試點后，是要推廣的，在推廣過程中一個強有力的執(zhí)行力是必然的 保證，這個不用多言。而對于守紀律的企業(yè)文化本來我并沒有太深的感受，直到有個朋友告訴我，他們公司的印度工程師如何的刻板。我突然意識到這也許就是國內(nèi)軟