这是一个创建于 1479 天前的主题，其中的信息可能已经有所发展或是发生改变。
一般来说，对完成一项开发任务需要消耗的时间，开发者总是会倾向于低估。
这方面，有什么好的经验方法吗？我觉得能够比较准确评估开发时间，确实是一项了不起的本领，用处也不小。
先说我总结出的一个规律：
开发人员在专注的时候，大概每小时可以编码 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
totoro52 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
GTim 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