听 Ethan Huang 老师聊估算！

关于估算通常我们有两种方式：一种叫做绝对值估算，以估算工时为代表。另一种叫做相对估算，以故事点估算为代表。

01 绝对估算

—

先岔开一个话题说说绝对值估算中的工时。工时这个词来源于国外，其原本的英文含义叫effort，含义是说我们要花多少的努力、精力去做这件事情。举个例子来说，我们喝一杯啤酒能为我们带来多少的能量，这就是effort。但是我们在不同的场景下喝这杯酒需要的时间不同，但是喝这杯酒做的功、带来的卡路里是恒定的，也就是 effort 是恒定的。所以 Effort 其实是一个相对估算的概念。

在传统的项目管理中，我们会对整个项目继续进行WPS的拆解成任务包更多的目的是为了核算费用、成本，而不是单单为了做计划。而且用工时来估算往往是不够准确的，因为估算的人和时间做这件事情的人可能不是同一个，会带来很大的误差。

02 相对估算

—

相对估算主要原理是通过对比去得到相应的估算值。一般来说我们会选择一个参照物，然后通过其他的任务与参照物进行对比得到对应的倍数，这就是相对估算的逻辑。人类通常不善于去做绝对估算而善于做相对估算，因为比大小更容易得出准确结论。中国有一些俗语也表达了类似的观点。例如：不比不知道，一比吓一跳；人比人气死人；一山还比一山高，都是相对估算的例子。

03 估算的目的

—

估算的目的是为了在实际的项目中更好的计划。所以估算的准确性和估算的效率是我们的重要考量标准。在项目中我们需要注意估算本身是不增值的活动，切莫为了估算的精确性花费太多时间。本质上来说，因为需求的可变性谈精确似乎没有意义。

04 相对估算的操作细节

—

一般对比估算时候我们会考虑三个方面：需求的体量、需求复杂度、技术复杂度。A需求相对于基准需求而言，体量、需求和技术复杂度分别怎么样？是他的多少倍更合适？关于需求的体量，这里有一个形象的例子。例如修改文案的需求，它的技术复杂性和需求复杂性都是0，但是它涉及到非常多的文案要改，那他这个时候其实表达的是体量很大。

再来说说相对估算中的基准值确定，我们往往选择需求的体量、技术复杂性和需求复杂性都相对较低的需求。确定好基准值之后，我们把它的点数定位1，然后其他需求可以基于这个基准需求来进行相对估算了。

相对估算的方法主要包含估算扑克和T恤估算法。

关于估算扑克和T恤估算我们需要注意的是：我们估算的其实是一个区间而不是具体的值。例如：估算点1、2、3、5、8、13，当我们选择 8 的时候，其实我估算的值是在5和13之间，它并不一定明确表示是8。另外T恤的估算方法也是一样，我们估算的是区间。

另外估算扑克有一个非常大的弊端：花费时间长。一个团队通过估算扑克会耗费很长的时间去打牌，这也是实操过程中是不好落地的原因之一。 T恤估算相对还好，我们把对应的T恤尺寸列出来，然后把对应的需求放在对应的尺寸上，通过团队成员为需求轮流排序让大家最终对所有的需求的理解一致。如果需求不一致时，那我们就可以触发讨论澄清需求。

05 把需求拆分到相同大小来估算

—

无论哪种相对估算的方法在实操中都很难落地，因为大家还是很容易习惯把故事点当做人天来进行估算。所以更好的方法是通过需求的个数来进行估算，也就是将需求拆分到相同大小，我们只需要数需求的个数就可以了。具体的实践通过用户故事拆分的方式将需求都拆到相对一致的大小。那如何保证大家是相对一致呢？可以通过验收条件的个数来进行判断。

写在最后

—

最后说说我听完之后的一些感想，如果是临时的项目团队，成员不稳定，没有办法通过历史数据拿到团队的速率，那相对估算其实也没有太大意义。如果我们有稳定的团队，那这个时候教会团队相对估算的方法其实是很有意义的，因为它能帮助我们快速的去进行估算、做计划节省很多的时间。

另外我觉得在迭代开发的过程中，除了相对估算还需要去拆分任务做工时的估算。因为技术栈的不同、人力分配的不同，很难保证说我们的计划能符合团队的实际现状。而打造一个学习型组织，能相互back up 的团队需要更多时间。