近乎疯狂的加班

重回公司后,截止上周五(9.19)已经差不多连续加班了20工作日,外加几个周末。尤其是最后两周,几乎天天都是晚上10点左右回家,甚至是11~12点。尼玛,还天天下雨。

加班到这种节奏还是头一次,感觉每天都不够睡。

终于的终于,几个人辛苦的加班成果得到了客户的认可,而这成果就是一份相对可靠和完整的的项目估算和计划哦耶~~ 周末可以好好碎觉了(而且天气不错)。

一个包含了近40个sheet的估算表


一个近30页的项目计划


晚上11点,整层楼就只有我们那个角落灯还亮着



就我们而言,刚拿到这个任务的时候,着实有些为难,主要为两点:

1、估 算:因为对于估算,从来不曾做过(意味着没有太多的经验可以参考),往期的项目一般由客户提供估算。而且《估算表》中的任何一个数字都必须有确实可靠的来源(一般要求每个单元格都能体现为公式),不允许拍脑袋决定。

2、开发流程:虽然项目的性质和往期雷同,但是实质上还是有挺大程度上的区别,不能照搬照用,这就需要我们重新研究项目的开发流程。

为了提供一个可靠的估算,首先必须确定开发流程,然后才能根据开发流程的各个环节进行估算,(这些环节主要涉及到开发、测试及修bug)。

光是研究开发流程,我们就大大小小开了N个会议,并最终确定了三套大方案,其中每套方案中又会根据不同情况分出不同的解决方案。这样,实际上我们会根据不同的分支有不同的估算值,而客户会通过我们给的估算值选择其中一条。


估算公式的确定

时间估算主要分为三类:开发、测试和修复 Bug。

开发所需时间的确定:在刚开始的时候,我们完全想不清楚这个表要怎么设计,数字要从何而来。唯一能做的就是通过一些现有的工具分析出本项目涉及到的工作量。同时,由有资深开发经验的人员就各别功能模块进行试验性实施,最终结合往期项目的经验数据,加权得到一个相对可靠的生产率。

而不同的模块会不有同的难度,不能用同一个数字来说明所有模块的生产率,因此还需要乘上一个难度系数。所以最终我们的公式类似:

工作时间(人天) = 工作量 x Complexity x 生产率


测试时间:我们会考虑测试的方法(系统测试、回归测试)、不同测试方法的用例数量、准备时间、覆盖率等,具体数字则由测试经理给出。


修复 Bug 的时间:根据往期项目中测试和修复 Bug 的时间比例得到一个基准数字,然后再根据本项目的特殊性进行微调。比如一轮系统测试总共需要100人天,而开发人员修复此轮 Bug 花了90人天,那么我们认为这个比例就是90%。


噩梦的开始

确定了公式,理论上来说离最终的估算表已经不远了,但万万没想到,这只是一切噩梦的开始。按照我们的公式和经验值,很快就给出了《估算表》的原始版本,然后就是把这份《估算表》交由资深的PM、开发人员、测试人员一起讨论其中的数字。

可以说,每次的讨论都是一次批斗会,会上大家会激烈的讨论某个数字的正确性。有些时候,就因为你无法提供有效的说服力,导致你所提供的数字可能会被完全否定。批斗还并不是什么糟糕的事,The worst thing 是你之后要重新去调整有问题的数字。而这一调整牵涉的东西有些时候会摧毁你的意志,试想一下当你调整一个数字,哪怕是一个百分点,可能的结果就是你必须要去修改10几个sheet和几十页的文档,这个工作量就直接造成了我们的加班,所以你会知道我们有多不情愿去修改这些数字。

争议最大的就是 “修理 Bug 的时间”,我们小组一致认为修复某种类型的 Bug 所需要时间可能会是测试时间的3倍,也就是说如果一天测出一个Bug,那修改这个 Bug 的时间将是三天。

有些人会质疑我们为什么不使用公式去维护这些数字,这样一处改就自动处处改了。事实是,我们几乎每个数字都是公式,但仍旧有部分数据无法通过公式得到,因为那些数字需要开发人员通过经验去调整。

估算的流程


就这样,没日没夜疯狂了几周后,总算是得到了客户的认可,接下来就是等待客户的选择了。


文章索引

[隐 藏]

本站采用知识共享署名 3.0 中国大陆许可协议进行许可。 ©2014 Charley Box | 关于本站 | 浙ICP备13014059号