规模调整和估算值概述

为了理解规模调整和估算的概念,您应了解:

相对大小与时间估算

估算不需要非常准确,但是需要保持一致。我们的速度会更正不准确的估算。对情景的估算是相对于对情景的其他估算而言。当工程师考虑估算时,他们需要将该情景与过去的其他情景进行比较,以便保持评估的一致性。

分数规模调整有助于您获得更多可预测的业务结果

人们通常擅长比较大小,但是并不擅长估算绝对值。1 和 2 之间的差异并不明显;但是 1 和 5 之间的差异却非常明显。

如果为某个情景分配 3 分,在附近找到 1 分的情景,然后评估此情景的复杂性是否为较小情景的 3 倍。这种方法称为三角化,对于确保一致性非常关键。通过计划定期执行此操作,特别是对于生成讨论和不一致的情景。

有助于将附近的一组情景进行比较。您可以在计划区域创建分数信息板。在此信息板上,列出为其分配的若干先前情景和估算。尝试为每个可能的估算分配一个或两个情景。进行计划时,可以记录情景 A 情景 J 分别是 5 分。这些情景在复杂性方面接近一致吗?

您希望您的分数强制进入存储桶,并且它们之间有足够宽的差距,不需要对不明显的差异进行争论。Mike Cohn 建议使用类似 Fibonacci 的序列 (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) 或二进制序列 (0, 1, 2, 4, 8, 16, 32, 64, 128) 以确保存储桶的合理性。

在为情景分配分数时,您应考虑三个基本因素:复杂性、努力程度和怀疑。

即使有一点点不方便,也要与整个团队进行估算。使用计划扑克牌或使用估算信息板应用程序。

鼓励您的产品所有者在估算之前拆分较大的情景。

估算信息板应用程序

启动时,所有未估算的情景都显示在左侧的列中。团队起立并依次选择,每次移动一张卡片。团队保持移动,如果有大量分歧,一部分人可以就此讨论,而其他人则继续对卡片排序。远程团队成员也可以参与。

使用此应用程序比计划扑克牌更快。它还有助于强调相对的规模调整工作量,因为目标是将类似规模的项进行分组,而不是分配数量。

分数与小时数

传统团队将以一种单位类型估算其所有工作。然后,这些团队在纳闷估算失败的原因以及竭尽全力获取更准确的估算结果方面花费过多的时间。许多团队能够通过两个不同的估算刻度(分数和小时数)来避免此情况。

产品积压工作中的用户情景应以其相对规模进行评估。在按照以下类似方法对产品积压工作进行编号后,您可以通过将每个已接受情景的数目相加来测量每次迭代时完成的单位数。时间久了,如果保持团队的完整性,此速度数目将会稳定。如果您的速度在过去大约是 15,如果团队保持不变,您可以预测将在每次迭代前移时得到 15。

那么为什么要对任务使用小时数?在几分钟的讨论后,情景估算将是任意数字。但是,如果您在迭代开始时计划任务,您应了解详细验收条件、详细任务列表以及完成此工作的人员。以小时表示的估算任务将反映估算的精确性。

对于应为情景中的任务分配的最大小时数,我们建议理想的开发人员工作日,大约是 6 小时。如果任务花费的时间超过了一天,则在每日例会时提供状态的值将会丢失。

为什么应该将分数转换为成本,而不是将分数转换为小时?

小时是更加精细的估算,不应依赖此值提供成本。通过使用分数,您可以大概了解是否能够满足迭代承诺。任务小时数表示每日承诺,可用于在迭代结束时了解您的分数估算是否准确。

分数是用于表示规模的相对的抽象值。我们知道微小和巨大之间的差异。情景分数只是此概念的一种表示形式。建议使用 Fibonacci 序列来表示分数。

速度

如何在没有小时估算时确定迭代何时完成?随着时间的推移,您的团队将会了解其速度。速度是可以在迭代中完成的情景分数的平均值。通过使用此已知值(接近),团队可以在此数据内进行计划,并且知道他们很可能能够完成。速度与速率不同。

反馈

需要更多帮助? CA Agile Central 社区为您提供一站式自助和支持。要将反馈或支持请求提交到 CA Agile Central 支持、获取解答并与其他用户协作,请加入我们的 CA Agile Central 社区