循证调度(2007)

软件开发人员并不真的喜欢制定时间表。通常，他们试图在没有枪的情况下逃脱。“做完了就做好了！”他们说，期待着这样一个勇敢、有趣的人会让他们的老板咯咯笑起来，在随之而来的欢乐中，日程安排会被遗忘。

你看到的大多数时间表都是半心半意的尝试。它们存储在某个文件共享位置，完全被遗忘了。当这些团队出货时，晚了两年，办公室里那个拿着文件柜的奇怪家伙把旧的打印出来的东西送到验尸房，每个人都笑得很开心。“嘿，看！我们花了两周的时间在Ruby中从头开始重写！“。

你想把时间花在性价比最高的事情上。如果你不知道要花多长时间，你就无法计算出你的大爆炸要花多少钱。当你必须在“动画回形针”功能和“更多金融功能”功能之间做出选择时，你真的需要知道每个功能都需要多少时间。

为什么开发人员不制定时间表呢？有两个原因。第一：这是一件令人头疼的事。第二：没有人相信这个时间表是现实的。如果计划不正确，为什么要不厌其烦地按计划工作呢？

在过去一年左右的时间里，在Fog Creek，我们一直在开发一个非常简单的系统，即使是我们最爱发牢骚的开发人员也愿意接受它。据我们所知，它能产生极其可靠的时间表。这叫做基于证据的日程安排，简称EBS。您收集证据(主要来自历史时间表数据)，将其反馈到您的日程表中。你得到的不只是一个发货日期：你会得到一条置信分布曲线，显示你在任何给定日期发货的概率。它看起来是这样的：

曲线越陡，你就越相信发货日期是真实的。

当我看到一个以天甚至周为单位的日程表时，我知道它是行不通的。你必须把你的日程表分解成可以用小时来衡量的非常小的任务。不会超过16小时。

这会迫使你真正弄清楚你要做什么。写入子程序foo。创建此对话框。解析Fizzbott文件。单个开发任务很容易估计，因为您以前编写过子例程、创建过对话框和解析过文件。

如果你很马虎，选择了为期三周的大任务(例如，“实现Ajax照片编辑器”)，那么你还没有想过要做什么。详细地说。循序渐进。当你还没有想过要做什么的时候，你就不知道需要多长时间。

设定16小时的最长时间会迫使你设计这该死的功能。如果你有一个名为“AJAX照片编辑器”的三周手摇功能，但没有详细的设计，很抱歉我是那个打破它的人，但你是官方注定要失败的。你从来没有想过它将采取的步骤，而且你肯定会忘记其中的很多步骤。

很难做出完全正确的个人估计。您如何解释中断、不可预测的错误、状态会议以及半年一次的Windows Tithe Day(您必须在主开发箱上从头开始重新安装所有内容)？见鬼，即使没有所有这些东西，你怎么能准确地说出实现一个给定子例程需要多长时间呢？

所以，留着时间表吧。记录你花在每项任务上的时间。然后你可以回去看看相对于估计花了多长时间。对于每个开发人员，您将像这样收集数据：

图表上的每个点都是一个已完成的任务，并带有该任务的估计时间和实际时间。当您将估计值除以实际值时，您得到的是速度：相对于估计值，任务完成的速度有多快。随着时间的推移，对于每个开发人员，您将收集速度历史记录。

神话中的完美估计者只存在于你的想象中，他总是准确地做出每一个估计。因此它们的速度历史是{1，1，1，1，1，…。}。

典型的不良估计器的速度遍及整个地图，例如{0.1，0.5，1.7，0.2，1.2，0.9，13.0}。

大多数估计者对规模的估计是错误的，但相对估计是正确的。每件事的时间都比预期的要长，因为这个估计没有考虑到错误修复、委员会会议、喝咖啡休息和那个总是打断别人的疯狂老板。这个常见的估计器具有非常一致的速度，但它们低于1.0。例如{0.6，0.5，0.6，0.6，0.5，0.6，0.7，0.6}

随着估算员获得更多的经验，他们的估算技能也会提高。所以扔掉任何超过，比如说，6个月的速度。

如果你的团队中有一个新的估算员，他没有记录，那就做最坏的打算：给他们一个速度范围很大的假历史，直到他们完成了六个真正的任务。

不是简单地把估计加起来得到一个单一的发货日期，这听起来是正确的，但给出了一个严重错误的结果，你将使用蒙特卡洛方法来模拟许多可能的期货。在蒙特卡洛模拟中，您可以为未来创建100种可能的场景。每一种可能的期货都有1%的可能性，所以你可以制作一个图表，记录你在任何给定日期之前发货的可能性。

在计算给定开发人员的每个可能的未来时，您要将每个任务的估计值除以从该开发人员的历史速度中随机选择的速度，这是我们在步骤2中收集的。下面是一个未来示例：