标签：http ar 使用 sp strong 文件 数据 div on
http://www.aqee.net/why-programmers-are-bad-at-estimating-times/一个我曾经共事过的很有经验的项目经理曾宣称说，他会拿程序员估计出的时间乘以π值，然后再提高一个数量级，这样得出的才是正确的开发所需要的时间。1天时间经过变换后是3.14周。他经过惨痛的教训才认识到程序员预估的时间都是不靠谱的。为了能更精确的对程序员估计的时间进行换算，我创建了一个时间换算表，重点说明究竟是什么地方出了问题。
| 估计时间 | 程序员的思考 | 程序员忽略的事情 | 真正所 需时间 |
|---|---|---|---|
| 30秒 | 只需要对代码进行很小的改动就搞定了。我清楚的知道程序应该在哪里做修改、怎么修改。只需要30秒时间。 | 启动电脑的时间，启动开发环境的时间，获取源代码的时间。编译、测试、提交代码和文档修改的时间。 | 1小时 |
| 5分钟 | 一个小问题，我只需要上谷歌上查查它正确的语法就能搞定。 | 你不可能第一次就能精确的查找到正确的信息，就算是找到了，在使用它之前你也需要对它做一些调整。还有编译、测试的时间等。 | 2小时 |
| 1小时 | 我知道该怎么做，但是这需要写一些代码，所以要花一些时间。 | 1小时时间太紧张，没有给任何未预料到的事情留下余地。总有一些你预料不到的事情。 | 2小时 |
| 4小时 | 这需要写一些代码，但我基本知道该怎么做。我知道我们的标准框架里的Wizzabanga模块能做这个事情，但我需要去查查文档看如何正确的调用它。 | 这可能是唯一一个符合现实的估计。在任务不是很大、能够处理的情况下，它给未预料到的问题留下了足够的时间。 | 4小时 |
| 8小时 | 我首先要重构Balunga类，把它拆分成两个，然后在Wizzabanga模块里加入调用代码，最后在界面上添加一个新的表单域。 | 系统的很多地方都对Balunga类有依赖关系。大概有40多个文件需要调整。界面上新添加的属性的同时数据库里也要新增字段。8小时是十分理想的状况的时间。程序员在估计时间时总忽略了还有很多其它事情要做。 | 12-16小时 |
| 2天 | 这需要写很多的代码。我需要在数据库中添加一些新表，用一个界面来显示它们，然后还要写存取它们的逻辑代码。 | 对大多数程序员来说，2天时间能完成多少东西都是很难说的。肯定会有一些东西被遗忘。并不是指一些小的东西，一些主要功能上的重要东西也有可能在你估计时被遗漏。 | 5天 |
| 1周 | 哇塞…这可是个大任务。我还不知道如何实现它，我不是告诉你我不知道如何做。一周时间应该足够了，但愿，希望能够，但我不会要求更多的时间，不然的话他们会说我能力不行。 | 这样一个任务对于大多数程序员来说都很难理解消化。这个任务应该发回给架构师，让他把任务拆分成更小的模块，对各模块应该如何执行给出一些指导。架构师应该能找到实现它的一些简单的方法——或者认识到这个任务的工作量比他预期的要多。 | 2-20天 |
预估时间本身就很难。每个程序员的估计都会跟真正需要的时间有些差距。估计时间短了说明有些事情被忽略了(编译，测试，提交代码)。估计时间超了说明任务太大，难以理解。
对于资历较浅的程序员，这种估计误差是混乱的，他们经常会轻视一些任务，同时又对一些稍微有难度的任务过分高估。我认为，对一个有经验的程序员，一个任务的时间应该在半小时到24小时之间，超出24小时的任务都需要拆分。程序员在脑中想一想可能会认为要60小时，但实际上即使是很有经验的程序员也需要将任务分成可控的模块再来分析做决定。
还有一个很重要的需要认识到的一点是，编程上的经验并不等同于时间估计上的经验。一个从没有做过工期估计的程序员不会擅长估计时间。如果不去拿真正需要的时间和估计出的时间进行比较，你不可能从其它反馈信息之得到正确估计时间的经验。
每个程序员都会用到评估技巧。为了提高你的这项技能，你可以在你从事的每个任务上进行锻炼。在任务开始时先预估开发所需时间，拿它跟你最终真正用掉的时间进行对比。这样，你不仅在对任务细节的理解上有提高，同时也提高了你对时间预估的技能。
标签：http ar 使用 sp strong 文件 数据 div on
原文地址：http://www.cnblogs.com/svennee/p/4100988.html
