大家都知道“估不准原理”吗？

[daokedao]

就是每次估计项目开发需要的时间，都不准，有时能相差千里。
讲真，大家怎么估计项目所需时间？

[SpiderXiantang]

遇事不决 量子力学

[kaneg]

经验很重要。每个项目完成后都要回顾对比估算时间和实际花费时间，这样次数多了，误差就会越来越小。排除一些奇葩项目有不可预知的变更，按照 2/8 原则，起码大多数项目的估算还是可以掌控的。

[hugo54]

@SpiderXiantang 那没事了

[icenya]

@licheeve
完成项目是小事情欸...
如果是炒股票肯定就会有蝴蝶效应啦 x
（就好像知道彩票一等奖号码一样 x

[wnpllrzodiac]

不放余量的？

[yuruizhe]

因为开发工程中总有千奇百怪的新坑，谁也说不准多久能解决

[daysv]

还好吧， 我估时间一般都比较准， 但是产品喜欢在开发了一半的时候搞事情。

[falconeye]

按时间倒排，只保留本期的核心功能，确定搞不完的就放到下一期。
量小了，评估就能相对准确；有 deadline 就能确保核心功能和优先级；目标是能持续交付和快速迭代。

[liuzhaowei55]

@xmumiffy 我觉得乘 PI 就可以了，开发人员估时间的时候太太谦虚了。

[cnrting]

@xmumiffy 所以到底是听领导的还是听你的

[tiedan]

个人而言，比较新的任务类型前几次估不准很正常，但是做了十次八次的几乎不存在估不准的情况。

[joshuacavell]

遇事不决,量子力学.

[zlhsvc]

一般往大了说 2 倍时间是保底，因为你不知道中间会出什么幺儿子

[wangkun025]

人的问题。

[ayase252]

需求明确 * 2
需求一看就不靠谱 * 4

[no1xsyzy]

@falconeye 这个涉及到管理学领域的三难问题：时间限制（ Time ）、预算限制（ Budget ）、成果要求（ Specification ）三者很大程度上相关，但只要降低一个要求通常能够符合
（当然，人月神话否定了软件工程领域放开预算限制的作用，但影响不大，反正传统上就比较少地采用加预算）
似乎一个实例就是 Linux 分两条发布，稳定内核放弃成果要求，不一定要把所有这段时间内新添加的功能加进去，而最新内核没有固定发布时间。

[qianc1990]

我知道 海森堡测不准原理： 无法同时测得粒子的位置和速度.

[MaverickLee]

我知道买买提测不准原理：你无法同时得知一个 msl 携带的炸药量和他要引爆的地点。

[CodingNaux]

领导恨不得把迭代周期排的满满，不给人留一点 buffer
所以得多估 = =

[CodingNaux]

或者是这个需求匆忙进入迭代，之前没好好评审，没让开发做技术调研之类。赶鸭子上架