这是一个创建于 1815 天前的主题，其中的信息可能已经有所发展或是发生改变。
一般来说，对完成一项开发任务需要消耗的时间，开发者总是会倾向于低估。
这方面，有什么好的经验方法吗？我觉得能够比较准确评估开发时间，确实是一项了不起的本领，用处也不小。
先说我总结出的一个规律：
开发人员在专注的时候，大概每小时可以编码 100 行。
这个规律是自己很多次实验+统计得到的，然后也由同事独立发现过。
也许，可以通过估计某个功能的所需代码行数，来评估开发时间(不考虑摸鱼这些损耗)？
这方面，有什么好的经验方法吗？我觉得能够比较准确评估开发时间，确实是一项了不起的本领，用处也不小。
先说我总结出的一个规律：
开发人员在专注的时候，大概每小时可以编码 100 行。
这个规律是自己很多次实验+统计得到的，然后也由同事独立发现过。
也许，可以通过估计某个功能的所需代码行数，来评估开发时间(不考虑摸鱼这些损耗)？
 | 1 gaorenhua 2020-10-22 15:23:11 +08:00  9 反正不管怎么估算，项目延期是肯定的。邪门了。 |
 | 2 kun368 2020-10-22 15:25:10 +08:00 坐标阿里，假设只有晚上有时间（白天确实也很忙，经常没时间写代码），估计出来的基本就差不多的 |
 | 3 rensuperk 2020-10-22 15:30:23 +08:00 1 估计时间*2，就是你完成的时间 |
 | 4 duanxianze 2020-10-22 15:31:13 +08:00 2 不管怎么估计也赶不上领导和产品经理改需求的速度 |
 | 5 qa2080639 2020-10-22 15:40:53 +08:00 误差在客户不断增改需求 |
 | 6 demo06 2020-10-22 15:50:18 +08:00 摸鱼时间怎么能不算呢? |
 | 7 zhuweiyou 2020-10-22 15:54:30 +08:00 不改需求 不延期的情况下 你自己估算一下 ,然后乘以 3 倍报出去 |
 | 8 boring3b 2020-10-22 15:55:57 +08:00 「开发人员在专注的时候，大概每小时可以编码 100 行。」 KPI 警告 |
 | 9 securityCoding 2020-10-22 15:56:17 +08:00 3 取决于你任务分解做的怎么样，任务分解做不好排期不可能准的。通常做事比较有条理性的人估算出来的排期比较靠谱 |
 | 10 295464512 2020-10-22 15:56:41 +08:00 这个只能看经验啊,我都是自己预估的实际时间乘以 2 报给客户的 |
 | 11 wangtian2020 2020-10-22 16:05:26 +08:00 一定超期，计划两倍 |
 | 12 xuanbg 2020-10-22 16:20:52 +08:00 我一向都估的很准。主要就两个方面，一个是实现多少功能，另一个是这些功能的复杂度。通常，都是一些 CRUD，工作量很好估算。 |
 | 13 Junh 2020-10-22 16:25:57 +08:00 via iPhone 我每次都估得很准，可能我把摸鱼的时间也算上了…… |
 | 14 unco020511 2020-10-22 16:28:09 +08:00 一般正常开发时间*2 差不多吧 |
 | 15 sillydaddy OP 看样子大家都是*2 或者*3，然后+摸鱼时间。哈哈。 |
 | 16 polyang 2020-10-22 17:56:22 +08:00 一般都是开发时间*1.5 或者*2，然后再加上摸鱼的时间。道理很简单，*1.5 或者*2 是为了应对突发情况（比如需求变更），加上摸鱼时间是因为人不可能一直都能全神贯注的写代码，就跟上课一样，总会有走神的时候。 |
 | 17 xingyuc 2020-10-22 18:09:16 +08:00 大概每小时可以编码 100 行。 平均每行多少字符？ 是否疯狂 { aaa },{ xxx } |
 | 18 jeeyong 2020-10-22 18:16:17 +08:00 估算的准确度完全取决于你的经验, 不只是编码经验, 还要包含和其他同事或部门沟通的效率及难易度. 说白了, 就是你以前做过类似的事情, 知道怎么办, 清楚过程, 于是你就能判断出接近实际情况的时间. 如果只是单一维度的事情, 就是你自己干就可以了, 不需要协作, 那就是你是否做过这个事情, 能否正确评估难度和工作量. 其他本质上都是靠自信和猜. |
 | 19 mepwang 2020-10-22 18:17:37 +08:00 via iPhone 同意，预估时间*2 |
 | 20 en20 2020-10-22 18:21:31 +08:00 via iPhone @xingyuc 这个当然分事情，如果写 css，一天 1000 行没问题，写逻辑性很强的东西 100 到 150 差不多 |
 | 21 sockball07 2020-10-22 21:33:46 +08:00 预估时间*2 的 产品不给你们压的？ 9 月开始已经进入满负荷状态... |
 | 22 iwh718 2020-10-23 00:15:41 +08:00 via iPhone 计划两倍 |
 | 23 xy90321 2020-10-23 01:42:27 +08:00 via iPhone 1 难道做了那么久项目，什么复杂度的功能维护和新作分别多少生产性心里还没数么？ 换句话说如果是没接触过的领域，那就做两个 PoC 看看生产性啊… 基本上手上的传统 WEB 项目维护的话，看一眼需求，核对下 ER 图，然后数数画面项目数量就能估得八九不离十。 吃不准的部分要么 PoC 看生产性要么根据经验放大个 30-50%再说。 |
 | 24 ericgui 2020-10-23 01:44:19 +08:00 via iPhone x 1.5 |
 | 26 liyaoo 2020-10-23 08:36:20 +08:00 via Android  1 霍夫斯塔特定律：实际花费的时间总是比预期的要长，即便你考虑到了本条定律。 |
 | 27 MIUIOS 2020-10-23 08:45:37 +08:00 只有实习生才会一整天百分百的敲代码，老司机大部分时间都在摸鱼，一个需求下来一小时就搞定的事 起码也得两天 |
 | 28 chenluo0429 2020-10-23 09:00:29 +08:00 先进行任务分解，在实际预估的基础上，简单功能+1-2 天，复杂功能时间翻倍。最后再在总时间上加上 20%-50%的缓冲时间就可以报上去了 |
 | 29 summersnow521 2020-10-23 09:08:54 +08:00 一般看经验吧，完全不了解的技术一般先根据情况考虑花半天或更久调研下 |
 | 30 Visitor233 2020-10-23 09:24:34 +08:00 一个微信特约商户对接的 API 接口，我估了 20 天（ 10 天赶上了国庆），接口对上了，但后续的逻辑代码大大超出预期，任务延期了。 |
 | 31 guxingke 2020-10-23 10:25:39 +08:00 1 > 如果你不能准确的估算时间, 说明你任务分解的粒度还不够细。 从我的经验来看，合适的子任务耗时是半个工作日 |
 | 32 crazypig14 2020-10-23 10:29:38 +08:00 楼上竟然没人提到过现实项目中最常用的倒推大法 |
 | 33 jtwor 2020-10-23 10:32:20 +08:00 一天 200 有效代码已经不错了。 |
 | 34 yemoluo 2020-10-23 10:35:14 +08:00 以前我经常会估的比较准，大概会多出 1-2 天。突然有一次，我估了 1 个月，结果需求下来，大概是一个半月，老板倒好，直接砍成 18 天 |
 | 35 ghjacky 2020-10-23 10:39:19 +08:00 额 这边一般沟通排期全靠直觉，都没去想过设计、文档、编码各需要多长时间，自己直觉的时间再适当放宽个 50%，反正目前为止没延期过，可能跟产品没强行施压，排期灵活也有关 |
 | 36 zlu1123 2020-10-23 10:42:30 +08:00 我每次都估不准，估计是人头外包还没练出来，我再接再厉 |
 | 37 HenryWang0723 2020-10-23 10:47:57 +08:00 反正都不准，不然企业怎么会花钱搞专业的项目管理 |
 | 38 misdake 2020-10-23 10:52:49 +08:00 "（开发软件时）前 90%的代码要花费 90%的开发时间，剩余的 10%的代码要再花费 90%的开发时间。" |
 | 39 zerofancy 2020-10-23 13:23:50 +08:00 安卓，等 iOS 的估计完看心情加减 1 天 |
 | 40 westoy 2020-10-23 13:31:29 +08:00 做外包的话， 大概是预估 2 ～ 3 倍时间， 实际也基本是常常卡着交付点做好的 |
 | 41 tony1890 2020-10-23 13:32:27 +08:00 倾向于多估。 我是前端，ui 稍微发挥一下、产品经理稍微改一下我这边工作量就不一样。 特别是某些我不熟悉的功能。能顺利找到 api 或者插件还好。不然就很难了。如果能使用组件默认样式 /功能还好，否则…… 所以，多估一点好。 |
 | 42 binux 2020-10-23 13:33:20 +08:00 via Android 我从来不估开发用时，我都是在估计别人觉得要多少时间。 以免发觉我做太快，不方便划水。 |
 | 43 libook 2020-10-23 13:51:29 +08:00 1 程序员的产能是难以由硬性指标衡量的，之前看过一个漫画，就是以代码行数来评估绩效，结果 IT 和程序员开始进行对抗，程序员写了各种工具来处理源代码生成行数更多的代码，IT 写了各种工具来消化这些无意义的行数来提高绩效精度，最终浪费了大量产能。 建议以任务作为单位进行工作量评估。我觉得和投篮一样，凭借不断尝试、反馈、修正来成为一种感性经验。 敏捷方法论里有一个 Story Point 的方法论也可以借鉴，可以衡量任务难度、个人能力、项目健康程度等。 规划工作时间分配工作任务是有挺多技巧的，关键的一点是重要任务不要填满工作时长，留出一定比例的工作时长给不那么重要的任务，这样当重要任务遇到突发情况需要延长的时候，挤掉不重要的任务就不会对整体项目计划和关键结果造成太大影响。 |
| 44 sillydaddy OP @libook 嗯。最后一条建议确实很好。 |
 | 45 liujialongstar 2020-10-23 17:28:33 +08:00 3 天写了 800 多行代码的我, 是不是很菜 |
| 46 sillydaddy OP @liujialongstar 一天将近 300 行，非常不错了，相当于有 3 个小时都是专注的，再加上需求沟通+设计+调 bug 的时间。。感觉很难得了。 当然这是指这 800 行，应该是新写的，带有一定的结构和逻辑的。如果是重复性的代码，比如代码内部重复或者是重复别人写的，那就另说了。。 |
Select Language