工作量估算，用故事点还是人天？

作者：熊节《重构》译者

这已经是超级老生常谈的一个话题了，然而还是被不断地提出来，所以我终于决定写篇文章，一劳永逸地解决这个问题。这个总有人的问题就是：

估算工作量，到底应该用「故事点」作为单位呢，还是应该用「人天」作为单位？

每次聊这个问题总会有人说，方法没有对错~两种都可以~看团队情况~blahblah。我觉得有必要正一正视听：这不是「没有对错」、「都可以」的事。用故事点为单位估工作量，是正确的做法；用人天为单位估工作量，是错误的做法。对错都分不清，还怎么聊下去。

为什么说用故事点为单位估工作量是正确的做法？因为「工作量」按照定义就是一个「量」的概念，而不是「时间」的概念。我们用得最多的一个例子：搬一千块砖，就是搬一千块砖的工作量。搬得快，它是一千块砖；搬得慢，它还是一千块砖。工作量的大小，是与时间无关的。

那么工作量如何与时间产生关系呢？很明显，通过「速度」这个概念。同样搬一千块砖，建筑工人每分钟搬20块，50分钟搬完；大学生每分钟只能搬10块，那就100分钟搬完。知道了速度，才会知道时间。这都是中学物理就学过的知识。

工作量 ➗ 速率 = 时间

所以为什么说用人天为单位估工作量是错误的做法，对着公式一看就很明白了：在估工作量的时候，你如何知道速率？

无法确定速率，你要如何用人天为单位估工作量？

然后下一个问题接踵而至：但是老板需要知道项目能否按时交付。项目要在10月1日之前上线，你不按人天估工作量，只有一个「1800故事点」的估算，怎么知道能不能按时上线？

答案很简单：昨天的天气。你只要跑两个迭代，就会知道这个团队的速率。用总体工作量除以团队速率，你就得到了预期交付的时间。还是初中物理嘛。

项目总体工作量 ➗ 团队速率 = 预期交付时间

然而，这个简单的公式，会告诉我们另一些重要的信息。比如说，为什么那么多团队仍然直接用时间来估工作量呢？为什么他们认为「以故事点为单位」和「以人天为单位」是没区别的呢？

因为他们假设速率是常量。既然速率是常量，那么工作量与时间就始终成正比，所以用哪个为单位来估算都没区别。

这个看似不起眼的假设，背后其实是一系列重要的观念：

程序员都是可替换的「人力资源」，A程序员和B程序员是没区别的，生手程序员和熟手程序员是没区别的，这个程序员离职了马上去大街上招一个，对速率也是没有重大影响的。
程序员是不会成长的，在项目启动阶段的速率是这样，做到项目结尾时，速率还是这样，程序员并不会在项目过程中收获经验和技能，程序员的速率不会因为知识和熟练度的增加而提高。
团队的环境是无关紧要的，团队成员彼此协作的方式要么不可能有任何改变、要么这种改变不会对速率产生任何影响。

只有当这些观念在脑中根深蒂固时，或者再说白一点，只有预设了程序员就是机器上无差别可替换的齿轮时，一个团队、一个公司才会认为：软件开发的速率是一个常量，因此工作量估算用故事点为单位还是用人天为单位都没区别。

所以，正如我经常说的，敏捷中的众多小问题，都见微知著，都映照出领导、团队、公司看待软件开发这件事、看待软件开发者这群人的价值观。把软件开发者当人、当重要的知识工作者看待，你会得到一种答案；反之，你会得到另一种完全不同的答案。