軟件過程改進：經驗和教訓

前言：

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

　　所以我此后開始以‘有效、簡易、可行、低成本’為標準探索起適合起我們公司的過程改進的最佳實踐?，F在，我很高興可以在文中和大家探討我公司在過程改進過程中的一些經驗和教訓，也許你會從中得到一些啟發，開發出適合你自己的最佳實際?！　〗涷灪徒逃枺?/P>

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

　　中小企業，特別是開發人員小于40個人的企業。一般不會有專門的人員可以組建‘軟件過程組’，也很少會有專職的質量工程師和配置工程師。在進行過程改進中，對于這些職位基本上都是由原來的人員兼職完成。這無形中增加了人員的工作量。一旦過程定義的不是太完善，或是在試點中不是太成功。很容易讓人去懷疑過程改進本身的可行性。同時中小企業接到的項目也比較小，成本壓力是比較大的，而提高質量是必須以犧牲成本為代價的。所以有時從成本的角度出發，可能在高層管理人員的心目中，對于過程改進也是有成本的顧慮的，一方面希望，可以通過過程改進提供質量，并為企業的發展提供基礎，另一方面，也面臨成本壓力，若過程是改進了，可是成本也大幅度提高了，則本事企業的生存就成問題了。而在大的軟件企業，一般可以有專職的人員進行質量保證和過程改進。同時由于大企業拿到的項目一般也比較大，項目組就比較大，客戶要求也高。這也為過程改進增加了必要性。持續的改進很重要，但頻繁的改進會不利于過程的執行CMM中定義了每個KPA的目標和一系列的KP，企業必須根據自己的實際情況去定義實現每個KPA的工作流程。但并不是每個企業都很幸運，在一開始就可以定義一個自己企業的最佳實踐。一般的情況是，首先定義一個工作流程，并在一個試點項目中實行，而后對試點項目進行總結，并對此工作流程進行改進。再在其他項目或整個企業中推廣，也許在推廣的過程中，又遇到問題，再對流程進行修改。整個的過程定義是螺旋上升的進行。 這本身沒有問題，但有時當遇到問題時，不要太急于就改流程，或加流程的分支。而要仔細分析后，慎重的進行。太頻繁的改動，給人一種不嚴肅的影響，似乎流程可以隨意的改動和定義。最后，沒人去遵守流程了。 同時，根據不同的項目若定義了太多了流程分支，最后，實際人員也不知道要去實行哪一套了?？傊?，頻繁改動的規矩，讓人無所適從。過程制定后，一定要有選擇的進行試點。一個進度和成本寬余的項目和一群對過程改進 有熱情的人是保證試點成功的組合。定義好一套流程，最好的驗證方式就是找個真實的項目去‘跑’一遍。并注意收集應用流程前后的各種情況的對比。由于在項目的進行中，還要試驗流程，所以需要更多的培訓時間，讓項目組的成員了解熟悉新的流程。需要更多的評審，不但是評審項目本身，還要評審過程和進行必要的度量。

一群對于過程改進有熱情的組員是試點成功的保證。他們要有熱情去學習新的流程，要有熱情去溝通在執行新流程當中遇到的問題，他們要有熱情去克服進行中的困難，而不是抱怨，他們要有熱情去總結和改進新的流程，使它更完善，最總要的是，他們要有熱情作為新流程的傳播者，把流程象星星之火一樣在組織中開展。一個堅決支持過程改進的領導是必不可少的。象任何其他的變革一樣，一個堅決支持變革的領導是不可缺少的。在一切順利，大家贊成的時候，也許感覺不到什么。但當變革遇到阻力，遭受暫時的困難時，這種堅決的支持就是變革是否可以繼續進行的保證。因此，在過程改進的初期，于企業的高層進行溝通，讓其了解到過程改進的必要性和預期的前景是十分必要的。同時最好在過程改進的開始階段，一個誓師大會的舉行也是鼓舞士氣的上佳方法。在過程改進的過程中也要注意及時的通報進行的過程，取得的成果。當然在遇到困難，或需要高層支持時，更要及時開口。(這對于技術人員主持的過程改進尤為重要。)要有選擇的對于KPA進行改進，不一定是最薄弱的KPA，最重要是選擇你可以控制的KPA。關于這點其實并不涉及CMM的技術問題，而是一個管理問題。這里有個現實的例子，一家企業的管理有點亂，高層希望可以通過CMM的過程改進，來提高企業的產品質量，理順工作的流程。于是任命了一個開發組的主管(代稱A)，來主持這個過程改進。 結果A在選擇KPA的時候，認為首先應該對于實行需求管理和變更管理。因為開發組的同事們都抱怨，需求經常改變，造成的返工很多，在最終期限的壓力下他們不得不經常加班。 這個本事沒有問題，可是需求管理和變革管理的發起基本是在系統分析組，而這個組在行政上不歸他管。公司也沒有因為要進行過程改進而把他提高到一個高的級別(即使是暫時的)。

原文轉自：http://www.kjueaiud.com