工作量估算,用故事点还是人天?

AI智能一体化敏捷管理课8.0 敏捷项目管理暨Certified Scrum Master 中文认证课程实战培训(2天)线上 -2024年7月
2021年6月30日
Certified Scrum Product Owner 中文敏捷产品管理CSPO认证课程培训 -2024年7月-上海-敏捷产品负责人
2021年7月5日

作者:熊节 《重构》译者

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

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

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

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

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

工作量 ➗ 速率 = 时间

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

  • 你知道谁来做这个故事吗?生手和熟手程序员,速率是不一样的吧。
  • 你知道做的人每天花多少时间来做这个故事吗?外部干扰多的一周,和外部干扰少的一周,体现在每天上的速率是不一样的吧。
  • 你知道在什么时候做这个故事吗?项目初始阶段,和项目临近尾声,开发一个故事的速率是不一样的吧。

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

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

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

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

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

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

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

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

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

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

拨打免费咨询电话 021-63809913