J9九游最新备用网

  • <tr id='9l2e'><strong id='l16ogt'></strong> <small id='ga5z4m'></small><button id='on3f1'></button><li id='9i4k2'> <noscript id='gf93'><big id='otg4'></big><dt id='iu3w'></dt></noscript></li></tr> <ol id='q15yua'><option id='vyvby6'><table id='lk56'><blockquote id='nj81'> <tbody id='mfsc4z'></tbody></blockquote></table></option></ol><u id='ro5h7'></u><kbd id='wu8k'> <kbd id='1faj'></kbd></kbd>

    <code id='bydvg'><strong id='psa8j'></strong></code>

    <fieldset id='0dbglm'></fieldset>
          <span id='uqhe1e'></span>

              <ins id='xng8'></ins>
              <acronym id='l1z6lr'><em id='bz3v3'></em><td id='u4iexj'><div id='rfpw15'></div></td></acronym><address id='bxin'><big id='9sg1'><big id='v2sswy'></big><legend id='ylug'></legend></big></address>

              <i id='2h1wg'><div id='mnlb7p'><ins id='bzu45'></ins></div></i>
              <i id='ew4fl'></i>
            1. <dl id='8th9z'></dl>
              1. <blockquote id='1cu7p'><q id='warofg'><noscript id='fcwa'></noscript><dt id='ry9n'></dt></q></blockquote><noframes id='esmej'><i id='68rza'></i>

                软件估算的三个自带病毒

                软件估算的三个自带病毒

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

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

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

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

                CMMI认证 

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

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

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

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

                 病毒二:坚决不改的估算

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

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

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

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

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

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

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

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

                 

                文章来源丛斌博士


                点击关闭
                • CMMI认证客服

                  CMMI3认证客服

                  CMMI咨询

                  CMMI4认证