不管在敏捷项目还是在常规瀑布型项目中,都需要对某一功能进行工时评估,从而得出时间、资源,推导出成本、ROI(投产比)等,那怎么能够更准确、更快速的估算具体功能的工作量呢?计划扑克是一个非常实用的好方法;
以下谈论的主要是以敏捷项目为例;
计划扑克算是PMP里估算活动中的类比估算,可以移步持续时间估算方法,主要是通过以往经验,针对与待开发功能相似的功能的开发量来预估需要占用的资源;
具体步骤如下:
-
准备一副或多副牌(如果够多人的话)
planning poker可能会有几个小疑问了?
-
poker上的数字代表什么?
poker的数字反应了被评估功能或任务的大小(资源、工时),并没有具体的单位(人、天、小时),这个单位建议是故事点(story point),数字代表了多少个故事点;
- 0: 不需要任何工作量;
- ?: 需求没有理解很透彻,无法准确评估;
- 100:任务量好大,好难评估,需要细化;
- ∞ :比100更严重,无法评估,亟需细化才能估算;
- coffee: 我太累了,脑子转不动了;
-
故事点(story point)是什么?
故事点,是在Scrum敏捷开发过程中使用的概念,代表某一开发团队所推选出来的抽象的标准单位工作量。它是相关成员都熟悉的的独立并且简单的全部工作。
举个例子:针对于前端开发,一个系统的登录页面开发可以做为一个故事点,包括:页面的UE设计、页面UI设计、页面的前端开发、前端与后台的联调工作等; -
为什么数字类似于斐波拉契数列
我们在知道故事点的概念后,它做一个单位基准,Poker上的数字代表了多少个单位的故事点;
斐波拉契数列的排序是为了更好的需求任务的量,试想,1和2是好分辨,2是1的两倍的量,那8和9,或者15与16,他们的之间的差别,大家该如何分辨呢?
-
-
产品经理讲解需求or任务;
相关or任务(用户故事)需要满足可估算的条件(可以参考问题14,面试问题),否则没有太大意义; -
所有相关人员同时出牌;
-
查看所有人员的出牌数字:
- 估算接近:取平均值,或是对业务/功能最熟悉的人员的估算,结束;
- 估算差距较大:最低&最高估算人员阐述观点;
-
差距较大的重新评估,最多三轮,结束。
计划扑克是一个非常好的小工具,在需求的评估阶段,能够让每个团队成员都能够参与起来,并且“无废话”的阐述自己的观点,如果运用得当,并且相似性较高,则可以大大提高早期工作量评估的和排期的效率,甚至准确率。
对于那些100,∞的计划,作为Project Owner或产品经理一定要与团队成员一起沟通,不断细化需求,直至可以拆分为多个足够详细、足够小、足够评估的需求,再评估。
网友评论