软件估算的三个自带病毒

软件估算的三个自带病毒

   软件项目失控的原因是从八十年代起就有许多人研究的课题。众多见仁见智的结论中有两点大家达成了共识:一是不稳定的需求,二是不合理的估算。

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

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

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

CMMI认证 

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

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

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

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

 病毒二:坚决不改的估算

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

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

   如果估算真是走走过场倒也伤害性有限,可实际上估算的目标对项目团队影响巨大。不按期交付在领导和客户眼里就意味着失败,不努力,没能力。所以加班成了常态,捷径成了习惯,隐患成了必然。
    携带这三种病毒的任何一种的估算方法都不可能有效,市场的压力和强势的客户是产生病毒的原因,真正破解确实不容易,这需要大环境发生一些根本变化。但也不代表我们什么也做不了,这里提供两个缓解的招数供参考。

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

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

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

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

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

 

文章来源丛斌博士


点击关闭
  • CMMI认证客服

    CMMI3认证客服

    CMMI咨询

    CMMI4认证