开发人员都是怎样估算开发所需时间的？误差是多少呢？

[sillydaddy]

一般来说，对完成一项开发任务需要消耗的时间，开发者总是会倾向于低估。

这方面，有什么好的经验方法吗？我觉得能够比较准确评估开发时间，确实是一项了不起的本领，用处也不小。

先说我总结出的一个规律：
开发人员在专注的时候，大概每小时可以编码 100 行。

这个规律是自己很多次实验+统计得到的，然后也由同事独立发现过。
也许，可以通过估计某个功能的所需代码行数，来评估开发时间(不考虑摸鱼这些损耗)？

[gaorenhua]

反正不管怎么估算，项目延期是肯定的。邪门了。

[kun368]

坐标阿里，假设只有晚上有时间（白天确实也很忙，经常没时间写代码），估计出来的基本就差不多的

[rensuperk]

估计时间*2，就是你完成的时间

[duanxianze]

不管怎么估计也赶不上领导和产品经理改需求的速度

[qa2080639]

误差在客户不断增改需求

[demo06]

摸鱼时间怎么能不算呢?

[zhuweiyou]

不改需求 不延期的情况下 你自己估算一下 ,然后乘以 3 倍报出去

[boring3b]

「开发人员在专注的时候，大概每小时可以编码 100 行。」 KPI 警告⚠️

[securityCoding]

取决于你任务分解做的怎么样，任务分解做不好排期不可能准的。通常做事比较有条理性的人估算出来的排期比较靠谱

[295464512]

这个只能看经验啊,我都是自己预估的实际时间乘以 2 报给客户的

[wangtian2020]

一定超期，计划两倍

[xuanbg]

我一向都估的很准。主要就两个方面，一个是实现多少功能，另一个是这些功能的复杂度。通常，都是一些 CRUD，工作量很好估算。

[Junh]

我每次都估得很准，可能我把摸鱼的时间也算上了……

[unco020511]

一般正常开发时间*2 差不多吧

[sillydaddy]

看样子大家都是*2 或者*3，然后+摸鱼时间。哈哈。

[polyang]

一般都是开发时间*1.5 或者*2，然后再加上摸鱼的时间。道理很简单，*1.5 或者*2 是为了应对突发情况（比如需求变更），加上摸鱼时间是因为人不可能一直都能全神贯注的写代码，就跟上课一样，总会有走神的时候。

[xingyuc]

大概每小时可以编码 100 行。
平均每行多少字符？
是否疯狂
{
aaa
},{
xxx
}

[jeeyong]

估算的准确度完全取决于你的经验, 不只是编码经验, 还要包含和其他同事或部门沟通的效率及难易度.
说白了, 就是你以前做过类似的事情, 知道怎么办, 清楚过程, 于是你就能判断出接近实际情况的时间.
如果只是单一维度的事情, 就是你自己干就可以了, 不需要协作, 那就是你是否做过这个事情, 能否正确评估难度和工作量.
其他本质上都是靠自信和猜.

[mepwang]

同意，预估时间*2

[en20]

@xingyuc 这个当然分事情，如果写 css，一天 1000 行没问题，写逻辑性很强的东西 100 到 150 差不多

[sockball07]

预估时间*2 的 产品不给你们压的？ 9 月开始已经进入满负荷状态...

[iwh718]

计划两倍

[xy90321]

难道做了那么久项目，什么复杂度的功能维护和新作分别多少生产性心里还没数么？

换句话说如果是没接触过的领域，那就做两个 PoC 看看生产性啊…

基本上手上的传统 WEB 项目维护的话，看一眼需求，核对下 ER 图，然后数数画面项目数量就能估得八九不离十。

吃不准的部分要么 PoC 看生产性要么根据经验放大个 30-50%再说。

[ericgui]

x 1.5

[kaiki]

@rensuperk 客户容易加需求就*3，加需求的时候还加钱就*4，平时喜欢一拍脑袋就来点建议得*N

[liyaoo]

霍夫斯塔特定律：实际花费的时间总是比预期的要长，即便你考虑到了本条定律。

[totoro52]

只有实习生才会一整天百分百的敲代码，老司机大部分时间都在摸鱼，一个需求下来一小时就搞定的事 起码也得两天

[chenluo0429]

先进行任务分解，在实际预估的基础上，简单功能+1-2 天，复杂功能时间翻倍。最后再在总时间上加上 20%-50%的缓冲时间就可以报上去了

[summersnow521]

一般看经验吧，完全不了解的技术一般先根据情况考虑花半天或更久调研下

[Visitor233]

一个微信特约商户对接的 API 接口，我估了 20 天（ 10 天赶上了国庆），接口对上了，但后续的逻辑代码大大超出预期，任务延期了。

[guxingke]

> 如果你不能准确的估算时间, 说明你任务分解的粒度还不够细。

从我的经验来看，合适的子任务耗时是半个工作日

[crazypig14]

楼上竟然没人提到过现实项目中最常用的倒推大法

[jtwor]

一天 200 有效代码已经不错了。

[GTim]

以前我经常会估的比较准，大概会多出 1-2 天。突然有一次，我估了 1 个月，结果需求下来，大概是一个半月，老板倒好，直接砍成 18 天

[ghjacky]

额 这边一般沟通排期全靠直觉，都没去想过设计、文档、编码各需要多长时间，自己直觉的时间再适当放宽个 50%，反正目前为止没延期过，可能跟产品没强行施压，排期灵活也有关

[zlu1123]

我每次都估不准，估计是人头外包还没练出来，我再接再厉

[HenryWang0723]

反正都不准，不然企业怎么会花钱搞专业的项目管理

[misdake]

"（开发软件时）前 90%的代码要花费 90%的开发时间，剩余的 10%的代码要再花费 90%的开发时间。"

[zerofancy]

安卓，等 iOS 的估计完看心情加减 1 天

[westoy]

做外包的话， 大概是预估 2 ～ 3 倍时间， 实际也基本是常常卡着交付点做好的

[tony1890]

倾向于多估。
我是前端，ui 稍微发挥一下、产品经理稍微改一下我这边工作量就不一样。
特别是某些我不熟悉的功能。能顺利找到 api 或者插件还好。不然就很难了。如果能使用组件默认样式 /功能还好，否则……

所以，多估一点好。

[binux]

我从来不估开发用时，我都是在估计别人觉得要多少时间。
以免发觉我做太快，不方便划水。

[libook]

程序员的产能是难以由硬性指标衡量的，之前看过一个漫画，就是以代码行数来评估绩效，结果 IT 和程序员开始进行对抗，程序员写了各种工具来处理源代码生成行数更多的代码，IT 写了各种工具来消化这些无意义的行数来提高绩效精度，最终浪费了大量产能。

建议以任务作为单位进行工作量评估。我觉得和投篮一样，凭借不断尝试、反馈、修正来成为一种感性经验。
敏捷方法论里有一个 Story Point 的方法论也可以借鉴，可以衡量任务难度、个人能力、项目健康程度等。

规划工作时间分配工作任务是有挺多技巧的，关键的一点是重要任务不要填满工作时长，留出一定比例的工作时长给不那么重要的任务，这样当重要任务遇到突发情况需要延长的时候，挤掉不重要的任务就不会对整体项目计划和关键结果造成太大影响。

[sillydaddy]

@libook 嗯。最后一条建议确实很好。

[liujialongstar]

3 天写了 800 多行代码的我, 是不是很菜

[sillydaddy]

@liujialongstar 一天将近 300 行，非常不错了，相当于有 3 个小时都是专注的，再加上需求沟通+设计+调 bug 的时间。。感觉很难得了。
当然这是指这 800 行，应该是新写的，带有一定的结构和逻辑的。如果是重复性的代码，比如代码内部重复或者是重复别人写的，那就另说了。。