软件测试中的CMMI杂感
敏捷和CMMI是否矛盾问题
首先应该是考虑为何要实施CMMI的问题，如果仅仅是获取PassPort的话那很多后话都不用再谈．但真正的目的还是应该是降低软件开发生命周期的总成本，这个要用发展观点来看应该是一个中期或远期的考虑．如果实施了CMMI成本没有降低，那就只能说CMMI的实施是失败的不管是做了多数KPA,输出了多少文档，改进了多少过程．
对于敏捷或快速开发，如果过多的依赖是个人英雄主义，但势必和CMMI的理念是矛盾的．如果采用敏捷思路是提高开发效率，降低开发成本，考虑中长期软件开发的成本，那和CMMI的思路就是一致的．差别仅仅是在了你需要关注哪些KPA,产出物的要求上面，而这是可以通过裁剪来解决的．组织级定义的是通用过程，项目必须根据自己情况裁剪．
CMMI五级的境界问题
任何一个组织都会遇到层出不穷的新问题，关键是自我形成一套识别，分析和解决问题的过程．在五级企业已经形成PDCA或IDEAL的自我改进循环，达到持续自我改进的目的．组织是自适应的，组织是自我学习的．如果不具备这种自我诊断或学习的目的，那始终达不到五级的水平，到了五级就应该代表自己的问题自己能够解决水平，而这个问题不是老问题而是各种新问题，需要你遵循相关的过程或方法论去解决．
关于估算的准确性问题
对于估算不可能做到100%的准确，重点是将偏差控制在可以接受的范围．比如软件项目具体的软件需求没有开发完成时候是很难估计的很准确的，要估计准确就得花时间，这个时间其实就是在细化软件需求和功能．所以估算仍然需要进行成本效益分析，投入额外的工作量去估算以增加估算精度是否有必要．不管是类别法，专家法，三点法还是功能点法，没有谁好谁坏的问题，关键是哪个准确度高的问题．为何CMMI有时候强调功能点估算，重点就是使估算更依赖于过程而非个人．
关于岗位角色和分工的问题
如何划分角色岗位，分工要多细完全是一个平衡的问题．平衡的目标仍然是开发效率和质量．岗位分工越多则沟通成本越大，信息失真可能越大，需要更多的评审,Review和配置管理工作．但分工的好处是支持大规模作业，分工细化后降低了对单个角色需要具备的技能水平的依赖，分工细化后便于流水化作业．对于大型软件项目更需要强调这一点，需要的是专才而非通才，通才的结果可能就是样样懂但都不精通．
过程的重要性
在高度成熟的企业，过程是用信息化的手段来沉淀的，可以最大程度减少对人自觉性的依赖，并且减少监督的成本,提高执行力，最大程度的减少重复工作，避免带来数据积累、统计手工计算带来的问题。所以组织中的人更多的是依赖于过程或规程在做事情，而不是依赖于个人的经验在做事情．企业需要创新，但决定不需要人人都去创新．
如果企业始终处在头痛医头，脚痛医脚的状态．则完全是处于一种被动，挨打和救火的状态．最好的防守就是出击，最好的处事原则就是防患于未然．如果始终是善于识别问题的根源，去预防问题那就始终占据主动地位．
先进理念
先进的理念如果不能给公司带来真正的效益，那么说明理念本身的适应性有问题，或者说组织根本就不适合这个理念．你可以打着先进的幌子在短期内无收益，但不可能在中长期仍然无实际的收益．检验的重点就是成本效益，时间可以说明一切．存在即是合理的，完全否定项目实际而推广高屋建瓴的先进理论注定失败．
我们说CMMI实施更多应该是思想的转变，但要转变思想首先要能够看到对自我和组织有益处．望梅是止不了渴的，要宣传未来的饼有多大最好现在就能够让大家吃上一小口．
人的重要性
要做过程改进首先要回答的是为何要做过程改进的问题．只有自主，自发和组织自我需求驱动的改进才能够真正达到改进的目的．过程改进是一种氛围，是积累组织中的每个人不断创造价值的氛围．因此请尊重人，重视人，激励人，善用人，但又不能过度的依赖人．否则你依赖的是经验，而非过程．
文章来源于领测软件测试网 https://www.ltesting.net/
