这是一个创建于 3356 天前的主题，其中的信息可能已经有所发展或是发生改变。
估了这么多次,每次也没把握估的比较准
客观来讲,这不是一个简单的工作,因为一般着手做的情况下,会出现各种各样的没有预料到的问题
当然,估算时间会给到自己一个时间缓冲
客观来讲,这不是一个简单的工作,因为一般着手做的情况下,会出现各种各样的没有预料到的问题
当然,估算时间会给到自己一个时间缓冲
 | 1 kaner 2016-08-13 12:09:39 +08:00 via iPhone 经验 |
 | 2 SeanChense 2016-08-13 12:13:11 +08:00  1 取决于你对需求的理解，不仅仅局限于对设计图而是从设计图背后展开一系列的动作，以及你对自身能力的评估。 个人觉得能估好需要非同一般的经验，估不好那你就报你估的量 +15%或者其他你觉得应该的比例。 |
 | 3 Felldeadbird 2016-08-13 12:13:36 +08:00 via iPhone 心中的开发时间乘以 3.14 … |
| 4 SeanChense 2016-08-13 12:14:40 +08:00 @Felldeadbird 1.618 或者 1.732 差不多， 3.14 估计这单就黄了。 |
 | 5 shaozhengmao 2016-08-13 12:59:33 +08:00 我见过这么估工作量的： 根据需求估算实现总的代码行数，除以自己每天代码量。 当时我是听的目瞪口呆，不知道 v 友们怎么看 |
 | 6 billwang 2016-08-13 13:42:25 +08:00 自己根据经验估算一个时间，然后乘以 2. |
 | 7 ipconfiger 2016-08-13 14:16:04 +08:00 3 搭建项目基础架构所需时间, 经验丰富积累深厚的程序员这里花费的时间较少(因为有大量的可复用的脚手架代码和自己积累的各种库), 所以少则 1 天, 多则 N 天, 你得根据对自己的了解来评估 N 是几, 如果你对自己都不了解的话, 就用上一个项目来类比. 然后是功能开发所需的时间, 根据功能的复杂程度分分级别, 用小时作为粒度, 简单的 1 个小时, 中等的 3 个小时, 复杂的 8 个小时, 特别是简单任务, 很多都是劳动力堆集型的, 这类任务再牛逼的程序员也没法比一个刚够用的程序员快多少, 所以一个牛逼的程序员可能把复杂任务从 8 个小时减少到 1 个小时, 但是没法把简单任务从 1 小时缩短到 40 分钟. 所以还是按照标准来预估, 这个时间作为标准工作量预估. 接下来需要评估自己的工作时间, 不要按照每天 8 小时算, 要按照每天你能够实际工作的时候来算, 比如要排除掉发呆,打望, 看美女, 抽烟, 出门买水, 开会等各种干扰后的时间, 实际上在公司上班的程序员应该不足 5 小时. 标准工作量除以每天实际工作时间, 就是项目开发需要的时间了. 在这个基础上每周加上 2 小时的会议沟通时间,再预留下一周的富裕用于意外情况的冗余. 这样子作为内部项目的评估就相对靠谱了. 如果是外包项目的话, 将上述时间乘以 2 如果是外快项目的话, 评估工作时间要用自己的业余时间来估计, 比如每天晚上有 3 个小时, 就按照 1.5 小时来评估, 最后计算的时间再乘以 2 即可. 以上的评估方法只适合没有任何技术挑战的项目. 如果有技术挑战, 那是另外一种算法了, 但是外包一般都没啥技术含量的 |
 | 8 SuooL 2016-08-13 14:23:49 +08:00 我的底线是不少于最多的时间, 最多的时间就是根据经验得出预估的时间然后乘以 1.5 这样子提前做完了可以做接下来的任务, 同时最大可能避免因为估时太少而把自己甩到加班的坑里. |
 | 9 BMW 2016-08-13 14:30:53 +08:00 先估算代码行数，再估算字符，在看每天平均代码字符数。 |
 | 10 seeker 2016-08-13 15:08:50 +08:00 更重要的是随时能砍掉未完成需求而不会对代码伤筋动骨以便按时发布 ;) |
 | 11 zhangfan 2016-08-13 15:58:43 +08:00 *3 这样比较好，老司机都这么说。 |
 | 12 caixiexin 2016-08-13 17:34:38 +08:00 via Android 估算完，有做过的*2 ，没做过的*4 交上去后一般领导会除以 2=_= |
 | 13 poke707 2016-08-14 18:52:48 +08:00 via Android 人月神话是研发估的 * 3 ， QA 再 * 3 吧 |
 | 14 zhouzhe8013 nbsp; 2016-08-15 09:28:57 +08:00 先分解工作吧,分好开发的顺序,模块,功能点 然后按一个固定的时间定好里程碑,不要太久,最长不超过三个月 最后按里程碑倒排工作计划,以周为单位 常见的作坊式开发基本都这样吧. |
 | 15 BenX 2016-08-19 15:32:00 +08:00 relaxrelaxrelax |
 | 16 andyL 2016-08-19 16:46:24 +08:00 目前我们小组迭代的时候在用的: 由组长把需求看详细，需求评审的时候把上游交付的东西严格把关 组长把功能和模块划分好 组长对列出来的功能以组长自己的经验水平估时间，单位用人天 因为要分给组员来做，所以每个功能的时间可以乘以一个系数 1.1~1.5 就够了 整体提交测试，按测试的时间走就行了，改改 bug 以周来作为小周期，这样的好处就是，你可以给组员说，争取把每周的任务前置在周一周二周三，这样周四周五就会轻松一点，人也很舒服 比如： 功能列表上总共的工作量估出来 40 个人天，参与开发的共 5 个人， 那么平均是 8 人天左右的工作量 组长可以安排为两周开发时间，（组长要顶住领导和其他部门的压力的前提下），提前一天整体提交测试 叫小组成员来选功能，原则是每人凑够 8 人天左右的工作量 接下来就可以开始开发了 组长的职责就很重要了，一定要有丰富的工程经验的人，一定要负责做好代码审查，也要对组员的提交的代码提出优化意见 这样做了谁会不服你呢 其实大部分人都能提前一点完成，这样个人留出一部分自测时间，也可以私下找产 品和测试人员也可以提前介入测试（这是还没有进入测试阶段噢） －－－－－ 出来混，都是拼本事 作为一个有经验的高级开发，如果恰好还在带团队 那么就必须有维护自身和组员们利益的心思 如果让兄弟们跟着你干，净吃亏的话，我觉得是很不够意思 如果老想着老板，想着讨好老板，也要分轻重缓急，也要有原则，也要有和老板商 量，并顶住老板压力的打算 不要以损害员工们的正常休息时间和正常福利 大家现在有幸是同事 以后出去不在一起了，说不定谁混的更好，也说不定谁是谁的上下级 大家说有理吗 |
| 17 andyL 2016-08-19 16:47:01 +08:00 说了这么多，所以你的技术领导很重要，也就是领导的经验和人品很重要！ |
| 18 andyL 2016-08-19 16:58:59 +08:00 @ipconfiger 我之前也用小时来估算，可能是自己水平不够，也存在上游输出不给力的情况，开发阶段压力很大。以小时评估了，领导却是很喜欢。但是实际上根本不可能，人不是机器，都存在一个效率问题。人也不是那几个小时内都只编写代码的，也可能会有沟通和其他任务的交换，以小时评估的话，个人的可控性太低了。 |
Select Language