2001我開始慢慢關注起軟件工程和CMM，也對CMM進行了學習。并且對其中的一些KPA在自己單位中進行了試驗�？墒且婚_始這些試驗的結果并不令人愉快，甚至遭到了抵制和反對。開發和測試人員認為降低了開發速度和靈活性，加大了工作量，工作流程太煩瑣。而質量的提高也不是一時可以反映出來的。于是在進行了2個小項目的試驗后，我被迫停止了CMM在公司的實施。因為公司并不從事外包服務，所以CMM對其沒有生存的壓力。高層也只是想通過一個可行的過程管理，一個提高軟件質量，保證項目進度，有效控制項目成本。所以公司并不是要去過CMM等級，而是要一個有效的過程管理。
所以我此后開始以‘有效、簡易、可行、低成本’為標準探索起適合起我們公司的過程改進的最佳實踐�，F在，我很高興可以在文中和大家探討我公司在過程改進過程中的一些經驗和教訓，也許你會從中得到一些啟發，開發出適合你自己的最佳實際。歡迎對此文章提出評論和質疑，您的來信將是我繼續研究的動力�？梢园lMail：bluehao@online.sh.cn, roychen7608@yeah.net MSN: bluehao7608@hotmail.com
經驗和教訓：
在中小型的軟件企業當中，軟件過程的改進更容易半途而廢。
中小企業，特別是開發人員小于40個人的企業。一般不會有專門的人員可以組建‘軟件過程組’，也很少會有專職的質量工程師和配置工程師。在進行過程改進中，對于這些職位基本上都是由原來的人員兼職完成。這無形中增加了人員的工作量。一旦過程定義的不是太完善，或是在試點中不是太成功。很容易讓人去懷疑過程改進本身的可行性。同時中小企業接到的項目也比較小，成本壓力是比較大的，而提高質量是必須以犧牲成本為代價的。所以有時從成本的角度出發，可能在高層管理人員的心目中，對于過程改進也是有成本的顧慮的，一方面希望，可以通過過程改進提供質量，并為企業的發展提供基礎，另一方面，也面臨成本壓力，若過程是改進了，可是成本也大幅度提高了，則本事企業的生存就成問題了。而在大的軟件企業，一般可以有專職的人員進行質量保證和過程改進。同時由于大企業拿到的項目一般也比較大，項目組就比較大，客戶要求也高。這也為過程改進增加了必要性。持續的改進很重要，但頻繁的改進會不利于過程的執行CMM中定義了每個KPA的目標和一系列的KP，企業必須根據自己的實際情況去定義實現每個KPA的工作流程。但并不是每個企業都很幸運，在一開始就可以定義一個自己企業的最佳實踐。一般的情況是，首先定義一個工作流程，并在一個試點項目中實行，而后對試點項目進行總結，并對此工作流程進行改進。再在其他項目或整個企業中推廣，也許在推廣的過程中，又遇到問題，再對流程進行修改。整個的過程定義是螺旋上升的進行。 這本身沒有問題，但有時當遇到問題時，不要太急于就改流程，或加流程的分支。而要仔細分析后，慎重的進行。太頻繁的改動，給人一種不嚴肅的影響，似乎流程可以隨意的改動和定義。最后，沒人去遵守流程了。 同時，根據不同的項目若定義了太多了流程分支，最后，實際人員也不知道要去實行哪一套了�？傊�，頻繁改動的規矩，讓人無所適從。過程制定后，一定要有選擇的進行試點。一個進度和成本寬余的項目和一群對過程改進 有熱情的人是保證試點成功的組合。定義好一套流程，最好的驗證方式就是找個真實的項目去‘跑’一遍。并注意收集應用流程前后的各種情況的對比。由于在項目的進行中，還要試驗流程，所以需要更多的培訓時間，讓項目組的成員了解熟悉新的流程。需要更多的評審，不但是評審項目本身，還要評審過程和進行必要的度量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
