Story Pts Vs Man Days

在敏捷实践中，故事点是用来估算故事复杂性的一个度量。但是由于各种原因，出现了另一个单位 -- 人天，顾名思义，人天用来估算一个故事卡需要一个人多少天来完成。

刚开始知道有人天的说法我是不理解的，然后我结合之前 U 内的讨论和这几天新项目的实际接触后，我仔细思考了为什么一些项目已经习惯了使用人天来估算工作量。于是有了这篇文章。

在开始之前，我默认你已经对故事这个概念有了解，我不会对此做过多介绍。

含义

故事点的本质是对复杂度的估计，而复杂度其实包含了两部分 -- 难度和工作量。

可能一个故事工作量并不大，但是难度比较大，需要处理复杂逻辑，复杂的验证等等；也有可能一个故事并不复杂，但是工作量比较大，比如一个简单的工作重复20次。这两种情况都可能使得一个故事的故事点变大。

而与之相反，人天这个估计值就很直接了，这个故事一个人做 n 天，你觉得 n 是多少，人天就是多少，简单粗暴。那么，人天真的这么简单粗暴吗？

我们来尝试揭示人天背后的故事。首先需要达成共识的是，不管是人天还是故事点，都是对某一个故事的一个估计值。

但是人天特殊的一点在于，我已经提前“预知”这个故事卡几天能够做完了。这句话咋一看没啥不妥，但是背后的逻辑值得我们深思，这个“预知”背后隐藏了许多假设：

为什么会有这些假设？道理很简单，因为当你预计一个故事 n 天能做完，那么这也就意味着不管是项目刚刚启动大家对业务和技术栈不熟悉的情况下，还是项目已经平稳运行大家已经熟悉业务和技术栈，这个故事都是 n 天做完。这显然是不合理的。

dev 同学做卡的速度受很多因素的影响：

那是不是故事点就没有这些问题呢？是的，没有。我们前面提到过，故事点是对一个故事的难度和工作量的估计，说白了就是一件工作的工作总量的度量。它压根没有体现时间，可是时间作为项目管理一个重要的指标，它从哪里来呢？

小学老师讲应用题的时候教过我们 时间 = 工作总量 / 速率

现在问题变成了速率哪里来，敏捷实践告诉我们 -- 昨天的天气。理论上同一个团队上一个迭代的速率跟现在这个迭代的速率不会相差太大，于是我们可以假设当前迭代的速率与上一个迭代相等，但通常来说一个团队的速率本来就不是一成不变的：

于是整个项目工作总量的消耗和每个迭代消耗的工作量组成了敏捷项目管理最重要的两个图表 -- 燃尽图和速率图，它们可以告诉团队到底还需要多少时间能够完成项目，或者我们还能不能在某一时间点完成项目，时间这个关键指标就被“计算”出来了。

那么为什么人天这种计量单位会出现在我们的敏捷实践里呢？我也不知道，我粗浅的理解是来自于客户的压力。

大部分传统客户其实并不在乎你做的什么敏捷，他在乎的其实是你能不能在规定的时间内交付应该交付的软件。你告诉他我们用的是故事点估算，他会告诉你我不懂你们的故事点，你就告诉我这张卡几天做完。

这时其实客户已经出现了不信任的信号，现在要做的不是科普，而是建立信任。

在这样的情况下客户一般会紧盯团队的工作量，这时团队要做的是将团队的工作量通过各种方式暴露给客户 -- 站会，和客户pair，和客户一起估点。让客户知道我们的工作量可能跟客户想象的不一样，你认为的一个迭代 20 人天的工作量可能我们尽力就只能完成 15 人天。

另一种情况是客户和团队认为的工作量是一致的，但是客户觉得这个工作量的工作不应该花这么多时间。大白话就是觉得团队能力不行，速率不够，1 天能做完的东西要做 2 天。这种情况会更加复杂，至于如何解决已经超出本文讨论的范围了，我们就不过多展开。

无论哪种情况，人天这个估算早已名不副实，要么20人天 = 15人天要么估算已经变成监督团队的工具。你可能会说，反正都是估算，那就假设估算的 20 人天等于真正的 15 人天呗。

确实可以这么搞，那为什么不在建立信任的过程中换回故事点呢，这时人天这个单位已经完全失去意义了，团队的估算逻辑，客户被养成的习惯，都被扭曲了。

跟客户建立信任确实是困难的，但如果这是一个长期客户，那么我相信这是值得的，如果想要成为客户和他们宏大志向的杰出伙伴，那么我想影响并改变客户的观念或许是我们需要走出去的一步。

最后我想说的是，这是团队中每一个人需要努力的方向。有的开发同学会说管理客户期望，引导客户不就是你 BA/PM 的工作么，为什么你做不到。在我眼里这句话跟“bug free不就是你程序员的目标么，为什么你做不到”没有什么本质区别。