对于故事点的一些理解

在敏捷开发框架中,我们常用故事点来做估算,并用它来表示一个用户故事(User Story)所需要的工作量。有别于人天、功能点,故事点(Story Point)是一组没有单位的组合,是一种相对性的度量方式。它很抽象,也很颠覆,但它让团队实现对于完成一个任务在“难度”方面的估算。而这里指的”难度“包含了”复杂度”(Complexity),”风险”(Risk),”不确定性”(Uncertainty)和”工作量”(Effort-E)。

相对估算

看一本600页的书需要多少时间?

如果这是一道小学数学题,那么假设阅读速度是2页/分钟,看完600页的书需要300分钟(5小时)。简单的一个工作量(Effort)计算问题。

如果这个问题是工作中的场景。产品负责人问你,看完这份600页的文档需要多少时间?你脑子里一定会追问,什么类型的文档(这关系到复杂度)?我是否能有连续的、不受干扰的时间(这关系到风险和不确定性)?或许你还会追问,我看完就可以了吗?需要理解到什么程度?需要出份报告吗?(这还牵扯道完成定义的话题)

当然你可以告诉产品负责人,排除所有难度因素,理论上的估算是5小时。那么请问一周40小时的工作时间你能承诺看完几份600页的文档呢?显然不可能是8份吧。

同样是这个工作场景,如果我们换一种相对估算的方法。去回忆之前类似的阅读文档的经历,你脑子里会出现一堆“难度”因素的感觉,从而给出一个笼统值,例如5天。以此来作为此次任务的参考点,从而判断这一次可能需要相似的时间,或是更多,还是更少。

如果从来没有做过类似的工作,从而没有任何参考来做相对性的估算呢?那不如赶紧给个让你自己信服的值,然后开始工作来验证它。完成后做回顾和调整,并使其加入你的“参考值库”。

没有单位的阶梯

当有了参考值后,我们需要一个大家公认的”阶梯“,来对号入座地放置那些相对估算。

如果对于拼完一副500片(50cm*70cm)拼图的估算是5,那么拼完1000片拼图的估算是5+1?5+5?还是5+10?

其实都不重要。在一个敏捷团队中,只要所有人对于估算方法的认知是统一的,那他们可以使用任何介质来表示估算。只要是其能区分大小信息即可。例如,

  • 1, 2, 4, 8, 16
  • 1, 2, 3, 5, 8, 13 (费波纳切数列)
  • XXS, XS, S, M, L, XL, XLL (T恤尺寸)
  • 蓝莓, 葡萄, 苹果, 菠萝, 榴莲 (前提是所有人都知道榴莲是什么:))

为什么没有单位呢?原因很简单,因为复杂度,风险和不确定性没有单位。如果判断工作中含杂着”难度“因素,那么我们用精准单位(例如分钟,人天)来估算工作量就一定是不精确的。既然是不精确的,何不含糊一些,去了单位这个约束呢。

自己的货币

这个时候你的客户或许已经排案而起了:”我让你添加一个登陆功能。你说消耗一个菠萝!请问我能用一个菠萝的市价来支付你吗?”

好吧,事实上带有幽默感的客户还是挺容易沟通的。

我常碰到一种情况就是,经理、客户、甚至是产品负责人,不能把手里的交付物和故事点关联起来。拿客户举例,他使用了你交付的登陆功能且颇为满意。为了便于结算,你告知这件事花费了2个人天,而没有说明在团队中的估算是一个菠萝。久而久之,就会闹出上面那样的笑话。

相反的,如果我们每次都把团队的估算方式和”外人“分享,使其不再只是项目组内流通的语言。那么在整个干系人链路中,会建立起一些效应:

  1. 剥离了时间单位,弱化针对准确性产生的纠纷
  2. 时间的度量承载到了更为抽象而简明的划分上,便于分类和做决定
  3. 将用户体验直接映射到了团队估算。一个习惯用”菠萝“理解登陆功能的产品负责人,会觉得查询功能不值一个”榴莲“

这些效应让我联想到了货币。

你愿意用2元钱买一瓶水,有时是坐一次公交,或者是包一个微信红包。你愿意花这个2元钱,不是因为你精心计算过其成本,而是因为你的体验在告诉你这很值!

 

Leave a Reply

Your email address will not be published. Required fields are marked *