CMMI杂感谈[1]

　　敏捷和 CMMI是否矛盾问题
 
　　首先应该是考虑为何要实施CMMI的问题，如果仅仅是获取PassPort的话那很多后话都不用再谈．但真正的目的还是应该是降低软件开发生命周期的总成本，这个要用发展观点来看应该是一个中期或远期的考虑．如果实施了CMMI成本没有降低，那就只能说CMMI的实施是失败的不管是做了多数KPA,输出了多少文档，改进了多少过程．

　　对于敏捷或快速开发，如果过多的依赖是个人英雄主义，但势必和CMMI的理念是矛盾的．如果采用敏捷思路是提高开发效率，降低开发成本，考虑中长期软件开发的成本，那和CMMI的思路就是一致的．差别仅仅是在了你需要关注哪些KPA,产出物的要求上面，而这是可以通过裁剪来解决的．组织级定义的是通用过程，项目必须根据自己情况裁剪．
 
　　CMMI五级的境界问题
 
　　任何一个组织都会遇到层出不穷的新问题，关键是自我形成一套识别，分析和解决问题的过程．在五级企业已经形成PDCA或IDEAL的自我改进循环，达到持续自我改进的目的．组织是自适应的，组织是自我学习的．如果不具备这种自我诊断或学习的目的，那始终达不到五级的水平，到了五级就应该代表自己的问题自己能够解决水平，而这个问题不是老问题而是各种新问题，需要你遵循相关的过程或方法论去解决．
 
　　关于估算的准确性问题
 
　　对于估算不可能做到100%的准确，重点是将偏差控制在可以接受的范围．比如软件项目具体的软件需求没有开发完成时候是很难估计的很准确的，要估计准确就得花时间，这个时间其实就是在细化软件需求和功能．所以估算仍然需要进行成本效益分析，投入额外的工作量去估算以增加估算精度是否有必要．不管是类别法，专家法，三点法还是功能点法，没有谁好谁坏的问题，关键是哪个准确度高的问题．为何CMMI有时候强调功能点估算，重点就是使估算更依赖于过程而非个人．
 
　　关于岗位角色和分工的问题
 
　　如何划分角色岗位，分工要多细完全是一个平衡的问题．平衡的目标仍然是开发效率和质量．岗位分工越多则 沟通成本越大，信息失真可能越大，需要更多的评审,Review和 配置管理工作．但分工的好处是支持大规模作业，分工细化后降低了对单个角色需要具备的技能水平的依赖，分工细化后便于流水化作业．对于大型软件项目更需要强调这一点，需要的是专才而非通才，通才的结果可能就是样样懂但都不精通．
 
　　过程的重要性
 
　　在高度成熟的企业，过程是用 信息化的手段来沉淀的，可以最大程度减少对人自觉性的依赖，并且减少监督的成本,提高执行力，最大程度的减少重复工作，避免带来数据积累、统计手工计算带来的问题。所以组织中的人更多的是依赖于过程或规程在做事情，而不是依赖于个人的经验在做事情．企业需要创新，但决定不需要人人都去创新．
 
　　如果企业始终处在头痛医头，脚痛医脚的状态．则完全是处于一种被动，挨打和救火的状态．最好的防守就是出击，最好的处事原则就是防患于未然．如果始终是善于识别问题的根源，去预防问题那就始终占据主动地位．
 

[1]  [2]