一提到CMMI，大家就会想到QA；一提到QA，大家又都觉得无奈。有的企业设置了全职的QA人员，但是总觉得起不到应有的效果；有的企业将QA和测试合并在一起，基本上就都在干测试了。关于QA Manager（or Leader）的重要性上一篇（http://bowiehobby.blog.ccidnet.com/blog-htm-do-showone-uid-524637-type-blog-itemid-8594228.html）已经涉及到了，这次谈谈QA工作本身该如何有效开展。
国内绝大部分中小型软件企业对于QA人员的安排基本都是测试人员或者是开发人员转岗过来的，工作经验也基本都在1-3年以内，人员也一般在1-3人。这样的一个团队想要顺利的开展Assurance的工作的挑战是很大的。
首先，他们的工程经验还不够丰富，无论之前是研发和测试的经验都不足够深入的理解如何更有效的进行团队软件开发。毕竟在前2年基本上还是新人的角色，不可能承担很重要的业务；也是在提高技术能力的同时在适应企业的文化，从学生角色转变成员工角色。
其次，他们的理论技能还有很大的差距。想要真正理解CMMI模型并运用起来，是需要有深厚的工程背景和管理背景的，正因为第一点的原因，同时也导致QA人员很难准确理解CMMI模型的精髓，这样势必会难以合理运用。
再次，公司本身一定会更重视技术人员一些。当有争议发生的时候，绝大部分时间都会偏向技术人员，导致QA工作难以展开。
在以上的场景下要顺利开展QA工作，是一件斗智斗勇的事情。我觉得有以下几个突破口：
1. 调整心态。QA人员虽然是以Assurance为核心工作，但是需要以虚心的态度去跟着项目组学习已经得到证实的经验和结果；同时积极思考，这些实践在 CMMI体系中是如何描述的，是否有差异，差异在哪里，哪个对本企业更有帮助，实在有冲突如何进行融合。把这些问题思考清楚是很关键的，在自身能力有限的情况下，以不耻下问的心态积极与项目经理、测试经理、项目骨干等人员进行沟通和请教。很多QA都把自己当成是稽核人员，变成了Audit的角色，根据所谓的体系文件来要求和指挥项目组做这做那，很多根本都不知道为什么要这么做，这么做的结果大部分都是在做无用功。
这里有2个关键点。1个是要转换角色，不要把自己当做项目外部的稽核人员，要把自己当成是项目组的一员来思考和解决项目中发生的问题。2个就是要不耻下问，毕竟在经验不够丰富的时候，是需要有经验的人来帮助的，这个时候请教就是一件非常非常重要的事情了。
2. 积极学习。 QA人员要不断的学习软件相关的理论体系知识，例如：CMMI、PMBOK、Liftcycle、XP等都是必备的，有了这些理论知识的补充才能更有效的从实践中体会和验证理论，同时也指导实践工作的开展。还有一个方面必须要学习的就是公司的主流技术，对公司现有主流技术的了解可以更深入的切入到项目实施中，用项目组成员的语言与他们交流是非常有收获的。
这里的关键就是要不断的学习，软件工程、管理、技术都是必要的，安排合理的学习计划，在持续改进的同时持续的学习和实践。
3. 善于沟通。很多QA在推行CMMI体系的时候经常会抱怨组织给与的支持和权利不够，不足以让项目组“听话”。这两者固然重要，但是让体系得以运作的除了这两点还需要沟通的技巧。毕竟体系的执行主体都是人，在没有强大的组织支持和授权时如何说服别人按照体系做事沟通是关键。你要站在对方的角度去思考人家为什么要用这个体系，用了后是对项目有利了还是增加麻烦了，对组织是增加了混乱还是添加了效率。只有把这些都思考清楚了，然后再以帮助人家的思路去跟人家沟通清楚，坦诚相对，同时积极听取项目组的意见和建议，大家协商来制定流程和规范。让项目更多的参与到规范制定的活动中来，这样的沟通才能有效的调动项目经理的积极性，只要项目经理愿意协助，后面的事情就好办很多了。（关于如何沟通，后面会有单独的一篇来讨论。）
以上几点都是我自己在QA相关工作中通过碰壁碰出来的，总结后发现效果非常好，与大家分享。后面会谈谈EPG相关主题。
