扫码阅读
手机扫码阅读

听 Ethan Huang 老师聊估算!

235 2023-08-26

10月9日在线上听了 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 的团队需要更多时间。

想要了解更多,点击 查看原文