β

参加CMMI三级复审会议(1.10-1.13)

人月神话的BLOG 10 阅读
本次选择了三个项目来参加远行科技CMMI三级的复审,一周时间完成整个复审评估。

就过程和结果而言,好的过程不一定导致的好的结果,但是糟糕的过程一定导致坏的或不稳定的结果。在一个人做简单的事情时候过程和方法步骤的作用很小,但是当面对一个复杂项目需要几十甚至上100人的团队合作的时候,过程的作用就越发重要。

业务目标和问题驱动的过程改进往往是最有效的,对于任何一个PA,任何一个活动你可能开始没有意识到一定要做,但是真正发生问题的再回头思考和复牌,你会发现都是一些过程点滴没有做好的原因导致。不要去迷信自己的经验,也不要迷信自己的记忆能力,而是应该把关键过程点都做到位。

任何过程数据和组织度量数据的积累,在估算的时候也无法代替项目经理和专家的经验判断,一个有技术积累,对团队深入了解的项目经理,往往才可能估算出准确的规模和工作量,能够清楚的评估项目进度实现的概率以及可能存在的风险。简单来说,如果一个年人员流失率在50%以上的团队,你会发现任何过程资产和经验积累都会失效,没有磨合过的稳定团队,再好的过程也难预测和控制。

做的好的仍然是需求,总体设计和测试几个关键点。做的不好的仍然是培训和评审,最大感觉还是体现在支持类过程没有做好,最终都会体现到大量变更和返工上面。

详细设计本身意义不大,我一直的观点还是源代码就是设计,应该多组织Code Review类评审会议,通过会议加强对编码规范,设计思想的知识传递。对于单元测试本身意义也不太大,但是没有完整的自动化的单元测试并不代表开发人员不需要做完整的功能自测。如果在过程管控里面发现开发环节出现大量的缺陷泄露,那么就一定要去考虑究竟是哪里出了问题,是开发人员本身技能问题,还是没有引入受控的单元测试或自测环节。

敏捷方法论的推广绝对不是逃避文档的接口,相反敏捷方法更加强调文档,只是这些文档应该都是真正有用的文档,而不是写出来没人看的问题。同时敏捷思路也尽量通过沟通来减少那种不必要的文档传递。

对于没有接触过CMMI标准规范体系的,多接触下没有任何坏处,至少你清楚了你自己企业进行研发过程改进,研发规范推进可以参考的一下方法,工具和思路。在诸多方法论体系里面,CMMI相对来说仍然是最完整和最系统的。CMMI体系强调过程,但是并没有否定人的作用,在推进CMMI时候一定要注意这点。
作者:人月神话的BLOG
原文地址:参加CMMI三级复审会议(1.10-1.13), 感谢原作者分享。

发表评论