CMMI2.0软件估算

7-CMMI2.0软件估算

软件项目失控的原因是从八十年代起就有许多人研究的课题。众多见仁见智的结论中有两点大家达成了共识：

一是不稳定的需求，二是不合理的估算。

不稳定的需求我们往往无可奈何，属于不可控因素，那么不合理的估算从何而来？我们经常见到的是，过于乐观的估算带来了不合理的项目进度目标，结果自然是逼着项目各种走捷径，从头到尾都处于救火模式，交付有各种埋雷的产品也是意料之中。

四十年过去了，各种软件估算方法层出不穷，然而软件估算现状并无大的改观，依然困扰着软件团队。CMMI2.0已经把估算升级为一个独立的实践域，欧美敏捷圈子一些人则直接喊出“放弃估算”。两种截然的态度昭然！

估算怎么这么难？是软件估算的三个自带病毒让其深陷泥潭。

软件估算的三个自带病毒

病毒一：估算发生在错误的时机、由错误的人决定

估算一般都是项目初期的活动，这往往也是我们对项目各种信息了解最少的阶段。需求不清晰，解决方案不确定，风险未识别，估算自然不靠谱。

谁来做估算？正常情况下应该是干活的人，估计大部分CMMI组织的估算流程也是这么写。但真正做估算的人往往是客户、市场部、老板。技术人员只是走个估算流程，让交付时间合法的同时顺便给自己挖了个大坑。当然，许多组织也会做个像模像样的可行性分析，虽然，我还没有看到一个说No的。

错误时机、错误的人做的估算只是自己挖坑自己跳的游戏。

病毒二：坚决不改的估算

初始估算不靠谱可以理解，可是项目执行中发现它是错的还是不改就不能原谅了。后墙不倒是我常听到的一句话，完全脱离实际的估算已经失去了意义。

病毒三：用不靠谱的估算考核团队

如果估算真是走走过场倒也伤害性有限，可实际上估算的目标对项目团队影响巨大。不按期交付在领导和客户眼里就意味着失败，不努力，没能力。所以加班成了常态，捷径成了习惯，隐患成了必然。

携带这三种病毒的任何一种的估算方法都不可能有效，市场的压力和强势的客户是产生病毒的原因，真正破解确实不容易，这需要大环境发生一些根本变化。但也不代表我们什么也做不了，这里提供两个缓解的招数供参考。

招数一：客户/老板4选3，团队4选一

估算不外乎考虑四个选项：进度、成本、实现需求范围、质量要求。可以先让客户或老板选择其中任何三项，但把剩下一个控制权留给团队。马不吃草还要快跑的想法实在有点想太多。

缓解招数二：轻量，做中学，做中估，管控风险

哪怕不能改变强加的估算结果，团队还是应该实事求是的做估算，把它当做风险识别管控的重要手段，如果估计值和目标差别大，需要尽早想办法, Do more with less。

估算要轻量，just enough，远粗近细。团队对项目的了解随着时间不断递增，这些新的知识要用在项目管理中。敏捷大大缩短了学习反馈周期，重估算是每个迭代的选项。但计划驱动模式也可以在一些点重新评估项目，如，解决方案的确定，每个重要的里程碑节点。

管控风险有可能意味着项目创新，也可能意味着放弃一些影响不大的活动。多年前我提过一条建议，国内绝大多数软件组织都需要一个“紧急项目管理流程”，这个流程绝不需要覆盖CMMI的几百条实践，三级的组织并不一定所有项目都按三级来管理。

合理假设也是CMMI对估算的要求之一，无法根治，起码理解约束条件，这也是我写这篇文章的意义。

文章来源：公众号《老丛讲桌》

CMMI认证评估查询中文网，服务中国CMMI认证企业，数据实时同步全中文翻译CMMI认证评估结果查询，提供权威认证评估授权机构，帮助企业培训学习软件成熟度V2.0模型知识及资料下载。收集各地补贴政策，专业CMMI3级4级5级认证评估咨询办理。

文章源于网络，如有侵权或者不当，请告知删除

CMMI认证中文网