文章转自 http://blog.csdn.net/zinking3/article/details/15408225，有些图片不能显示，重新配上新图
Evidence Based Scheduling
基于事实证据的进度计划
by Joel Spolsky Friday, October 26, 2007
Softwaredevelopers don’t really like to make schedules. Usually, they try to get awaywithout one. “It’ll be done when it’s done!” they say, expecting that such abrave, funny zinger will reduce their boss to a fit of giggles, and in theensuing joviality, the schedule will be forgotten.
软件开发人员实在是不喜欢定计划。他们通常会尝试不做计划。他们会说“做好的时候就做好了！”，期望这样勇敢，幽默的台词会让老板付之一笑，在随后的愉悦中，软件计划就被忘到一边了。
Most of theschedules you do see are halfhearted attempts. They’re stored on a file sharesomewhere and completely forgotten. When these teams ship, two years late, thatweird guy with the file cabinet in his office brings the old printout to thepost mortem, and everyone has a good laugh. “Hey look! We allowed two weeks forrewriting from scratch in Ruby!”
你通常看见的计划大都是漫不经心的产物。他们被存在某个共享的地方然后就完全被忘记了。当这些团队两年后发布产品的时候，那个守着文件柜的怪人事后就从他的办公室拿出了那份老的打印版，然后每个人都开始大笑。“嘿，看，我们当时居然允许花两个礼拜时间用Ruby来重写！”。
Hilarious! If you’re still inbusiness.
如果你还在做这事的话，那实在太滑稽了。
You want to bespending your time on things that get the most bang for the buck. And you can’tfigure out how much buck your bang is going to cost without knowing how longit’s going to take. When you have to decide between the “animated paperclip”feature and the “more financial functions” feature, you really need to know howmuch time each will take.
你肯定希望把时间花在最划算的事情上。然后如果你不知道你的事情要花多长时间的话，你肯定也不知道要花多少钱。当你要决定是做“动画回形针”还是“更多的金融功能”特性的时候，你真的得搞清楚他们各要花多长时间。
Why won’tdevelopers make schedules? Two reasons. One: it’s a pain in the butt. Two:nobody believes the schedule is realistic. Why go to all the trouble of workingon a schedule if it’s not going to be right?
为什么开发人员不定计划？两个原因。一：实在是太他妈痛苦了。 二：没人会相信计划是现实的。 如果计划不正确的话那干嘛还费那么大力气来做呢？。
Over the lastyear or so at Fog Creek we’ve been developing a system that’s so easy even ourgrouchiest developers are willing to go along with it. And as far as we cantell, it produces extremely reliable schedules. It’s called Evidence-BasedScheduling, or EBS. You gatherevidence, mostly from historical timesheetdata, that you feed back into your schedules. What you get is not just one shipdate: you get a confidence distribution curve, showing the probability that youwill ship on any given date. It looks like this:
在过去的一年多，在FogCreek公司我们开发了一个系统，这个系统是如此简单易用以至于我们最爱抱怨的开发者都愿意拿来使用。就目前为止，它产生的计划还是非常靠谱的。我们把它叫做基于事实的计划定制（EBS），你可以从历史事件表里搜集事实然后将其反馈会计划制定。你得到的不仅仅是一个发布日期：你得到一个置信分布曲线，该曲线显示了你在任意给定日期交付的概率。看起来是这个样子的。
The steeper thecurve, the more confident you are that the ship date is real.
曲线越是陡，你的发布日期就越准确可信。
Here’s how you doit.
下面是如何来生成该曲线。
1) Break ‘er down
2) 分解。
When I see aschedule measured in days, or even weeks, I know it’s not going to work. Youhave to break your schedule into very small tasks that can be measured in hours.Nothing longer than 16 hours.
当我看见以天甚至星期为单位制定的计划时，我知道这肯定是不准确的。你需要把你的计划分解成用小时衡量的小任务。 所有任务不得超过16小时。
This forces youto actually figure out what you are going to do. Write subroutine foo.Create this dialog box. Parse the Fizzbott file. Individual development tasksare easy to estimate, because you’ve written subroutines, created dialogs, andparsed files before.
这个过程会迫使你去搞清楚你将要做什么。编写子过程foo。创建这个对话框。杰西Fizzbott文件。但一个的开发任务很容易估算，因为你以前写过子过程，创建过对话框，以及解析过文件。
If you aresloppy, and pick big three-week tasks (e.g., “Implement Ajax photo editor”),then you haven’t thought about what you are going to do. Indetail. Step by step. And when you haven’t thought about what you’re going todo, you can’t know how long it will take.
如果你很随便，选择了一个大的3个星期的任务（像，实现一个Ajax照片编辑器），那么你还没想清楚你要干什么。具体的，一步一步。而且如果你没想清楚你要怎么做，你就不可能知道要花多久。
Setting a 16-hourmaximum forces you to design the damn feature. If you have ahand-wavy three week feature called “Ajax photo editor” without a detaileddesign, I’m sorry to be the one to break it to you but you are officially doomed.You never thought about the steps it’s going to take and you’re sure to beforgetting a lot of them.
设定16个小时的上限就是为了迫使你去设计那个该死的功能。如果你掰掰手指头就说有个三个礼拜的功能叫做“Ajax照片编辑器”而没有详细的设计，很抱歉我是那个打破你幻想的人，但客观的说你肯定不能那样。你从没想过里面的步骤，你肯定不会记得大部分这些步骤。
3) Track elapsed time
4) 跟踪花费时间。
It’s hard to getindividual estimates exactly right. How do you account for interruptions,unpredictable bugs, status meetings, and the semiannual Windows Tithe Day whenyou have to reinstall everything from scratch on your main development box?Heck, even without all that stuff, how can you tell exactly how long it’s goingto take to implement a given subroutine?
You can’t,really.
很难把每个任务都估算的绝对准确。你怎么考虑哪些打断，没法预测的错误，状态会议，以及每半年的Windows受难日（这天，你要重新安装你的主开发服务器上的所有东西）呢？见鬼，就是没有这些东西，你又如何精确的估算你实现一个指定的子过程要花多长时间呢？
你真的没办法做到的。
So, keeptimesheets. Keep track of how long you spend working on each task. Then you cango back and see how long things took relative to the estimate. For eachdeveloper, you’ll be collecting data like this:
所以，做个时间表，记录你在各项任务上花费的时间。然后你能回过去观察每样任务时间和预计相比花了多长时间。对每一个开发人员，你都要搜集像这样的数据：
Each point on thechart is one completed task, with the estimate and actual times for that task.When you divide estimate by actual, you getvelocity: how fast the taskwas done relative to estimate.
图上的每个点都代表一个完成的任务，同时还有那项任务的实际和估计时间。如果你用实际时间处以估算时间你就得到了速度因子：相对于预期你完成任务的速度因子。
Over time, foreach developer, you’ll collect a history of velocities.
日复一日，对每一个开发人员，你都会获得这样的一个速度因子历史。。
· The mythical perfect estimator, who exists only in yourimagination, always gets every estimate exactly right. So their velocityhistory is {1, 1, 1, 1, 1, …}
· 那种神秘的完美估算法，仅存在于想象当中，也就是每项估算都完全正确，因此他们的速度因子为{1,1,1,1,1,…}
· A typical bad estimator has velocities all over themap, for example {0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0}
· 一个典型的坏的估算就是在图中有着各种各样的速度因子，例如{0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0}
· Most estimators get the scale wrong but the relative estimatesright. Everything takes longer than expected, because the estimate didn’taccount for bug fixing, committee meetings, coffee breaks, and that crazy bosswho interrupts all the time. This common estimator has veryconsistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6,0.5, 0.6, 0.7, 0.6}
· 大多数的估算规模是错误的，但是相对估计是正确的。 所有的事情都比预计要花更多的时间，因为估算没有考虑修正错误，委员会会议，咖啡休息然后还有那个总是来打断的疯子老板。这种常见的估算者有着很稳定的速度因子，但他们都小于1.0 例如{0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7,0.6}。
As estimatorsgain more experience, their estimating skills improve. So throw away anyvelocities older than, say, six months.
随着估算者获得越来越多的经验，他们的估算技能也慢慢改进。所以抛弃那些已经超过6个月的估算。
If you have a newestimator on your team, who doesn’t have a track record, assume the worst: givethem a fake history with a wide range of velocities, until they’ve finished ahalf-dozen real tasks.
如果你的团队来了一个新的估算师，他没有跟踪记录，考虑一下最坏情况：给他们一个虚假的各种范围速度因子的历史，直到他们完成了一半真实任务的时候。
3) Simulate thefuture
3）模拟未来
Rather than justadding up estimates to get a single ship date, which sounds right but gives youa profoundly wrong result, you’re going to use the Monte Carlo method tosimulate many possible futures. In a Monte Carlo simulation, you can create 100possible scenarios for the future. Each of these possible futures has 1%probability, so you can make a chart of the probability that you will ship byany given date.
相比于仅仅相加然后得出一个最后的发布日期，这听起来不错，但给出的绝对是错误的结果，你应该采用蒙特卡洛算法来模拟许多可能的未来。在一个蒙特卡洛模拟中，你可以创建100个可能的未来场景。每个这些未来常见都仅有1%可能，这样你可以做出一张任意给定日期发布可能性的图标。
While calculatingeach possible future for a given developer, you’re going divide each task’sestimate by a randomly-selected velocityfrom that developer’shistorical velocities, which we’ve been gathering in step 2. Here’s one samplefuture:
当你为每个给定的开发人员计算这样的一个可能未来的时候，你应该将每项任务除以一个从开发者的历史速度因子里随机选择的速度因子（这项数据我们在步骤二里已经搜集过了），下面就是一个样本的未来数据。
| 估计: |
4 |
8 |
2 |
8 |
16 |
|
| 随机速度因子 |
0.6 |
0.5 |
0.6 |
0.6 |
0.5 |
Total: |
| E/V: |
6.7 |
16 |
3.3 |
13.3 |
32 |
71.3 |
Do that 100times; each total has 1% probability, and now you can figure out theprobability that you will ship on any given date.
Now watch whathappens:
重复这个过程100次；每个总计都只有1%的可能，然后你就可以得出你在任意给定日期发布的概率。
现在看看发生了什么：
· In the case of the mythical perfect estimator, all velocities are 1.Dividing by a velocity which is always 1 has no effect. Thus, all rounds of thesimulation give the same ship date, and that ship date has 100% probability.Just like in the fairy tales!
· 在那种神奇的完美估算者的情况下，所有的速度因子都是1.处以速度因子为1等于没有除。然后所有的模拟都会给出相同的发布日期，然后那个发布日期有着100%的概率。就像童话里描述的那样。
· The bad estimator’s velocities are all over the map. 0.1 and 13.0are just as likely. Each round of the simulation is going to produce a verydifferent result, because when you divide by random velocities you get verydifferent numbers each time. The probability distribution curve you get will bevery shallow, showing an equal chance of shipping tomorrow or in the farfuture. That’s still useful information to get, by the way: it tells you thatyou shouldn’t have confidence in the predicted ship dates.
· 会的估算者的速度因子在图表里到处都是，0.1和13.0一样可能。每一轮的模拟都会产生非常不同的结果，因为当你每次处以随机的速度因子的时候你都会得到很不一样的记过。这时你得到的概率分布曲线就非常浅薄，意味着你明天发布的可能性和遥远的未来发布的可能性是一样的。虽然还是有那么点儿用处，顺便说一下：它同时告诉你，你不应亲信预测的发布日期。
· The common estimator has a lot of velocities that are pretty closeto each other, for example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}. When youdivide by these velocities you increase the amount of time something takes, soin one iteration, an 8-hour task might 13 hours; in another it might take 15hours. That compensates for the estimators perpetual optimism. And itcompensatesprecisely, based exactly on thisdevelopers actual, proven, historical optimism. And since all thehistorical velocities are pretty close, hovering around 0.6, when you run eachround of the simulation, you’ll get pretty similar numbers, so you’ll wind upwith a narrow range of possible ship dates.
· 普通的估算者有着大量非常相似的速度因子，例如，{0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}。当你除以这些速度因子的时候你增加了某件事情花费时间发生的可能性，所以在某次迭代中，一项8小时的任务可能要花13小时；在另一个迭代中可能要花15小时。这种过程弥补了估算者的固有乐观倾向。而且弥补的很准确，因为这是基于该开发者的实际，真实，历史乐观性数据而来的。既然所有的历史速度因子都很接近，大约徘徊在0.6左右，当你每次运行一轮模拟的时候，你都会得到一个相近的数据，所以你最后就会得到一个相对精确的发布日期范围。
In each round ofthe Monte Carlo simulation, of course, you have to convert the hourly data tocalendar data, which means you have to take into account each developer’s workschedule, vacations, holidays, etc. And then you have to see, for each round,which developer is finishing last, because that’s when the whole team will bedone. These calculations are painstaking, but luckily, painstaking is what computersare good at.
在蒙特卡洛的每一轮模拟中，当然，你要把小时数据转换成日程数据，日历数据意味着你要把开发者的工作进度，休假，公假等等都考虑进来。然后你每一轮都要观察，哪个开发者最后完成，因为那就是整个团队的完成时间。这些计算很痛苦， 不过幸运的是， 计算机刚好擅长这些令人痛苦的事情。
Obsessive-compulsivedisorder not required
不需要强迫症
What do you doabout the boss who interrupts you all the time with long-winded stories abouthis fishing trips? Or the sales meetings you’re forced to go to even though youhave no reason to be there? Coffee breaks? Spending half a day helping the newguy get his dev environment set up?
。如果你的老板不停的打断你然后给你讲他去钓鱼路上的冗长的故事，你会怎么做？或者是你被迫参加你没有任何理由应该要参加的销售会议，你会怎么做？咖啡间歇呢？花半天时间帮新人设置开发环境？
When Brett and Iwere developing this technique at Fog Creek, we worried a lot about things thattake real time but can’t be predicted in advance. Sometimes, this all adds upto more time than writing code. Should you have estimates for this stuff too,and track it on a time sheet?
当我和Brett在FogCreek开发这种技术的时候，我们很担心这种实际上要花时间但是却不能预先估计的事情。有时候，这些事情总共花费的时间比写代码还多。你也应该要估算这种事情么？用时间表来追踪这些？。
Well, yeah, youcan, if you want. And Evidence Based Scheduling will work.
是的，如果你愿意的话当然可以。然后基于事实的计划制定就能成功。
But you don’thave to.
但你不必须那么做。
It turns out thatEBS works so well that all you have to do is keep the clock running onwhatever task you were doing when the interruption occurred. As disconcertingas this may sound, EBS produces the best results when you do this.
EBS实际上工作的很好，你要做的事情就是当任何打断出现的时候你都记下时间。这听起来可能很令人不安，但EBS在你这样做的时候才能产生最佳的结果。
Let me walk youthrough a quick example. To make this example as simple as possible, I’m goingto imagine a very predictable programmer, John, whose whole job is writingthose one-line getter and setter functions that inferior programming languagesrequire. All day long this is all he does:
让我跟你一起来看一个快速的例子。为了尽可能简化这个例子，我要想象一个很容易预测的程序员John,他的工作就是为那些低级的编程语言写那种必须的一行的getter和setter函数。
private intwidth;
public int getWidth () { return width; }
public void setWidth (int _width} { width = _width; }
I know, I know…it’s a deliberately dumb example, but you knowyou’ve met someonelike this.
我知道，我懂…这是个故意编出来的很傻的例子，但你也知道你也见过这样的人。
Anyway. Eachgetter or setter takes him 2 hours. So his task estimates look like this:
不管怎样。每个getter或setter函数都要花费他两小时，因此它的任务估计看起来是这样的：
{2, 2, 2, 2, 2,2, 2, 2, 2, 2, 2, … }
Now, this poor guy has a bosswho interrupts him every once in a while with a two-hour conversation aboutmarlin fishing. Now, of course, John could have a task on his schedule called“Painful conversations about marlin,” and put that on his timesheet, but thismight not be politically prudent. Instead, John just keeps the clock running.So his actual times look like this:
现在，这个可怜的家伙有个老板，每隔一段时间就要跟他聊大概俩小时关于钓马琳鱼。现在，当然，John可以在他的任务计划上写上一个任务“关于马琳鱼的痛苦对话”，然后把这个加到他的时间表上，不过这似乎是“政治上”不谨慎的。所以，John不考虑这些，继续计时，因此他的实际时间看上去就是：
{2, 2, 2, 2, 4,2, 2, 2, 2, 4, 2, … }
And hisvelocities are:
他的速度就是：
{1, 1, 1, 1, 0.5,1, 1, 1, 1, 0.5, 1, … }
Now think aboutwhat happens. In the Monte Carlo simulation, the probability that each estimatewill be divided by 0.5 is exactly the same as the probability thatJohn’s boss would interrupt him during any given feature. So EBSproduces a correct schedule!
现在想想发生了什么。在蒙特卡洛模拟过程中，每个估算被除以0.5的概率和John的老板在任何功能实现的过程中来打断他的概率是一样的。所以EBS算出了真确的计划！
In fact, EBS isfar more likely to have accurate evidence about these interruptions than eventhe most timesheet-obsessive developer.Which is exactly why it works so well.Here’s how I explain this to people. When developers get interrupted, they caneither
实际上，相比那些有记录时间表强迫症的开发者，EBS对这些打断的有着更加准确的事实证据。着也正是为什么EBS如此有效的原因。下面是我如何跟别人解释这些的。当开发者被打断的时候，他们可以：
1. make a big stink about putting the interruption on their timesheetand in their estimates, so management can see just how much time is beingwasted on fishing conversation, or
2. 公开抱怨这个打断，并把它记到他们的时间表估计项目上去，这样管理层就能知道有多少时间被浪费在这种钓鱼谈论中，或者。
3. make a big stink about refusing to put it on their timesheet, justletting the feature they were working on slip, because they refuse to pad their estimateswhich were perfectly correct with stupid conversation aboutfishing expeditions to which they weren’t even invited,
4. 抱怨归抱怨但是不把它放到时间表里去，就让他们工作的功能跳票，因为他们也不会为了显得他们的估算是完全准确的而在时间表里填上那些他们甚至都没被邀请的愚蠢的关于钓鱼的对话。
… and in eithercase, EBS gives the same, exactly correct results, no matter whichtype of passive-aggressive developer you have.
…不管是哪一种情况, 不管你被动还是主动类型的开发人员EBS都给出了相同的完全正确的结果。
4) Manage yourprojects actively
4）主动管理你的项目。
Once you’ve gotthis set up, you can actively manage projects to ship on time. For example, ifyou sort features out into different priorities, it’s easy to see how much itwould help the schedule if you could cut the lower priority features.
一旦你了解了这种设置，你就可以主动的管理项目以便准时发布产品。例如，如果你把功能根据优先级分成不同的类别，这样就很容易看出来如果你砍掉低优先级的功能对进度有什么帮助。
You can also lookat the distribution of possible ship dates for each developer:
你也可以查看每个开发者的可能交付日期分布：
Some developers(like Milton in this picture) may be causing problems because their ship datesare so uncertain: they need to work on learning to estimate better. Otherdevelopers (like Jane) have very precise ship dates that are just too late:they need to have some of their work taken off their plate. Other developers(me! yay!) are not on the critical path at all, and can be left in peace.
有些程序员（就像这幅图片里的Milton）可能会导致问题，因为他们的交付日期是如此不确定：他们应该学习更好的估计。其他的开发者（像Jane）有着非常精确的发布日期，就是发布日期太晚了：得从他们的架子上拿走一些活儿。其他的开发者（对，就像我）根本就不在关键路径上，可以安静的留在那儿。
Scope creep
Assuming you hadeverything planned down to the last detail when you started work, EBS worksgreat. To be honest, though, you may do some features that you hadn’t planned.You get new ideas, your salespeople sell features you don’t have, and somebodyon the board of directors comes up with a cool new idea to make your golf cartGPS application monitor EKGs while golfers are buzzing around the golf course.All this leads to delays that could not have been predicted when you did theoriginal schedule.
项目范围变动
假定你开始工作的时候所有的东西都已经计划到了极致，EBS也完全正确。不过，老实说，你还是可能会遇到你原来没有计划的功能。你会有些新的想法，你的销售人员会销售你没有的功能，董事会的某些人会帮你的高尔夫车GPS程序想出些新点子，例如让你的程序在高尔夫选手闹哄哄的跑来跑去的时候监视大伙儿的心电图。这些都会导致你原来的计划没有预料的情况并且延迟最终交付。
Ideally, you havea bunch of buffer for this. In fact, go ahead and build buffer into youroriginal schedule for:
理想情况下，你应该要有一些缓冲来应付这些情况。 实际上要为你原来的计划制定一些缓冲来处理这些情况：
1. New feature ideas
2. 新功能想法
3. Responding to the competition
4. 响应竞争
5. Integration (getting everyone’s code to work together when it’smerged)
6. 集成（当所有代码融合的时候花一些时间来保证所有人的代码都是能工作的）
7. Debugging time
8. 调试时间
9. Usability testing (and incorporating the results of those tests intothe product).
10. 可用性测试（将产品的可用性测试集成进产品）
11. Beta tests
12. Beta测试
So now, when newfeatures come up, you can slice off a piece of the appropriate buffer and useit for the new feature.
所以现在，当有新的功能需求出现的时候，你就应该要分出合适的额外的时间并拿它来处理新的功能需求。
What happens ifyou’re still adding features and you’ve run out of buffer? Well, now the shipdates you get out of EBS start slipping. You should take a snapshot of the shipdate confidence distribution every night, so that you can track this over time:
如果你的缓冲都用完了，你还在往产品里添加功能会怎么样？恩，这样EBS计算得出的发布日期就开始滑动。你应该每晚都快速的看一下发布日期置信分布，这样你就能不断的追踪发布日期变化。
The x-axisis when the calculation was done; the y-axis is the ship date.There are three curves here: the top one is the 95% probability date, themiddle is 50% and the bottom is 5%. So, the closer the curves are to oneanother, the narrower the range of possible ship dates.
X轴表示的是计算完成的时候；y轴表示的是发布日期。上图一共有三条曲线：最上面的是置信度为95%的发布日期，中间的是50%的下面的是5%的，所以这些曲线互相靠的越近，可能的发布日期范围就越精窄。
If you see shipdate getting later and later (rising curves), you’re in trouble. If it’sgetting later by more than one day per day, you’re adding work faster thanyou’re completing work, and you’ll never be done. You can also look and see ifthe ship date confidence distribution is getting tighter (the curves areconverging), which it should be if you’re really converging on a date.
如果你发现发布日期越来越迟（曲线上升），你就遇到麻烦了。如果每天发布日期都往后推一天，意味着你增加工作的速度比你完成工作的速度要快，那么你永远也没办法完成产品。你也要看看发布日期的置信分布曲线是不是越来越紧致（曲线是否收敛），如果你的发布日期真的收敛到一个日期的话那就应该是收敛到那一天。
While we’re at it
我们在讨论这些的时候
Here are a fewmore things I’ve learned over the years about schedules.
下面是另外一些这些年我学到的关于进度计划的东西。
1) Only theprogrammer doing the work can create the estimate. Anysystem where management writes a schedule and hands it off to programmers isdoomed to fail. Only the programmer who is going to implement a feature canfigure out what steps they will need to take to implement that feature.
只有在做实际工作的程序员才能估计。任何那种管理层制定计划然后把它扔给程序员的进度计划注定是要失败的。只有那些实际要实现功能的程序员才能弄清楚要实现这个功能的具体步骤。
2) Fix bugs asyou find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because youdon’t know what bugs you’re going to have. When bugs are found in new code,charge the time to the original task that you implemented incorrectly. Thiswill help EBS predict the time it takes to get fully debugged code,not just working code.
当你发现错误的时候就开始修正它们，把时间算到你原来的这项任务里。 你无法预先制定修正某个错误的计划，因为你不知道你会遇到什么样的软件错误。当新代码里发现错误的时候，把时间算到你原来计划中会正确实现的那项任务里。这有助于EBS正确的预测你实现完整的调试过的代码的时间，而不仅仅是工作代码。
3) Don’t let managersbadger developers into shorter estimates. Manyrookie software managers think that they can “motivate” their programmers towork faster by giving them nice, “tight” (unrealistically short) schedules. Ithink this kind of motivation is brain-dead. When I’m behind schedule, I feeldoomed and depressed and unmotivated. When I’m working ahead ofschedule, I’m cheerful and productive. The schedule is not the place to playpsychological games.
不要让项目经理纠缠程序员制定更短时间的估计。 许多初级软件项目经理会认为他们可以通过给予程序员更“紧凑”（时间短到不现实）的进度计划来激励程序员更加快速的工作。我觉得这种所谓的激励简直就是脑残。当我落后于进度的时候我会觉得注定是这样的，抑郁，并且失去动机。当我提前于进度计划，我就会很高兴并且充满效率。进度计划不是玩心理游戏的地方。
Why do managerstry this?
为什么经理会尝试这么做？。
When the projectbegins, the technical managers go off, meet with the business people, and comeup with a list of features they think would take about threemonths, but which would really take twelve. When you think of writing codewithout thinking about all the steps you have to take, it always seems like itwill take n time, when in reality it will probably take morelike 4n time. When you do a real schedule, you add up all the tasksand realize that the project is going to take much longer than originallythought. The business people are unhappy.
当项目开始的时候，技术经理就会去会见业务人员，然后定出一堆他们觉得只要花3个月的功能，实际上这些功能可能要花12个月。 当你只考虑写代码而不考虑写代码的所有步骤的时候，总是看起来要花N的时间，而实际上可能要花4N的时间。当你制定实际的计划的时候，你把所有的任务都加起来然后意识到项目要比原来的计划要花多得多的时间。业务人员就不高兴了。
Inept managerstry to address this by figuring out how to get people to work faster. This isnot very realistic. You might be able to hire more people, but they need to getup to speed and will probably be working at 50% efficiency for several months(and dragging down the efficiency of the people who have to mentor them).
无能的经理就会通过让人工作的更快来解决这个问题。这很不现实。你可以雇更多的人，但他们得花时间了解情况然后可能只能以50%的效率工作几个月（同时会拉低那些要辅导他们的人的效率）。
You might be ableto get 10% more raw code out of people temporarilyat the cost ofhaving them burn out 100% in a year. Not a big gain, and it’s a bit like eatingyour seed corn. Of course, when you overwork people, debugging time doubles anda late project becomes later. Splendid karma.
你可能临时的让他们多写出10%的原始代码，代价是一年之内他们都筋疲力尽了。不是什么太大的收获，有点像吃掉你自己的玉米种子。当然，当你开始让大家加班，调试时间就会翻倍，延迟的项目会更迟，完全就是因果报应。
But you can neverget 4n from n, ever, and if you think you can, pleaseemail me the stock symbol for your company so I can short it.
但你绝对不能从N里得到4N，如果你觉得你能，发电子邮件告诉我你们公司的股票代码，我绝对会做空它的。
4) A scheduleis a box of wood blocks. If you have a bunchof wood blocks, and you can’t fit them into a box, you have two choices: get abigger box, or remove some blocks. If you wanted to ship in six months, but youhave twelve months on the schedule, you are either going to have to delayshipping, or find some features to delete. You just can’t shrink the blocks,and if you pretend you can, then you are merely depriving yourself of a usefulopportunity to actually see into the future by lying toyourself about what you see there.
进度就像一盒子的木料。 如果你有一堆木料而且你无法把他们装进盒子里，你有两个选择：选个更大的盒子，或者去掉一些木料。如果你想要在6个月内发布，但你的进度上有12个月的内容，你要么延迟发布，要么找些功能删除掉。你不能缩减内容，如果你假装可以的话，你不过是在对你自己撒谎你能在未来看到什么，你剥夺了自己很好的机会来看看未来实际是怎样的。
Now that Imention it, one of the great benefits of realistic schedules is that you are forcedto delete features. Why is this good?
既然我提到了，现实版的进度计划的最大好处之一就在于你被迫删除功能特性。为什么这样好呢？。
Suppose you havetwo features in mind. One is really useful and will make your product reallygreat. The other is really easy and the programmers can’t wait to code it up(”Look! <blink>!”), but it serves no useful purpose.
假设你脑海中有两个功能。其中之一非常有用而且会让你的产品非常棒。另外一个非常简单程序员实在等不及要实现它了（“瞧!一眨眼就好了！”），不过它没什么特别有用的地方。
If you don’t make a schedule,the programmers will do the easy/fun feature first. Then they’ll run out oftime, and you will have no choice but to slip the schedule to do theuseful/important feature.
如果你不制定进度计划，程序员就首先会做最简单/有趣的功能，然后他们就没时间了，你除了跳票掉原来的有用功能的进度计划之外没有选择。
If you do make aschedule, even before you start working, you’ll realize that you have to cutsomething, so you’ll cut the easy/fun feature and just do the useful/importantfeature. By forcing yourself to chose some features to cut, you wind up makinga more powerful, better product with a better mix of good features that shipssooner.
如果你确实制定计划，那排在你开始工作之前，你就会意识到你必须要砍掉些东西，然后你就砍掉那些容易/有趣的功能然后只做那些有用/重要的功能。通过强迫自己选出一些功能来砍掉，你最终做出了更加强大，更好的产品，产品融合了更好的功能，也能较早发布。
Way back when Iwas working on Excel 5, our initial feature list was huge and would havegone way over schedule. “Oh my!” we thought. “Those are all superimportant features! How can we live without a macro editing wizard?”
早在我还在EXCEL5工作的时候，我们最早的功能列表巨大而且早就已经超出了进度计划。“噢，天呐！”我们想“这些都是超级重要的功能！我们怎么能没有一个宏编辑向导呢？”。
As it turns out,we had no choice, and we cut what we thought was “to the bone” to make theschedule. Everybody felt unhappy about the cuts. To make people feel better, wetold ourselves that we weren’tcutting the features, we weresimply deferring them to Excel 6.
实际上，我们别无选择，我们必须砍掉我们认为“骨子里”重要的的功能来赶上进度。所有人都会对这些功能裁剪感到不高兴。为了让人们觉得好一点，我们告诉自己我们不是在砍掉这些功能，我们只是把他们推迟到Excel6。
As Excel 5 wasnearing completion, I started working on the Excel 6 spec with a colleague,Eric Michelman. We sat down to go through the list of “Excel 6” features thathad been punted from the Excel 5 schedule. Guess what? It was the shoddiestlist of features you could imagine. Not one of those featureswas worth doing. I don’t think a single one of them ever was. The process ofculling features to fit a schedule was the best thing we could have done. If wehadn’t done this, Excel 5 would have taken twice as long and included 50%useless crap features that would have had to be supported, for backwardscompatibility, until the end of time.
在Excel5快要完成的时候，我开始和同事EricMichelman编写Excel6的规范，我们坐下来讨论从Excel5推迟过来的特性。你猜怎么着？那简直就是你能想象的最挫的功能列表。没有一个功能值得做。 我不觉得任何一个值得去做。 裁剪功能了列表来迎合进度计划的过程是做得最好的事情。如果我们没有这么做，Excel5至少要花两倍的时间而且包含了50%的无用垃圾功能。这些功能还得后续技术支持，后向兼容直到最后。
Summary
总结
UsingEvidence-Based Scheduling is pretty easy: it will take you a day or two at thebeginning of every iteration to produce detailed estimates, and it’ll take afew seconds every day to record when you start working on a new task on atimesheet. The benefits, though, are huge: realistic schedules.
使用基于事实的进度计划相当简单：在开始的时候每个迭代大约要花你一两天来产生详细的估算，然后每天工作的时候要花你几秒钟把任务记录到时间表里。好处是巨大的：现实的进度计划。
Realisticschedules are the key to creating good software. It forces you to do the bestfeatures first and allows you to make the right decisions about what to build.Which makes your product better, your boss happier, delights your customers,and—best of all—lets you go home at five o’clock.
符合现实的进度是创建好的软件产品的关键。它强迫你先做最好的特性然后让你做出关于要创作什么的最好决定。这个过程让你的产品更好，让你的老板更高兴，让你的顾客高兴，然后最好的一点-让你5点钟可以准时回家。
P.S.
Evidence BasedScheduling is built into FogBugz6.0.
加一句
基于事实的进度计划已经被集合进了FogBugz6.0