循证式日程规划 (Evidence-Based Scheduling) 1：基本概念

Evidence Based Scheduling

EBS 2.0

循证式日程规划（EBS）是著名博客Joel on Software中提出的一种用时预测的方法。其目的就是在给定一系列的历史数据（包括估计用时及实际用时）的条件下，根据估计用时计算可能的实际用时发生的概率。EBS被整合在FogBugz中，但我们没有必要为了EBS去搭建一个FogBugz服务器，因为原理很简单，大可以自己实现一个（因为市面上并没有单独的EBS程序，因此这个轮子值得一造）

首先是EBS的逻辑，从输出输入的角度看，最简单的EBS输入是一组历史记录，每一个记录包含如下内容：

• estimateHours: 预估耗时
• actualHours: 实际耗时

当记录足够多时，我们就可以计算出预估耗时和实际耗时之间的偏差率发生的概率。对于现实世界而言，大多数人的偏差率都非常的稳定（House大叔会说People don’t change），对此，Joel的评述如下

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, …} 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} 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}

但是随着经验的积累和内力的提高，我们还是可以不断的提高估算的准确率，也就是说太古老的历史记录可能不如最近的记录管用：

As estimators gain more experience, their estimating skills improve. So throw away any velocities older than, say, six months.

因此，对于记录还要加上一个日期参数来计算权重。当然，还可以加上任务的简单描述，或者可以加上任务的类别（不同类别的任务估算误差也会不一样吧）。

OK，至此，我们可以做出大致的设计。首先有一个叫做History的类用来记录历史任务的信息。然后有一个叫Estimator的类，其输入是一组velocity/weight，输出是……

输出有些复杂，因为显然不应该输出一个概率计算公式，也不能输出一百万个蒙特卡洛模拟结果给最终用户，那怎么办呢？在这里，我们必须放弃精确的Digital输出模式，转向Analog输出模式，告诉用户“有68%的可能在16小时内完成；20%的可能在10小时内完成……”。OK，也就是说，在不同的用户界面上可能会有不同的精度，不同的表述等，那么这就是view的任务了，Estimator的输出将是那一百万个模拟结果……杯具ing，然后通过一个叫SimplePresenter的类来输出CEO们可阅读的结果。（让CEO们读懂这类东西是绝对的挑战，不说了……你们懂的）。

等基本结构完成后，可以加上任务的分类或支持不同的用户来锦上添花或是狗尾续貂（通常都是续貂的），或是加上不同的权重计算策略等，那就是后话了。

设计完毕，开工。

Technorati 标签: EBS, Scheduling, PM