团队工作量评估不准确？是方法不对！

工作量评估的意义是什么？

在软件开发过程中，工作量评估是必不可少的一步。大多数的工作量评估，采用是绝对时间，如人天、人时。这时候就会陷入小马过河的困境：究竟河水是老牛说的那样浅，还是松鼠说的那样深？

团队中人员能力、技术偏好各有不同。对大牛来说，某个Feature可能需要4小时搞定，对初级工程师，可能8小时也不够。如果按绝对时间来评估，究竟以谁的为准？按平均数？似乎总不合理。

再次，人的大脑的进化，对事物的绝对大小，总是难以估计。

我一个朋友，说去美国旅游的时候，看到一个悬崖，估计了一下大约100多米，结果别人告诉他高达900米。他作为一个很有山地户外经验的人，为何会出现如此大的偏差？答案是树。当地很多美国红杉，树木高达上百米，他的估算是根据悬崖和树的比例进行。当树的大小出现严重偏差，他的结果也就出现严重偏差了。

我们大脑对绝对值难以估计，对相对值倒是擅长。只要有一个可靠参照物，在比例不是特别悬殊的情况下，总是可以得到比较接近的结果。

但这个比例不能太大，你不能给一个细菌的重量，然后让我去估算鲸鱼。但给一颗小树的高度，去估算一栋房屋，大部分人就没问题了。

因此，用户故事点数估算的发明，解决了我们的人月神话陷阱。首先选择一个比较适中的用户故事，把他的复杂程度、工作量评估为1（也可以是其他数字）。

然后其他的用户故事，和这个基准用户故事进行比较，得出其他用户故事的点数。

由于人擅长估算相对值，而且对不同水平的开发人员，相对值是比较接近的，也不会带来人员上的偏差。那么最后，就可以得到一个比较客观的用户故事点数估算结果。

那么这个结果究竟如何转换为时间呢？毕竟，我们最后是要给出实际时间上什么时候可以完成，你给一个无单位的数字恐怕产品要揍你。

答案是经验。我们先尝试1-2个冲刺，由于每个冲刺的时间长度是固定的，在团队固定的情况下，1-2个冲刺后，我们就可以知道我们一个冲刺能做多少用户故事点数，然后用这个做预测，就可以比较准确知道我们的生产力了。

随着团队的变化、生产力提高，每次冲刺的用户故事点数可能会有波动，但会在一个相对可控的范围变动。我们因此变得对生产力比较有掌控，可以做出承诺并比较能确保完成承诺。