开发时间估计

开发时间估计

项目管理中,项目任务时间估计是其中一个重要的环节。各种管理员人都觉得时间估计很重要,都希望时间估计能准确一些,但是,事实却并不如此。事实上,会下面这样的结果。

目前状态 完成进展 剩余任务估计
任务刚被分配,还没有做调查 完成0% 大约2周
完成需求分析和调查,攻克了难点 完成50% 大约2周多一点
我几乎做完了。只有出了点我事先没有想到的岔子。
不过,我已找到解决方法了。只是还需要一些时间
完成90% 大约2周多一点
我全部做完了,只是还要写文档,做Code Review,
单元测试和错误处理
完成99% 还需要2周

呵呵,这是怪我们的项目管理的方法论呢?还是怪我们太过草率的程序员呢?


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (8 人打了分,平均分: 4.25 )
Loading...

开发时间估计》的相关评论

  1. 所以有人说程序员估计的时间和实际时间的关系大约是:实际时间=程序员估计的时间*2+10%

  2. 开始阶段,程序员只会估计自己的有效编码时间. 之后才会考虑测试时间,重构时间.最后会算上改bug时间. 嗯, 剩余时间总是2个周

  3. 《软件随想录》里面joel的方法不错,就是记录自己预期的时间和完成任务的时间,一步一步慢慢逼近

  4. 新程序员容易乐观,公司、领导也不允许把测试、技术难题、协作中互相等待的时间计入预计

  5. sunbett :
    所以有人说程序员估计的时间和实际时间的关系大约是:实际时间=程序员估计的时间*2+10%

    你是说
    实际时间=程序员估计的时间*2.1 吗?

  6. 有时程序员被要求估计时间时甚至都还没来得及去看需求说明,可能只能看到一个空洞的名字而已,连做什么、怎么做、可行性都不清楚,如何准确地估计时间?当程序员对具体情况有所了解之后,有多少领导还会在这时去倾听或询问?就算听了,如何面对延期?如果这时只是责怪程序员一开始估计得太离谱,又有多少人这时会主动要求延期呢。
    估计时间是最没有意义的事情,因为这不能给具体的开发提供指导——该做的总归绕不过去,能绕的程序员也大都会绕过去,毕竟大家都不喜欢加班。

  7. 百度黑板报 :

    wavesun :

    sunbett :
    所以有人说程序员估计的时间和实际时间的关系大约是:实际时间=程序员估计的时间*2+10%

    你是说
    实际时间=程序员估计的时间*2.1 吗?

    哈哈 这个问题 我也觉得纳闷~

    有没有可能是:实际时间=程序员估计的时间*2.2

  8. 我倒是觉得,估计一件将要做的事会耗费的时间,其准确率取决于工作内容的重复程度。
    里面的东西重复性越高,估计的时间也会越准。当你完全做的是同一类事情的时候,那你的估计可能会百分之百准确,甚至由于熟练度的问题,完成的速度可能还会更快。

    但在面对一个很大程度上的新事物时,不可能有人准确的估计时间。这时候你只能确保时间估计的数量级可靠。其依据是丰富的阅历和知识中类似的技术跨度所需要的大概时间。

    遗憾地是,时间估计几乎成了项目管理方法论中的一个顽疾,总是有人把事情想得太简单。但实际上,如果每一步所估计的时间都几乎完全不准的话,那么时间的预估就没有了任何意义。不管你将这部分时间如何记录在什么文档上,它都不可能起到了你所希望的任何作用,它们只能是一个有误导性的、无说明性的、造假的数字。

  9. sunbett :
    所以有人说程序员估计的时间和实际时间的关系大约是:实际时间=程序员估计的时间*2+10%

    我估计过一个时间,本来是计划将近两个月,因为我并不知道会遇到什么问题。结果被砍掉几乎一半时间,变成一个月了。结果是我们也按时完成了(不包括测试,因为这个项目是改造旧的,只要在开发时自己测试下就基本没问题)

发表评论

电子邮件地址不会被公开。 必填项已用*标注