Scrum实践系列之一:工作时间打扑克?--谈谈扑克估算

不知道是不是因为勾起了大家的牌瘾,最近一阵"扑克"估算很是火了一把,在几个项目尝试后很快蔓延开来,很多项目团队都跃跃欲试。

尝试的过程中难免产生一些困惑,干脆在这里做个澄清,把我实践下来所理解的扑克估算的方方面面跟大家一一道来。

 

在开始之前,首先需要澄清的是,在某种程度上,估算其实是在预测未来!

预测未来是件非常难的事情,我们看看天气预报,就知道人类在这项工作上有多么滴不靠谱了。

 

为什么要做估算?

估算本身很困难,而花在估算活动本身上的时间,又并不能够对产品本身产生直接的价值,那么为什么我们要花时间做估算呢?为什么气象中心还是坚持不懈的发放自己的预报呢?

首先,用户需要一个预期,甚至是承诺,这个功能什么时候能够提供。

其次,管理层需要可预测性,某些决策需要基于估算而做出,即便这个估算还不那么准确,但总是聊胜于无。

最后,团队需要了解如何相互协作,在哪个时间点能够拿到我所需要的接口或素材,据此相应的规划并安排自己的工作。

总之,估算可以帮助我们找到一个合理的计划,给用户、管理层、以及团队自己一个稳定的预期。

 

为什么选择相对估算?

传统的估算方法,通常是基于人天/小时的绝对估算。而敏捷中所推荐的扑克估算方法,则是基于故事点的相对估算。这种估算一上来容易让人找不着北,大家会习惯性的问:“那这个故事点到底代表什么?单位是什么?做完了相对估算是不是还要再转化为人天?与人天的对应关系又是什么?”

讲清楚这一系列的问题,我们需要先搞清楚,为什么选择相对估算。相对估算有哪些好处呢?

首先,相对估算更符合人的本能认知。电脑区别与人脑的一大特点,就是电脑更擅长计算与处理绝对信息,而人脑则对相对印象更有感觉。我们可能永远搞不清楚手上的核桃和苹果的真实重量,但却能很直观的判断出苹果更重,重量嘛,大概相当于“6个核桃”。瞧,这就是人类的本能认知。

其次,正是因为相对估算更符合人的本能认知,因此掌握之后,它能让估算过程变得更快更简单。因为我们不再需要纠结于这个任务到底需要5天还是4.5天,我们只需要为手头的工作定义一个参照物(“一个核桃”)作为基准,然后拿其他的工作与之相比较,工作量是更大了还是更小,复杂度是更高还是更低,然后给出一个大约的倍数值就done了。

 

相对估算需要转化为人天吗?

在实施scrum的项目团队中,最后得出的故事点的数值,不需要再转化成人天,这是由scrum的特性所决定的。

在scrum项目中,我们会以sprint为周期来做增量交付,这直接改变了做计划的方式。传统项目中,我们需要根据基于人天的估算来确定各节点及最终发布的日期到底是几号;而在scrum项目中,周期是事先约定好的,每个sprint的计划不需要确定日期,而只需要估算下一个sprint我们能完成多少工作。由于sprint固定周期性的特点,在几个sprint之后,我们就会得出一组相对数据(比如35个story points),来衡量团队的生产效率。根据这个生产率,我们可以很容易的快速进行相对估算,不需要转化为具体人天就能得出结论。

当然,如果你是第一个sprint,没有经验数据的情况下,可以尝试转化为人天找找感觉,或是直接根据团队的直觉来做出判断。

如果你是在传统项目中做扑克估算,那么我的建议是可以直接用人天来进行估算,虽然不如相对估算那么便利,但至少还是获得以下的好处。

 

扑克估算有什么好处?

  • 团队一起做估算,估算更全面细致

传统的项目管理中我们也会做估算,WBS分解后完成任务分配,然后每个人估算自己的,如果每个人只对自己的那块比较熟悉的话,估算结果往往会有欠考虑,特别是针对相关性较强的模块,会出现较大误差,从而为项目后期埋下潜在风险。

在扑克估算时,一开始我们特意不进行任务的分配,对于每一个故事,都会由全员出牌,包括各个模块的开发及测试,每个人从自己角度出发想问题,互相补充。比如在扑克估算时,测试的成本会被自然地考虑进去,作为一个整体来衡量,对于测试成本高的story,大家会一同来考虑进行哪个层级的测试会更为合适,单元测试?API测试?还是UI测试。这样涵盖了各方成本的估算结果自然会更全面、更细致。

  • 团队一起做估算,需求探索更深入

实践中我们会发现,真正到了让你给出预估的时候,就会有各种各样的问题冒出来。这个需求到底要不要做这个,是否要满足那个条件,等等,扑克估算让这个需求探索的过程公开化,通过公开的讨论在早期进一步挖掘和明确需求,帮助我们将需求探索进行的更为深入。

  • 团队一起做估算,有助于优化解决方案

大家在一起亮牌,经常会有不一致的情况出现,比如一个人出5,另外一个出40,这个时候往往是团队成员间交流解决方案的好时机。问问你的团队,为什么相差这么远,这样的讨论能够帮助大家找出最优的解决方案,并在团队中迅速共享。


如何进行扑克估算?

敏捷扑克估算这篇文章中,配合实例有非常形象的说明,在此就不再赘述了。


后记

在这篇文章成文三年多以后,回顾自己亲身经历及旁观的大小项目,关于估算及扑克估算又有了新的认识。在实际实践过程中,很多项目都尝试过文中所述的这种扑克估算方法,由于其形式新颖活泼,引入时普遍广受欢迎,也确实带来了如上所说的种种好处。可以说,扑克估算让各个角色围绕时间预估,增进了彼此之间的沟通对话,将潜在的冲突公开化台面化,就是让大家去充分碰撞,然后用一种近似游戏化的方式再去化解掉,这可以说是扑克估算最为精髓的地方。

但,同时我们看到,在长期演化过程中,能坚持一直用扑克估算的项目少之又少,多半新鲜阵儿过去就走回老路,怎么简单怎么来。是不是扑克估算终究是花哨大于实用呢?实际倒不尽然,说到底,所谓的扑克估算,只是一种估算的招式而已,所起到的作用并不只是为了得到估算结果,而是其带来的种种附加效应。

而至于这些招式,用在什么样的场合,发挥什么样的作用,则完全取决于修炼者自身的把握。用不好,会觉得不过就是花拳绣腿;而真正用着好的,则会慢慢将招式内化。我所见到的一个团队,在尝试扑克估算一段时间后,逐渐形成了估算会议上多方碰撞的传统,然后渐渐的他们发现自己不需要扑克了。因为一旦这种对话机制建立起来了,没有这个道具的参与,对话也能正常进行。虽然最终看起来似乎并没有坚持做扑克估算,却已是内化了其精髓。

以上就是目前我对于扑克估算这个话题的简单认识,希望对各位看客们有所帮助~


系列文章导读

Scrum实践系列之二:我们怎么开每日站会?

Scrum实践系列之三--敏捷教练的5步修炼

评论 ( 1 )

© ID211326 | Powered by LOFTER