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模型"实例化"的过程.
文章来源于领测软件测试网 https://www.ltesting.net/
