本文主要是介绍CMMI，想说爱你不容易，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在公司感受CMMI有一段时间了，最初的时候我跟自己说，不要过分迷信Agile，CMMI毕竟卡耐基梅隆这种级别的大学里想出来的东西呢。而且国内各个公司都推CMMI必然有其道理，存在即合理的么。（虽然也有大批的人鄙视CMMI）
结果事实证明我又犯了那结果退出条件的错误，毕竟广泛流行和正确真是没有什么必然联系，合理不一定是合乎正确的道理，也许只是碰巧符合了人性弱点的客观规律。不然谁来给我解释瀑布模型和“奎尔特”现象？几个月的CMMI并没让我感觉到他的魅力。从我的角度来看还不如在以前的公司开发的时候有自信。总感觉没“准”。
对CMMI的信任，导致我忘了一个基本的问题。忘记了确认任务完成的标准是什么。（当然这里面也有我被这份工作冲昏头脑的原因在里面）本以为这是一个充满方向感的开发，可是在开发的过程中完全没有这种感觉。本以为可以轻易得感觉到完成的进度，结果却还是凭借经验去揣度这种原始的手法。本来编码就没实质的质量衡量标准准和保证的情况下，一遍遍得催促让人充满压力和恐慌。面对文档工作只能无奈。当测试降临的时候只有一拖再拖。（当然最后测试才介入这本身就有问题）一个个的紧逼让人着急，最后CMMMI给我留下的感觉就是四个字:"强人所难"。难道他们真的以为压力可以产生动力，着急能把事情做好吗？如果着急就能把事情做好，中国就没有贪官了，你去看大公司里为什么要制造一个轻松的工作环境？因为心理压力过大往往会把事情搞砸。软件开发是一个脑力劳动，不是一个体力劳动，一次次着急导致将就，一次次的将就就是一次次的隐患，到最后你靠什么保证质量？靠所谓的经验和最后的测试和回归？唉，真不知道人们的自信是哪里来的。往往的到最后只能靠某些人的长袖善舞和舌灿莲花。当然你还别说，很多时候这就够了。
这一切更坚定了我倒向Agile的决心，可是我的优点就是喜欢翻过来想，如果这个项目使用的是Agile就会好吗？说实话不一定。因为，发生的这些问题并没有触及到CMMI的理论缺陷，更多是实践有问题。没有建立起度量的标准和完成标准，没有采用合理的构建策略，没有质量保证的手段，没有进行足够的交流，没有足够精确的需求。同样的一批人，让他们去采用敏捷有什么办法保证不只学个皮毛？说实话，国人流于表面而轻易下结论的恶习不是一两个美好的愿望就能改变的。很可能是只学个皮毛，到时候Agile会不会让他们变成无序的混乱开发？到时候再来一个Agile无效？
算了，不是公司管理层，考虑这个暂时也于事无补。可是明天压力还是会存在，这种无形的压力什么时候是个头啊。唉，CMMI真是想说爱你不容易。
这篇关于CMMI，想说爱你不容易的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
