在scrum中,整个团队参与估算过程,因为具有不同才能的团队成员可能会提出其他团队成员不会意识到的故事的各个方面,这可能使故事或多或少比最初想象的复杂。然而,让很多人对每一个故事和任务的输入都是一个繁琐的过程。Scrum专家将估算过程变成了一个名为“计划扑克”的游戏
有效估计是软件开发人员在工作中面临的最严峻挑战之一。无论团队规模如何,他们都需要在整个团队中定义、估计和分配工作。随着团队变得越来越大,围绕计划和评估工作建立良好习惯变得更加重要。缺乏计划和评估会降低对项目的信心,破坏团队与业务之间的关系,并使每个人的发展更加困难。
群体估计与个体估计的准确性
根据一些关于软件项目实验中个人和群体之间努力估计准确性的研究。来自同一家公司的 20 位软件专业人员分别估算了实施同一软件开发项目所需的工作量。参与者有不同的背景和角色,软件项目之前已经实施过。之后,他们组成了五个小组。每个小组通过讨论和组合他们之间的知识,就一个估计达成一致。
什么是计划扑克?
计划扑克(也称为Scrum扑克)是一种基于共识的游戏化估算技术,主要用于估算软件开发中开发目标的工作量或相对规模。
规划扑克的步骤
- 要开始扑克计划会议,产品所有者或客户需要阅读敏捷用户故事或向估算人员描述一项功能。
例如:
“客户登录预订系统”
“客户输入酒店预订的搜索条件” - 该组的团队成员通过将编号牌面朝下打到桌子上而不透露他们的估计值来进行估计(斐波那契值:1、2、3、5、8、13、20、40)
- 卡片同时显示
- 然后讨论估算值并解释高估和低估算
- 根据需要重复,直到估计收敛
通过以这种方式隐藏数字,该小组可以避免锚定的认知偏见,其中第一个大声说出的数字为后续估计设置了先例。
敏捷估计——相对与绝对
估计只不过是有根据的猜测。我们利用手头的所有知识和经验来猜测将要花费的时间。因此,与其单独查看每个新工作项,不如将其与之前完成的工作项进行比较?人类更容易将相似的物品联系起来,而不是猜测事物的实际大小。
例如,它是否更接近这个非常小的东西?还是更像这个正常尺寸的物品?还是真的像我们上个月完成的那件作品一样巨大?进行相对估算不仅会减少估算工作所花费的时间,还会大大提高估算的准确性。
我们的大脑无法进行绝对估计;我们总是把我们需要估计的新事物与我们已经知道的事物联系起来。
斐波那契数列和规划扑克
Planning Poker 使用斐波那契数列为特征或用户故事分配点值。斐波那契数列是 13 世纪引入的一系列数学数字,用于解释自然的某些形成方面,例如树木的分枝。该系列是通过将前两个数字相加得到序列中的下一个值来生成的:0、1、1、2、3、5、8、13、21 等。
出于敏捷估算的目的,一些数字已被更改,产生以下系列:1、2、3、5、8、13、20、40、100,如下图所示:
分配给扑克牌的点数的解释如下表所示:
牌) | 解释 |
---|---|
0 | 任务已经完成。 |
1/2 | 任务很小。 |
1, 2, 3 | 这些用于小任务。 |
5, 8, 13 | 这些用于中型任务。 |
20, 40 | 这些用于大型任务。 |
100 | 这些用于非常大的任务。 |
<无限> | 任务艰巨。 |
? | 不知道完成这项任务需要多长时间。 |
<一杯咖啡> | 我饿了? |
估计中的点与小时值
那么为什么要使用故事点而不是时间值呢?故事指向使团队能够专注于交付工作所涉及的复杂性和时间。团队将新工作与他们已经完成的工作进行比较。他们将新任务的复杂性与过去的挑战进行比较,并对难度和所需时间进行排名。
例如,我们通常不考虑“开展业务的成本”。具有时间价值的会议、电子邮件、代码审查等。但实际上,这些都是我们日常生活中必不可少的做法,但实际上并不能算作“工作”。故事点将软件开发工作与相关的后勤工作项隔离开来,因此使用基于点的估计应该比基于小时的方法更一致。