如何写好软件项目的工作计划-项目估算(三)

      上一节说到了项目假设,这是做估算的一个基础,你做的估算都要基于你假设的模型基础上才能进行。比如你平时上班坐公交大约要花1个小时刚好提前5-10分钟达到公司,但是有天你起晚了15分钟,以你的假设如果按照往常公交出行(假设选择这个方式),路上一个小时(估计的时间)是要迟到的,如果遇到堵车(预计的风险)那就是一定迟到,所以你选了打车上班。

   有很多书籍和前辈们总结了各式各样的估算方法,CMMI体系里面也有很多估算的方法,但这个并不是我要去解析的,毕竟这需要有一个数据收集的企业文化和一个稳定而效率的流程才能做到3级以上的成熟度。这是要把质量体系推给你的同事操心的事情,我们就把项目管理这块的工作搞清楚就好了,或者你的公司不推行CMMI,那我们花那个经理去研究这些估算的方法干什么呢?对吧。

(一)项目工期固定,你要学会科学地用数据说服你的领导

      有个项目经理一直都在跟我抱怨领导给他安排的工作都是政治任务,一个项目发下来就是截止到几月几号3个月的时间内一定要上线。然后为此他总是不停地忙于应付各种项目事务,然后加班到深夜,但是好像事情永远做不完,人员不给力掉链子,人力资源也不够,客户的态度也很强硬。领导回复了一句话:最好的资源都给你了,不能按期完成工作你自己要好好想办法。看到这里,你觉得这是他的领导在甩锅吗?我觉得不是,这位领导说的没错,我给了最好的人力资源,办公场地和调试设备,为什么你的工作没有很大的起色,还告诉我项目搞得东倒西歪。

       不得不说,他的做法很糟糕,也非常无奈,但是给我的第一感觉,他做事情没什么头绪。他实际想表达的意思:工期太短,资源紧张,项目为了能够按期交付所以要赶工,但是赶工造成了工作衔接出了问题,极大可能不能如期交付,但是客户不同意他项目延期。但是他的话真的没有和领导沟通清楚,于是我帮他项目情况又重新梳理了一遍。

       比较幸运的是,经过两周的忙碌,这位项目经理坚定的执行了我告诉他先把需求调研计划做出来并执行清楚,所以他的用户需求还是整理的比较完整,我们让项目组的同事花了3个小时整理成了1份有247个功能项的清单(这不是IFPUG或者COSMIC方法讲述的标准功能点)。好了,这个时候你可以使用 Delphi或者三点估算法,针对每个功能项估计一下完成撰写软件需求和设计、编码开发、测试工作需要的工作量。但是我要再强调一下,这个估算的依据是你的软件规模,也就是你要完成开发的功能点数量。

      但是有人问这不是很耗时间去估计吗?是的,非常耗费时间,我没有要你去这么干。但是你需要明白的一个核心问题是,一个功能项比如“用户管理”包括了增删改查的基本操作,那么另一个功能项“角色管理”如果也仅仅包括增删改查的基本操作,它们两个功能项估计使用的开发工作量应该接近一致的,绝对不可能用户管理的开发要3人天,然后角色管理的开发要5人天,如果这个模块要5人天肯定是包含了其它的功能点要开发。我再解释一下,规模越大需要的工作量就越大,这是个线性正比例的关系,不可能规模大结果估计的工作量反而小,你估算完了做成了一个反比例关系,那么你的估算就是有问题的。

      尽管你没有使用标准功能点估算的方法,但是这也不影响把需求拆分成列表,然后人工依据模块的规模去推测工作量,因为写文档的工程师,开发和测试工程师他们知道自己的工作效率,可以帮你完成这种人天的估计(根据经验做类比估计),他们背后的逻辑一定是基于客观的功能点的大小,而不是随便给个数字。记住这不是你一个人的战斗,他们都是你的伙伴 ,即使他们不一定将来会是你的项目成员,但是在前期也可以作为专家帮你估计。

     好了,当我们有了需求、设计、开发、测试的工作量的数据以后,我们做了2种软件生命周期的假设,一种是增量开发,一种是迭代开发。(为什么不用瀑布模型去假设?好吧,这个问题你可以去百度一下这个模型的优缺点)

     我们把247个功能项按照优先级分成了3个增量和3个迭代来完成,如果按照领导现在给的人力资源来计算理想工期。

     已经花掉了2周做需求调研,我们分情况讨论(我们按照一周7天都在工作不能休假的假设去推算,当然我们也不考虑风险的情况):

     增量模型:第一个增量80个功能项5个人要花3周完成,第二个增量97个功能项6个人要花4周完成,第三个增量70个功能项6个人要花3周完成,2人集成测试和6人修改缺陷需要1周,系统测试完需要1周时间,上线需要2周的时间,理想时间是 2+3+4+3+1+1+2=16周,预计超期22天。

      迭代模型:第一个迭代80个功能项5个开发和一个1测试要花4周完成,上线需要增加1名工程师,实施需要1名工程师;第二个迭代97个功能项6个开发要花5周和2个测试人员完成,第三个迭代70个功能项6个开发和2个测试要花4周完成。好了,看到了吧,3次上线需要的理想时间是 2+4+5+4=15周,预计超期15天,并增加2个工程师。

     于是我们把这个结果重新又报给了领导,当看到项目现在的情况,理论上就是一个完成不了的工作,加班好像也干不完。这个时候,干系人的态度发生了重大变化。领导和客户方的领导进行了电话沟通,把事情的情况跟对方进行了解释,你知道的,领导的沟通能力都是很强的,马上把客户那边的上层搞定。然后又给项目组增加了3个开发人员,要求工期可以延迟半个月。当听到这个结果,项目经理如释重负。他看了看我,我们都会心的一笑。

      下一节,还是谈估算,我想讲讲另外经历的项目,那是预算固定,没人觉得赚钱的项目,但是我和另一个厉害的项目经理一起做到不亏本的故事。

  

     

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

黄鹤的故乡

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值