敏捷实践系列之二:规划扑克估算

敏捷规划扑克

Planning Poker

规划扑克是一项基于群体智慧、用于估算用户故事的工作量或相对规模大小的技术。其目标并不是一定要得出一个绝对正确、无可争辩的估算值,而是以快速且经济有效地的方式,比如利用群众的集体智慧,通过团队协作,得出一个大家一致认同的估算结果。

规划扑克的来历

玩过规划扑克的同学都知道,规划扑克玩起来非常有意思。其实规划扑克来自于项目管理中广为流传的专家估计法(Expert Estimation)、德尔菲方法(Delphi)和宽带德尔菲方法(Wide band Delphi)。

专家估计法

项目管理往往需要对某项工作进行估计,确定相应信息后进行管理。而得到这些的最简单方法,某过于找个人大致估计一下。对于某一项工作,其预期工作量、成本花费、工期时间等项目管理所需的必要信息,要对其进行估计,行业或领域专家(SME)以其具有的丰富经验、知识、技能和见多识广的经历,往往更有发言权。因此,专家估算法成为项目管理中最基本的项目信息估算方法。

专家往往会根据某项具体工作的性质、特点、复杂度等已知因素,依据自己的个人经验、所学过的知识、所拥有的工具和以往项目的具体情况,对该项工作的工作量、成本花费、具体工期时长等信息,做出较为可靠的估计。

但专家估算也有其缺点。其一,每一次项目都是不同的,外界条件、资金限制、组织因素、技术因素等经常发生变化,因而,依据过往已知项目信息得出的估计,往往与当前情况具有不同程度的偏差。其二,受限于专家的精力、能力、经验、知识等因素,专家对每个项目情况的估计也会出现偏差。其三,人人都会心存偏见,专家也不例外。

因此,要预防一个专家的估算出现较大偏差,你自然会想到,多找几个人来估算,然后求他们估算结果的平均值不就好了。

这就是德尔菲方法。

德尔菲方法

德尔菲方法的具体起源已经不可考。我们就来讲讲德尔菲方法的具体玩法。

多个专家来估算,聚在一起,吵吵闹闹、熙熙攘攘,最后得到的结果,八成不会让你满意。因为他们很可能会相互影响,或者某个专家非常强势,抢夺了估算会的话语权,其他人都没有机会发表自己的见解,或者发表了也被某些强势的人有意或无意地忽略掉了。而最后得到的结果也只能算是一言堂式的结论。

你自然不会满意。你也自然会想到,让他们各自单独地进行估计,而你来汇总结果就好了。有什么问题,再单独给他们反馈,让他们做出修改。这就是德尔菲方法的基本原理。

简单总结德尔菲方法,其过程如下:

  1. 估算协调者整理出一份功能说明(或问题陈述),并列明估算结果表格。
  2. 每名专家收到一份功能说明(问题陈述)和一份记录估算结果的表格。
  3. 专家们独自匿名地填写估算表格。专家们可以向协调者提出问题,但彼此之间不能讨论估计情况。
  4. 协调者把专家们的估算结果汇总整理到一个表格中,将综合意见反馈给各位专家,并给出新一轮估算迭代的具体信息,请求开始新一轮的专家估计。
  5. 专家们根据新一轮估算的具体信息,匿名地填写估算表格。
  6. 专家们反复迭代3到4次估算,直到达成充分一致的估算结果。在达成一致估算结果之前,不允许专家们彼此讨论。

你可能会问,为什么不让专家们进行讨论?主要还是为了预防相互影响,或者估算被某个强势或颇具权威的专家左右。

相比起来,德尔菲方法得出的估计结果要比某一个专家估算得出的结果可靠得多。

但德尔菲方法也有其缺点。德尔菲方法不能为专家们提高足够宽的沟通带宽来交换必要数量的信息,以便与其他估算参与者校准他们的估算。

因此,可以对德尔菲方法进行必要的修改,让专家们彼此之间获得必要的信息沟通的渠道和信息共享的方法,以允许进行必要的信息交换,这种新方法就是宽带德尔菲方法。

宽带德尔菲方法

宽带德尔菲方法的具体变化有很多种,其中通用的步骤汇总如下:

  1. 估算协调者整理出一份功能说明(或问题陈述),并列明估算结果表格。
  2. 每名专家收到一份功能说明(问题陈述)和一份记录估算结果的表格。
  3. 协调者把各位专家召集在一起,集体开会。
  4. 协调者主持小组会议。在会上,专家们与协调者及彼此讨论该问题陈述。
  5. 专家们匿名地填写估算表格。
  6. 协调者把专家们的估算结果汇总整理到一个表格中,并请求开始另一轮专家估算,但不会给出估算所需的具体信息。
  7. 协调者再次组织小组会议。在会上,大家集中讨论各位估算不一致的地方。
  8. 专家们再次匿名地填写估算表格。
  9. 协调者和专家们重复迭代5到6次估算,直到得到充分一致的估算结果。

你或许会问,在讨论会上,专家不会受别人的影响吗?答案是,会。但每次估算给出的结论是各位专家自己独立判断的结果,是相互独立的。而后的讨论,会进一步明确彼此判断中不一致的地方,暴露出各自的疑惑和疑问。进一步的讨论让大家对具体的问题更加明确,理解更加深刻,因为进行独立判断的可能性更大。

而且,这种方法的效率很高,通常到第二轮或第三轮,就能到达一个大家一致认可的最终结果。所以,广为流传。

规划扑克法

在敏捷软件开发中,常常需要对用户故事进行估算。你也许会想到了,使用宽带德尔菲方法,既能够快速高效地得到估算结果,又能保证团队成员对用户故事的背景知识、涉及范围、实现复杂度、技术难度等信息有了更加深刻的理解。

这就是规划扑克。

把宽带德尔菲方法中的协调者替换为敏捷项目中的Scrum Master或PM,把各位专家替换为软件研发团队的成员,把要估算的问题替换为用户故事或任务,把估算表格替换为扑克牌,把估算结果转换为用户故事点(User Story Point),这就是典型的用户故事的规划扑克估算法。

一般的规划扑克由54张扑克组成,其中52张扑克分为4组,每组扑克的数值由如下类似于斐波那契数列或指数数列的数字组成。

?,0,1/2,1,2,3,5,8,13,20,40,100,∞(无穷大)或(一杯咖啡)

?,0,1/2,1,2,4,8,16,32,64,100,200,∞(无穷大)或(一杯咖啡)

CrispPlanningPokerDeck
图片来自维基百科。https://en.wikipedia.org/wiki/Planning_poker

怎么玩儿?

因此,规划扑克估算法的具体过程如下:

前提:所有要估计的用户故事都已经写到了卡片上。Product Owner(产品经理)就位。

  1. Scrum Master或PM召集研发团队的各位主要成员开会。
  2. Product Owner 或产品经理,具体、深入、仔细地讲解用户故事的具体细节。团队成员有不明白或疑惑的地方,可以随时向PO或产品经理提问。
  3. Scrum Master要求参与估算的成员,考虑具体的估算数值,并选出自己的扑克牌,牌面向下扣在桌子上。
  4. Scrum Master在所有的估算者都选出了自己的估算扑克之后,喊出口号“开”。
  5. 估算者一起翻开自己的估算扑克,亮出自己的估算结果。
  6. 如果大家的结果不一致,大家可以讨论,说出自己估算的依据、考虑的方面等。通常是给出最大值和最小值的两个人先表达自己的意见和看法。
  7. 然后,各自收回估算扑克,在Scrum Master的带领下,进行第二轮估算,给出估算结果。
  8. 团队继续迭代,直到得到充分一致的估算结果。或者Scrum Master询问极少数数值不同的团队成员是否认可大多数团队成员给出的结果。
  9. 如果认同并接受,则估算结束。最后结果就是大多数团队成员给出的结果。
  10. 如果不认同,则要继续讨论、估算。或者,由Scrum Master最终决定估算结果。
  11. 把估算结果写到对应的用户故事卡片上。
  12. 选择另一个要估算的用户故事卡片,从步骤#2开始进行估算。

记住,敏捷估算的目标,不是得出一个绝对正确、准确无误的结果,而是通过敏捷估算,让团队成员充分地讨论、理解用户故事,使整个团队对于用户故事的具体细节、背景、技术难度、实现复杂度等拥有一致的认识和理解。

记住,故事点并不是时间的单位,它们都是相对规模,没有单位。随着规模数值(数字)的增加,估算中的不确定性(Uncertainty)也随之增加。估算结果中包含了用户故事实现的不确定性

而且,这只是个估算结果,不要求100%的准确。随着项目的深入,大家的理解会更加深刻,学习和了解的相关知识会更加广泛,对用户故事的理解和认识也会有所不同。

谁来参加?

大家经常会问,谁来参加规划扑克估算?简单地说,Scrum Master、PM、Product Owner(产品经理)、团队核心成员或任何参与这项工作的外部团队成员均可参加敏捷规划估算会议

但受限于扑克牌的数量,能够参与估算的,可能只是团队核心成员等“猪”类角色。其他参会者,可以参与讨论,提出疑问,给出见解和认识,但不能给出估算结果。也不能影响团队成员的估算结果。

规划扑克的价值

通过参与规划扑克游戏:

  1. 团队可以有效地避免相互影响,仅凭听到别人的某个数字就给出结果。
  2. 团队参与讨论,对要估算的用户故事会有更加深刻的认识、理解和学习。在团队中,对用户故事能够形成相对一致的看法和见解。
  3. 规划扑克迫使团队成员独立地思考,充分运用各自的知识、能力、经验、技术等独立条件,客观、独立地给出估算结果。
  4. 显示团队成员之间的差异,暴露大家对当前用户故事的不同看法和见解。
  5. 估算包含了不确定性,是对项目风险的容忍和接纳。

小提示

  1. Scrum Master可以掌控估算会议的进程,在必要的时候,果断终止不必要的讨论和偏离主题的争论。
  2. 对于不在一起的分布式远程团队,可以考虑使用视频会议来进行估算。或者在线视频工具,或者在线协作工具等收集大家的估算结果。
  3. 要考虑不同时区的远程团队之间的时间差异。

最后,我们不妨再扩展开来想一下,跳出敏捷思维的桎梏,考虑一下如下问题:

  1. 规划扑克只能用于用户故事估计吗?别的工作事项可否用规划扑克来估计呢?
  2. 规划扑克估算法,只能用于估计用户故事吗?可否用来估计别的项目信息呢?

答案自己考虑哦!或者也可以留言或者给冰块发邮件,一起讨论如何更大范围地使用规划扑克估算方法。