1.決定實施CMMI
2.EPG接受培訓，理解CMMI
3.EPG根據自己理解的CMMI和實際情況開發一大堆漂漂亮亮的過程文檔、流程圖、表格、模板、檢查單、作業指南。
4.大家邊聽著EPG的解釋(包括培訓、答疑)，邊執行這些過程標準，然后審計(內、外)
CMMI不是過程模型，是過程改進模型，根據CMMI定義過程是錯誤的做法!
所謂"定義"過程是將目前的實際的最佳實踐記錄下來、寫下來、文檔化下來。
很多新的EPG在做了一段時間后無奈的發現自己居然淪落成了一個過程標準解說員、甚至文檔管理員。當發現自己工作大部分時間是面對文檔時，已經走偏了，我認為EPG主要應該關注兩個方面：1.全員主動積極的過程改進意識和質量意識的提升，更多要做的是促使質量經理加強質量意識建設、研發經理加強經驗教訓積累、人力資源部加強企業文化建設。2.幫助研發人員解決研發過程中面臨的最嚴重的實際問題(當然是解決方案要上升到過程高度,而不應是單個問題或個人)。
通過收集過程改進建議、經驗教訓總結、解決的一些實際問題，經過幾年的積累，在這幾年中有意無意的將這些經驗教訓文檔化下來，最終形成過程標準。
事實上我們沒有用CMMI時，大家也經常在做定義過程的事，例如，你去財務報銷，一般會問財務或其他同事，他們會告訴你在哪拿單、填單、找誰簽字等流程，這些人被問得多了，為了省事就會寫個指南供以后新人看，最后形成了報銷的規程。
目前很多企業一開始就定義一大堆過程標準，過程標準所描述的那種過程與實際過程相差十萬八千里。然后請高級領導來開個動員大會，告訴大家我們要搞規范化管理，要從人治轉到法治(這點最錯，過程標準不是用來限制人的工作的，是用來做經驗教訓積累的.)，要大家按過程標準去做，工程師都很聽話，乖乖的按過程標準一步步都做了，該寫的文檔一個不少，但寫了就再也沒用過了，需求跟蹤矩陣做得好詳細，但評審時沒人用、變更時沒人用、沒人愿意去更新。
過程改進不是一蹴可就的，要慢慢積累。根據CMMI標準定義過程標準，那是想一步登天。
很多人剛接觸CMMI說看不懂，原因是CMMI里面所講的一些實踐或子實踐背后的工程知識、項目管理知識等等以前并未接觸過。事實上這些應該是EPG工作的基礎知識，不是看不懂CMMI，是不懂CMMI背后的一些與特定工程、管理知識相關的內容，你看不懂就是你還不夠格做EPG，應該再看看專業相關的書籍、文獻，在回頭來看CMMI，舉個例子，很多人問我關于操作場景，為什么CMMI那么重視，到底我們應該怎么做，推薦你看看《交互設計之路-讓高科技產品回歸人性》。如果已經了解過這些工程、管理知識，再看CMMI，你會發現CMMI就那回事，只是一個檢查單而已、里面的SP、GP只是一些檢查項，用來找研發企業過程問題的。只是工具，很多東西它沒有告訴你。EPG要做的是首先自己學習這些工程和管理知識、然后將它們散播到各專業的核心人員大腦里去，等一些專業人員都掌握了他們本該掌握的這些專業知識后，再來做改進，就變的順理成章，大家的參與熱情也會很高，因為這些專業人員自己就會發現這些方法和知識是可以將自己工作做得更好的，自己以前的做法不夠專業，往往自己就會主動的想辦法改進。EPG要做的是促進這個從知識引進到轉化成生產力的過程加速進行。
---過程標準的定義是經驗教訓的知識積累過程，是隱性知識向顯性知識轉化的過程，不是CMMI模型"實例化"的過程.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
