基于事实的进度计划

Software developers don’t really like to make schedules. Usually, they try to get away without one. “It’ll be done when it’s done!” they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten.

软件开发人员实在是不喜欢定计划。他们通常会尝试不做计划。他们会说“做好的时候就做好了！”，期望这样勇敢，幽默的台词会让老板付之一笑。然后在随后的愉悦中，软件计划就被忘到一边了 。

Most of the schedules you do see are halfhearted attempts. They’re stored on a file share somewhere and completely forgotten. When these teams ship, two years late, that weird guy with the file cabinet in his office brings the old printout to the post mortem, and everyone has a good laugh. “Hey look! We allowed two weeks for rewriting from scratch in Ruby!”

你通常看见的计划大都是漫不经心的产物。他们被存在某个共享的地方然后就完全被忘记了。当这些团队两年后发布产品的时候，那个守着文件柜的怪人事后就从他的办公室拿出了那份老的打印版，然后每个人都开始大笑。“嘿，看，我们当时居然允许花两个礼拜时间用Ruby来重写！”。

Hilarious! If you’re still in business.

如果你还在做这事的话，那也实在太搞笑了。

You want to be spending your time on things that get the most bang for the buck. And you can’t figure out how much buck your bang is going to cost without knowing how long it’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 how much time each will take.

你肯定希望把时间花在最划算的事情上。然后如果你不知道你的事情要花多长时间的话，你肯定也不知道要花多少钱。当你要决定是做“动画回形针”还是“更多的金融功能”特性的时候，你真的得搞清楚他们各要花多长时间。

Why won’t developers 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 working on a schedule if it’s not going to be right?

为什么开发人员不定计划？两个原因。一：实在是太他妈痛苦了。 二：没人会相信计划是现实的。 如果计划不正确的话那干嘛还费那么大力气来做呢？。

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gatherevidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

在过去的一年多，在FogCreek公司我们开发了一个系统，这个系统是如此简单易用以至于我们最爱抱怨的开发者都愿意拿来使用。就目前为止，它产生的计划还是非常靠谱的。我们把它叫做基于事实的计划定制（EBS），你可以从历史事件表里搜集事实然后将其反馈会计划制定。你得到的不仅仅是一个发布日期：你得到一个置信分布曲线，该曲线显示了你在任意给定日期交付的概率。看起来是这个样子的。

The steeper the curve, the more confident you are that the ship date is real.

曲线越是陡，你的发布日期就越准确可信。

Here’s how you do it.

下面是如何来生成该曲线。

1) Break ‘er down

2) 分解。

When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.

当我看见以天甚至星期为单位制定的计划时，我知道这肯定是不准确的。你需要把你的计划分解成用小时衡量的小任务。 所有任务不得超过16小时。

This forces you to actually figure out what you are going to do. Write subroutine foo. Create this dialog box. Parse the Fizzbott file. Individual development tasks are easy to estimate, because you’ve written subroutines, created dialogs, and parsed files before.

这个过程会迫使你去搞清楚你将要做什么。编写子过程foo。创建这个对话框。杰西Fizzbott文件。但一个的开发任务很容易估算，因为你以前写过子过程，创建过对话框，以及解析过文件。

If you are sloppy, and pick big three-week tasks (e.g., “Implement Ajax photo editor”), then you haven’t thought about what you are going to do. In detail. Step by step. And when you haven’t thought about what you’re going to do, you can’t know how long it will take.

如果你很随便，选择了一个大的3个星期的任务（像，实现一个Ajax照片编辑器），那么你还没想清楚你要干什么。具体的，一步一步。而且如果你没想清楚你要怎么做，你就不可能知道要花多久。

Setting a 16-hour maximum forces you to design the damn feature. If you have a hand-wavy three week feature called “Ajax photo editor” without a detailed design, 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 be forgetting a lot of them.

设定16个小时的上限就是为了迫使你去设计那个该死的功能。如果你掰掰手指头就说有个三个礼拜的功能叫做“Ajax照片编辑器”而没有详细的设计，很抱歉我是那个打破你幻想的人，但客观的说你肯定不能那样。你从没想过里面的步骤，你肯定不会记得大部分这些步骤。

3) Track elapsed time

4) 跟踪花费时间。

It’s hard to get individual estimates exactly right. How do you account for interruptions, unpredictable bugs, status meetings, and the semiannual Windows Tithe Day when you 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 going to take to implement a given subroutine?

You can’t, really.

很难把每个任务都估算的绝对准确。你怎么考虑那些打断，没法预测的错误，状态会议，以及每半年的Windows受难日（这天，你要重新安装你的主开发服务器上的所有东西）呢？见鬼，就是没有这些东西，你又如何精确的估算你实现一个指定的子过程要花多长时间呢？

你真的没办法做到的。

So, keep timesheets. Keep track of how long you spend working on each task. Then you can go back and see how long things took relative to the estimate. For each developer, you’ll be collecting data like this:

所以，做个时间表，记录你在各项任务上花费的时间。然后你能回过去观察每样任务时间和预计相比花了多长时间。对每一个开发人员，你都要搜集像这样的数据：

Each point on the chart is one completed task, with the estimate and actual times for that task. When you divide estimate by actual, you getvelocity: how fast the task was done relative to estimate.

图上的每个点都代表一个完成的任务，同时还有那项任务的实际和估计时间。如果你用实际时间处以估算时间你就得到了速度因子：相对于预期你完成任务的速度因子。

Over time, for each developer, you’ll collect a history of velocities.

日复一日，对每一个开发人员，你都会获得这样的一个速度因子历史。。

• The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right. So their velocity history is {1, 1, 1, 1, 1, …}

• 那种神秘的完美估算法，仅存在于想象当中，也就是每项估算都完全正确，因此他们的速度因子为{1,1,1,1,1,…}

• A typical bad estimator has velocities all over the map, 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 estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time. This common estimator has very consistent 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 estimators gain more experience, their estimating skills improve. So throw away any velocities older than, say, six months.

随着估算者获得越来越多的经验，他们的估算技能也慢慢改进。所以抛弃那些已经超过6个月的估算。

If you have a new estimator on your team, who doesn’t have a track record, assume the worst: give them a fake history with a wide range of velocities, until they’ve finished a half-dozen real tasks.

如果你的团队来了一个新的估算师，他没有跟踪记录，考虑一下最坏情况：给他们一个虚假的各种范围速度因子的历史，直到他们完成了一半真实任务的时候。

3) Simulate the future

3）模拟未来

Rather than just adding up estimates to get a single ship date, which sounds right but gives you a profoundly wrong result, you’re going to use the Monte Carlo method to simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible 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 by any given date.

相比于仅仅相加然后得出一个最后的发布日期，这听起来不错，但给出的绝对是错误的结果，你应该采用蒙特卡洛算法来模拟许多可能的未来。在一个蒙特卡洛模拟中，你可以创建100个可能的未来场景。每个这些未来常见都仅有1%可能，这样你可以做出一张 任意给定日期发布可能性的图标。

While calculating each possible future for a given developer, you’re going divide each task’s estimate by a randomly-selected velocityfrom that developer’s historical velocities, which we’ve been gathering in step 2. Here’s one sample future:

当你为每个给定的开发人员计算这样的一个可能未来的时候，你应该将每项任务除以一个从开发者的历史速度因子里随机选择的速度因子（这项数据我们在步骤二里已经搜集过了），下面就是一个样本的未来数据。

估计: 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 100 times; each total has 1% probability, and now you can figure out the probability that you will ship on any given date. Now watch what happens:

重复这个过程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 the simulation 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.0 are just as likely. Each round of the simulation is going to produce a very different result, because when you divide by random velocities you get very different numbers each time. The probability distribution curve you get will be very shallow, showing an equal chance of shipping tomorrow or in the far future. That’s still useful information to get, by the way: it tells you that you shouldn’t have confidence in the predicted ship dates.

• 会的估算者的速度因子在图表里到处都是，0.1和13.0一样可能。每一轮的模拟都会产生非常不同的结果，因为当你每次处以随机的速度因子的时候你都会得到很不一样的结果。这时你得到的概率分布曲线结论就非常肤浅，意味着你明天发布的可能性和遥远的未来发布的可能性是一样的。虽然还是有那么点儿用处，顺便说一下：它同时告诉你，你不应轻信预测的发布日期。

• The common estimator has a lot of velocities that are pretty close to each other, for example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}. When you divide by these velocities you increase the amount of time something takes, so in one iteration, an 8-hour task might 13 hours; in another it might take 15 hours. That compensates for the estimators perpetual optimism. And it compensatesprecisely, based exactly on this developers actual, proven, historical optimism. And since all the historical velocities are pretty close, hovering around 0.6, when you run each round of the simulation, you’ll get pretty similar numbers, so you’ll wind up with 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 of the Monte Carlo simulation, of course, you have to convert the hourly data to calendar data, which means you have to take into account each developer’s work schedule, 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 be done. These calculations are painstaking, but luckily, painstaking is what computers are good at.

在蒙特卡洛的每一轮模拟中，当然，你要把小时数据转换成日程数据，日历数据意味着你要把开发者的工作进度，休假，公假等等都考虑进来。然后你每一轮都要观察，哪个开发者最后完成，因为那就是整个团队的完成时间。 这些计算很痛苦， 不过幸运的是， 计算机刚好擅长这些令人痛苦的事情。

Obsessive-compulsive disorder not required

不需要强迫症

What do you do about the boss who interrupts you all the time with long-winded stories about his fishing trips? Or the sales meetings you’re forced to go to even though you have no reason to be there? Coffee breaks? Spending half a day helping the new guy get his dev environment set up?

如果你的老板不停的打断你然后给你讲他去钓鱼路上的冗长故事，你会怎么做？或者是你被迫参加你没有任何理由应该要参加的销售会议，你会怎么做？咖啡间歇呢？花半天时间帮新人设置开发环境？

When Brett and I were developing this technique at Fog Creek, we worried a lot about things that take real time but can’t be predicted in advance. Sometimes, this all adds up to more time than writing code. Should you have estimates for this stuff too, and track it on a time sheet?

当我和Brett在FogCreek开发这种技术的时候，我们很担心这种实际上要花时间但是却不能预先估计的事情。有时候，这些事情总共花费的时间比写代码还多。你也应该要估算这种事情么？用时间表来追踪这些？。

Well, yeah, you can, if you want. And Evidence Based Scheduling will work.

是的，如果你愿意的话当然可以。然后基于事实的计划制定就能成功。

But you don’t have to.

但你不必须那么做。

It turns out that EBS works so well that all you have to do is keep the clock running on whatever task you were doing when the interruption occurred. As disconcerting as this may sound, EBS produces the best results when you do this.

EBS实际上工作的很好，你要做的事情就是当任何打断出现的时候你都记下时间。这听起来可能很令人不安，但EBS在你这样做的时候才能产生最佳的结果。

Let me walk you through a quick example. To make this example as simple as possible, I’m going to imagine a very predictable programmer, John, whose whole job is writing those one-line getter and setter functions that inferior programming languages require. All day long this is all he does:

让我跟你一起来看一个快速的例子。为了尽可能简化这个例子，我要想象一个很容易预测的程序员John,他的工作就是为那些低级的编程语言写那种必须的一行的getter和setter函数。

private int width;

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 someone like this.

我知道，我懂…这是个故意编出来的很傻的例子，但你也知道你也见过这样的人。

Anyway. Each getter 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 boss who interrupts him every once in a while with a two-hour conversation about marlin fishing. Now, of course, John could have a task on his schedule called “Painful conversations about marlin,” and put that on his timesheet, but this might 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 his velocities are:

他的速度就是：

{1, 1, 1, 1, 0.5, 1, 1, 1, 1, 0.5, 1, … }

Now think about what happens. In the Monte Carlo simulation, the probability that each estimate will be divided by 0.5 is exactly the same as the probability that John’s boss would interrupt him during any given feature. So EBS produces a correct schedule!

现在想想发生了什么。在蒙特卡洛模拟过程中，每个估算被除以0.5的概率和John的老板在任何功能实现的过程中来打断他的概率是一样的。所以EBS算出了真确的计划！

In fact, EBS is far more likely to have accurate evidence about these interruptions than even the 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 can either

实际上，相比那些有记录时间表强迫症的开发者，EBS对这些打断的有着更加准确的事实证据。着也正是为什么EBS如此有效的原因。下面是我如何跟别人解释这些的。当开发者被打断的时候，他们可以：

1. make a big stink about putting the interruption on their timesheet and in their estimates, so management can see just how much time is being wasted on fishing conversation, or

1. 公开抱怨这个打断，并把它记到他们的时间表估计项目上去，这样管理层就能知道有多少时间被浪费在这种钓鱼谈论中，或者。

1. make a big stink about refusing to put it on their timesheet, just letting the feature they were working on slip, because they refuse to pad their estimates which were perfectly correct with stupid conversation about fishing expeditions to which they weren’t even invited,

1. 抱怨归抱怨但是不把它放到时间表里去，就让他们工作的功能跳票，因为他们也不会为了显得他们的估算是完全准确的而在时间表里填上那些他们甚至都没被邀请的愚蠢的关于钓鱼的对话。

… and in either case, EBS gives the same, exactly correct results, no matter which type of passive-aggressive developer you have.

…不管是哪一种情况, 不管你被动还是主动类型的开发人员EBS都给出了相同的完全正确的结果。

4) Manage your projects actively

4）主动管理你的项目。

Once you’ve got this set up, you can actively manage projects to ship on time. For example, if you sort features out into different priorities, it’s easy to see how much it would help the schedule if you could cut the lower priority features.

一旦你了解了这种设置，你就可以主动的管理项目以便准时发布产品。例如，如果你把功能根据优先级分成不同的类别，这样就很容易看出来如果你砍掉低优先级的功能对进度有什么帮助。

You can also look at the distribution of possible ship dates for each developer:

你也可以查看每个开发者的可能交付日期分布：

Some developers (like Milton in this picture) may be causing problems because their ship dates are so uncertain: they need to work on learning to estimate better. Other developers (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 had everything planned down to the last detail when you started work, EBS works great. 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 somebody on the board of directors comes up with a cool new idea to make your golf cart GPS 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 the original schedule.

项目范围变动

假定你开始工作的时候所有的东西都已经计划到了极致，EBS也完全正确。不过，老实说，你还是可能会遇到你原来没有计划的功能。你会有些新的想法，你的销售人员会销售你没有的功能，董事会的某些人会帮你的高尔夫车GPS程序想出些新点子，例如让你的程序在高尔夫选手闹哄哄的跑来跑去的时候监视大伙儿的心电图。这些都会导致你原来的计划没有预料的情况并且延迟最终交付。

Ideally, you have a bunch of buffer for this. In fact, go ahead and build buffer into your original schedule for:

理想情况下，你应该要有一些缓冲来应付这些情况。 实际上要为你原来的计划制定一些缓冲来处理这些情况：

1. New feature ideas

1. 新功能想法

1. Responding to the competition

1. 响应竞争

1. Integration (getting everyone’s code to work together when it’s merged)

1. 集成（当所有代码融合的时候花一些时间来保证所有人的代码都是能工作的）

1. Debugging time

1. 调试时间

1. Usability testing (and incorporating the results of those tests into the product).

1. 可用性测试（将产品的可用性测试集成进产品）

1. Beta tests

1. Beta测试

So now, when new features come up, you can slice off a piece of the appropriate buffer and use it for the new feature.

所以现在，当有新的功能需求出现的时候，你就应该要分出合适的额外的时间并拿它来处理新的功能需求。

What happens if you’re still adding features and you’ve run out of buffer? Well, now the ship dates you get out of EBS start slipping. You should take a snapshot of the ship date confidence distribution every night, so that you can track this over time:

如果你的缓冲都用完了，你还在往产品里添加功能会怎么样？恩，这样EBS计算得出的发布日期就开始滑动。你应该每晚都快速的看一下发布日期置信分布，这样你就能不断的追踪发布日期变化。

The x-axis is 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, the middle is 50% and the bottom is 5%. So, the closer the curves are to one another, the narrower the range of possible ship dates.

X轴表示的是计算完成的时候；y轴表示的是发布日期。上图一共有三条曲线：最上面的是置信度为95%的发布日期，中间的是50%的下面的是5%的，所以这些曲线互相靠的越近，可能的发布日期范围就越精窄。

If you see ship date getting later and later (rising curves), you’re in trouble. If it’s getting later by more than one day per day, you’re adding work faster than you’re completing work, and you’ll never be done. You can also look and see if the ship date confidence distribution is getting tighter (the curves are converging), which it should be if you’re really converging on a date.

如果你发现发布日期越来越迟（曲线上升），你就遇到麻烦了。如果每天发布日期都往后推一天，意味着你增加工作的速度比你完成工作的速度要快，那么你永远也没办法完成产品。你也要看看发布日期的置信分布曲线是不是越来越紧致（曲线是否收敛），如果你的发布日期真的收敛到一个日期的话那就应该是收敛到那一天。

While we’re at it

我们在讨论这些的时候

Here are a few more things I’ve learned over the years about schedules.

下面是另外一些这些年我学到的关于进度计划的东西。

1) Only the programmer doing the work can create the estimate. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to implement a feature can figure out what steps they will need to take to implement that feature.

只有在做实际工作的程序员才能估计。任何那种管理层制定计划然后把它扔给程序员的进度计划注定是要失败的。只有那些实际要实现功能的程序员才能弄清楚要实现这个功能的具体步骤。

2) Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’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. This will help EBS predict the time it takes to get fully debugged code, not just working code.

当你发现错误的时候就开始修正它们，把时间算到你原来的这项任务里。 你无法预先制定修正某个错误的计划，因为你不知道你会遇到什么样的软件错误。当新代码里发现错误的时候，把时间算到你原来计划中会正确实现的那项任务里。这有助于EBS正确的预测你实现完整的调试过的代码的时间，而不仅仅是工作代码。

3) Don’t let managers badger developers into shorter estimates. Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.

不要让项目经理纠缠程序员制定更短时间的估计。 许多初级软件项目经理会认为他们可以通过给予程序员更“紧凑”（时间短到不现实）的进度计划来激励程序员更加快速的工作。我觉得这种所谓的激励简直就是脑残。当我落后于进度的时候我会觉得注定是这样的，抑郁，并且失去动机。当我提前于进度计划，我就会很高兴并且充满效率。进度计划不是玩心理游戏的地方。

Why do managers try this?

为什么经理会尝试这么做？。

When the project begins, the technical managers go off, meet with the business people, and come up with a list of features they think would take about three months, but which would really take twelve. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 4n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. The business people are unhappy.

当项目开始的时候，技术经理就会去会见业务人员，然后定出一堆他们觉得只要花3个月的功能，实际上这些功能可能要花12个月。 当你只考虑写代码而不考虑写代码的所有步骤的时候，总是看起来要花N的时间， 而实际上可能要花4N的时间。当你制定实际的计划的时候，你把所有的任务都加起来然后意识到项目要比原来的计划要花多得多的时间。 业务人员就不高兴了。

Inept managers try to address this by figuring out how to get people to work faster. This is not very realistic. You might be able to hire more people, but they need to get up 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 able to get 10% more raw code out of people temporarilyat the cost of having them burn out 100% in a year. Not a big gain, and it’s a bit like eating your seed corn. Of course, when you overwork people, debugging time doubles and a late project becomes later. Splendid karma.

你可能临时的让他们多写出10%的原始代码，代价是一年之内他们都筋疲力尽了。不是什么太大的收获，有点像吃掉你自己的玉米种子。当然，当你开始让大家加班，调试时间就会翻倍，延迟的项目会更迟，完全就是因果报应。

But you can never get 4n from n, ever, and if you think you can, please email me the stock symbol for your company so I can short it.

但你绝对不能从N里得到4N，如果你觉得你能，发电子邮件告诉我你们公司的股票代码，我绝对会做空它的。

4) A schedule is a box of wood blocks. If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks. If you wanted to ship in six months, but you have twelve months on the schedule, you are either going to have to delay shipping, 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 useful opportunity to actually see into the future by lying to yourself about what you see there.

进度就像一盒子的木料。 如果你有一堆木料而且你无法把他们装进盒子里，你有两个选择：选个更大的盒子，或者去掉一些木料。如果你想要在6个月内发布，但你的进度上有12个月的内容，你要么延迟发布，要么找些功能删除掉。你不能缩减内容，如果你假装可以的话，你不过是在对你自己撒谎你能在未来看到什么，你剥夺了自己很好的机会来看看未来实际是怎样的。

Now that I mention it, one of the great benefits of realistic schedules is that you are forced to delete features. Why is this good?

既然我提到了，现实版的进度计划的最大好处之一就在于你被迫删除功能特性。为什么这样好呢？。

Suppose you have two features in mind. One is really useful and will make your product really great. The other is really easy and the programmers can’t wait to code it up (”Look! !”), 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 of time, and you will have no choice but to slip the schedule to do the useful/important feature.

如果你不制定进度计划，程序员就首先会做最简单/有趣的功能，然后他们就没时间了，你除了跳票掉原来的有用功能的进度计划之外没有选择。

If you do make a schedule, even before you start working, you’ll realize that you have to cut something, so you’ll cut the easy/fun feature and just do the useful/important feature. By forcing yourself to chose some features to cut, you wind up making a more powerful, better product with a better mix of good features that ships sooner.

如果你确实制定计划，那排在你开始工作之前，你就会意识到你必须要砍掉些东西，然后你就砍掉那些容易/有趣的功能然后只做那些有用/重要的功能。通过强迫自己选出一些功能来砍掉，你最终做出了更加强大，更好的产品，产品融合了更好的功能，也能较早发布。

Way back when I was working on Excel 5, our initial feature list was huge and would have gone way over schedule. “Oh my!” we thought. “Those are all super important 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 the schedule. Everybody felt unhappy about the cuts. To make people feel better, we told ourselves that we weren’tcutting the features, we were simply deferring them to Excel 6.

实际上，我们别无选择，我们必须砍掉我们认为“骨子里”重要的的功能来赶上进度。所有人都会对这些功能裁剪感到不高兴。为了让人们觉得好一点，我们告诉自己我们不是在砍掉这些功能，我们只是把他们推迟到Excel6。

As Excel 5 was nearing 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 that had been punted from the Excel 5 schedule. Guess what? It was the shoddiest list of features you could imagine. Not one of those features was worth doing. I don’t think a single one of them ever was. The process of culling features to fit a schedule was the best thing we could have done. If we hadn’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 backwards compatibility, until the end of time.

在Excel5快要完成的时候，我开始和同事EricMichelman编写Excel6的规范，我们坐下来讨论从Excel5推迟过来的特性。你猜怎么着？那简直就是你能想象的最挫的功能列表。 没有一个功能值得做。 我不觉得任何一个值得去做。 裁剪功能了列表来迎合进度计划的过程是做得最好的事情。如果我们没有这么做，Excel5至少要花两倍的时间而且包含了50%的无用垃圾功能。这些功能还得后续技术支持，后向兼容直到最后。

Summary

总结

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

使用基于事实的进度计划相当简单：在开始的时候每个迭代大约要花你一两天来产生详细的估算，然后每天工作的时候要花你几秒钟把任务记录到时间表里。好处是巨大的：现实的进度计划。

Realistic schedules are the key to creating good software. It forces you to do the best features 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 Based Scheduling is built into FogBugz 6.0.

加一句

基于事实的进度计划已经被集合进了FogBugz6.0