2001我開始慢慢關注起軟件工程和CMM，也對CMM進行了學習。并且對其中的一些KPA在自己單位中進行了試驗�？墒且婚_始這些試驗的結果并不令人愉快，甚至遭到了抵制和反對。開發和測試人員認為降低了開發速度和靈活性，加大了工作量，工作流程太煩瑣。而質量的提高也不是一時可以反映出來的。于是在進行了2個小項目的試驗后，我被迫停止了CMM在公司的實施。因為公司并不從事外包服務，所以CMM對其沒有生存的壓力。高層也只是想通過一個可行的過程管理，一個提高軟件質量，保證項目進度，有效控制項目成本。所以公司并不是要去過CMM等級，而是要一個有效的過程管理。
所以我此后開始以‘有效、簡易、可行、低成本’為標準探索起適合起我們公司的過程改進的最佳實踐�，F在，我很高興可以在文中和大家探討我公司在過程改進過程中的一些經驗和教訓，也許你會從中得到一些啟發，開發出適合你自己的最佳實際�！�
經驗和教訓：
在中小型的軟件企業當中，軟件過程的改進更容易半途而廢。
中小企業，特別是開發人員小于40個人的企業。一般不會有專門的人員可以組建‘軟件過程組’，也很少會有專職的質量工程師和配置工程師。在進行過程改進中，對于這些職位基本上都是由原來的人員兼職完成。這無形中增加了人員的工作量。一旦過程定義的不是太完善，或是在試點中不是太成功。很容易讓人去懷疑過程改進本身的可行性。同時中小企業接到的項目也比較小，成本壓力是比較大的，而提高質量是必須以犧牲成本為代價的。所以有時從成本的角度出發，可能在高層管理人員的心目中，對于過程改進也是有成本的顧慮的，一方面希望，可以通過過程改進提供質量，并為企業的發展提供基礎，另一方面，也面臨成本壓力，若過程是改進了，可是成本也大幅度提高了，則本事企業的生存就成問題了。而在大的軟件企業，一般可以有專職的人員進行質量保證和過程改進。同時由于大企業拿到的項目一般也比較大，項目組就比較大，客戶要求也高。這也為過程改進增加了必要性。持續的改進很重要，但頻繁的改進會不利于過程的執行CMM中定義了每個KPA的目標和一系列的KP，企業必須根據自己的實際情況去定義實現每個KPA的工作流程。但并不是每個企業都很幸運，在一開始就可以定義一個自己企業的最佳實踐。一般的情況是，首先定義一個工作流程，并在一個試點項目中實行，而后對試點項目進行總結，并對此工作流程進行改進。再在其他項目或整個企業中推廣，也許在推廣的過程中，又遇到問題，再對流程進行修改。整個的過程定義是螺旋上升的進行。 這本身沒有問題，但有時當遇到問題時，不要太急于就改流程，或加流程的分支。而要仔細分析后，慎重的進行。太頻繁的改動，給人一種不嚴肅的影響，似乎流程可以隨意的改動和定義。最后，沒人去遵守流程了。 同時，根據不同的項目若定義了太多了流程分支，最后，實際人員也不知道要去實行哪一套了�？傊�，頻繁改動的規矩，讓人無所適從。過程制定后，一定要有選擇的進行試點。一個進度和成本寬余的項目和一群對過程改進 有熱情的人是保證試點成功的組合。定義好一套流程，最好的驗證方式就是找個真實的項目去‘跑’一遍。并注意收集應用流程前后的各種情況的對比。由于在項目的進行中，還要試驗流程，所以需要更多的培訓時間，讓項目組的成員了解熟悉新的流程。需要更多的評審，不但是評審項目本身，還要評審過程和進行必要的度量。
一群對于過程改進有熱情的組員是試點成功的保證。他們要有熱情去學習新的流程，要有熱情去溝通在執行新流程當中遇到的問題，他們要有熱情去克服進行中的困難，而不是抱怨，他們要有熱情去總結和改進新的流程，使它更完善，最總要的是，他們要有熱情作為新流程的傳播者，把流程象星星之火一樣在組織中開展。一個堅決支持過程改進的領導是必不可少的。象任何其他的變革一樣，一個堅決支持變革的領導是不可缺少的。在一切順利，大家贊成的時候，也許感覺不到什么。但當變革遇到阻力，遭受暫時的困難時，這種堅決的支持就是變革是否可以繼續進行的保證。因此，在過程改進的初期，于企業的高層進行溝通，讓其了解到過程改進的必要性和預期的前景是十分必要的。同時最好在過程改進的開始階段，一個誓師大會的舉行也是鼓舞士氣的上佳方法。在過程改進的過程中也要注意及時的通報進行的過程，取得的成果。當然在遇到困難，或需要高層支持時，更要及時開口。(這對于技術人員主持的過程改進尤為重要。)要有選擇的對于KPA進行改進，不一定是最薄弱的KPA，最重要是選擇你可以控制的KPA。關于這點其實并不涉及CMM的技術問題，而是一個管理問題。這里有個現實的例子，一家企業的管理有點亂，高層希望可以通過CMM的過程改進，來提高企業的產品質量，理順工作的流程。于是任命了一個開發組的主管(代稱A)，來主持這個過程改進。 結果A在選擇KPA的時候，認為首先應該對于實行需求管理和變更管理。因為開發組的同事們都抱怨，需求經常改變，造成的返工很多，在最終期限的壓力下他們不得不經常加班。 這個本事沒有問題，可是需求管理和變革管理的發起基本是在系統分析組，而這個組在行政上不歸他管。公司也沒有因為要進行過程改進而把他提高到一個高的級別(即使是暫時的)。
現在問題來了，雖然他花費了心思去設計的流程。并對于需求部門和相關部門組織了培訓�？墒窃谶M行試點的時候，他發現，當他去評審需求分析組的工作時，別人很反感。而且對于有些需求的變革也推諉到銷售人員、客戶等因素。同時，流程中只要有一點不太合理的地方，就抱怨的很厲害。最后試點結束，他自己很累，試點的結果也不好，改善的目標沒有實現。整個過程的改進處于一種微妙的處境。最后，試點的流程并沒有推廣。其他的KPA過程改進也不再進行了，隨著時間的推移，過程改進在企業中也不在有人提起。知道這位開發組的主管錯在哪里嗎? 他選錯了KPA，他選了一個不屬于自己管轄范圍的KPA作為起點。他跑到一個不屬于他的地方開始指手畫腳，他是個不受歡迎的人。注定了，在一開始他就面對著對立和抱怨。這樣的團隊是無法經受一點點挫折和失敗的。若他一開始選擇配置管理，這個至于他管理范圍的KPA，他可以利用手中的權利、資源和威信，組織試點�？赡芮闆r就好的多。 又或者企業的高層給這個開發主管一個虛職，比如過程改進項目組組長，并任命其他組的組長為過程改進項目組成員。情況也會完全不同。
對于過程的改進要有度量。不必一開始就是數字化的，也可以是感性的體會。但要把這些也要收集起來。 一個有力的對比可以堵住反對者的嘴。不要因為度量管理是CMM4級的內容就在實施低級別的CMM時放棄度量。一套流程需要一系列度量的數據來說明它改進了多少。而度量的數據將會為它贏得預算和支持。當然度量作為CMM4級的內容，也是有一定的道理的。收集一套完備、準確的度量是需要大量人力的。但是在一開始，也許我們可以借助一些好的工具達到同樣的效果，而不必花費大量的時間和精力。在我就自己做過一個簡易的BUG管理工具，并和數據庫相連。在項目結束時我可以輕易的了解項目中有多少BUG、BUG分布如何，BUG的原因統計等度量數據。我只是用了幾個SQL語句就掌握了我需要的度量。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
