为团队进行规模调整和估算

规模调整和估算包括以下主题:

什么是估算?

排定工作之前,您需要了解其大小。下一次迭代中是否能够容纳两个用户情景?四个或者更多?需要估算实践才能回答这些问题。CA Agile Central 允许在迭代计划期间或之前进行规模调整和估算以供使用。

观看以下简短视频了解规模调整和估算之间的差异:

规模调整和估算
规模调整和估算(5 分钟)

 

用户情景

估算是完成某个用户情景所需的工作量的记录度量。估算情景时,请作为一个团队进行估算。协作估算可确保每个团队成员都致力于要计划的工作。跨职能依存关系、潜在问题和加速进度的力量可以通过团队估算来发现。

CA Agile Central 使用“计划估算”字段记录每个用户的估算。您可以使用“积压工作”页显示“计划估算”列,并通过单击该字段轻松编辑值。

计划估算

“计划估算”字段使用的默认单位类型是分值。将此值看做是一个代表所有团队工作量的相对的抽象值。您可以更改单位类型来表示其他数值(如周或月),但是我们建议简单的类似 Fibonacci 的数字顺序。

以下是示例分值集合:2、3、5、8、13、20、40 或 100 分。

在迭代计划之前,还应在迭代的“计划速度”字段中输入分数估算。此值表示团队认为他们可以在迭代中完成的情景分数(或其他值)的总数。此总数也称为团队的资源。您可以通过计算过去几个迭代的已验收分数总数的平均值来计算速度。

新的敏捷团队最初可能会看到速度波动(您可以在一个迭代中完成 13 分,在另一个迭代中完成 20 分),但是随着团队协作越来越密切,速度也会越来越稳定。

资源字段

注意:如果您的团队提供的情景估算大于未来迭代的总速度,那就麻烦了!团队只能承诺可以在单个迭代中完成的工作。要估算大型情景或新方案,可以将情景拆分成较小的子情景。随着情景向上移动到积压工作,继续将内容拆分成可交付值的最小单位。

任务

排定用户情景后,需要标识提供该情景值所需的必要操作或步骤。这些操作通过创建任务记录在 CA Agile Central 中。任务还包含用于估算和跟踪工作量的字段,但是度量值不同。

情景和任务

通常情况下,个人自愿选择任务并拥有该任务。所有者提供他认为完成任务所需的小时数的初步估算。与情景分数不同,任务估算不是抽象值。情景分数可提供对“我们是否能够在迭代承诺结束之前完成此工作?”的较高级别的了解,而任务估算可提供对“我的团队成员是否能在今天结束之前完成编写此用户情景部分的代码?”的每日进展。

任务的默认单位类型是小时。此类型也可以更改,但是我们建议创建需要在 1-6 个小时之内完成的任务。这样可以确保一个工作日之内的工作范围,以便团队可以在每日立会中了解彼此的进度和问题。

CA Agile Central 允许您记录初步的每小时任务估算,以及完成之前的剩余时间。在任务所有者执行初步估算时,“任务估算”字段在迭代计划期间使用,并且该值将自动复制到“待做”字段。在每天结束时或状态会议之前,所有者可以更新“待做”字段以反映剩余的初步小时数。

任务估算字段

重要信息:避免将任务小时总数与情景分数关联。不需要进行如下讨论:“此情景大约需要 20 个小时的工作,所以我们估算此情景为 10 分。据我们团队的了解,2 小时的工作等于 1 个情景分数。”这可能是一个保守的估算。随着团队逐渐成熟,您会开始注意到某些分值大小的工作是任务小时数的平均值。此类确认非常有用,但是仅适用于在迭代结束后验证估算的准确性。

有哪些缺陷?

是否应估算系统中的现有缺陷?如果可能,您的团队应使用相同的分值系统估算作为用户情景的缺陷修复工作。此练习中的值是从总迭代速度中减去的缺陷。如果团队的每迭代平均速度为 20 分并且已排定了 2 分的缺陷,则团队将不会承诺另外两个 10 分的情景,因为他们很可能无法完成。

CA Agile Central 中的缺陷还使用“计划估算”字段记录分数。

规模调整和估算值

敏捷流程中有一句老话 — 我们通常会低估工作量的大小,并高估完成此工作所需的能力和时间。正确估算未来工作的规模和范围是在 CA Agile Central 中计划和执行敏捷项目的关键。如果团队知道如何进行估算,他们就能准确预测当日完成任务所需的时间,确定平均迭代中可容纳的用户情景数量,以及更改、缺陷或其他问题将通过何种方式影响长期目标。

CA Agile Central 中使用以下估算字段:

  • 发布单位:适用于发布的估算资源单位数量。
  • 迭代单位:适用于迭代的估算资源单位数量。
  • 计划估算:此字段记录团队估算的完成用户情景或缺陷所需的工作量。
  • 计划速度:团队估算的他们在给定迭代中完成的计划估算分数。此总数也称为可用资源。
  • 任务估算:此字段记录个人估算的完成任务所需的工作量。
  • 待做︰完成任务的实际剩余时间量。

大部分估算单位都汇总到累积总计并且可以在“迭代状态”或“发布状态”页面中查看。

如何估算?

您的团队可以使用多个不同的技巧来估算工作。无论喜欢哪种方法,请确保所有操作都是协作性的。请记住,团队成员负责提供估算,而不是产品所有者提供。

计划扑克牌

要估算和获取讨论流程,计划扑克牌是一种简单有趣的方式:

  1. 为每个团队成员创建或购买一套计划卡片。为分值系统中的每个值分配一张卡片:2、3、5、8、13、20、40、100(或类似)
  2. 在显示器或信息板上显示建议的情景。说明为该情景提供的分值以及初始要求。
  3. 给团队成员几分钟的时间选择卡片,正面向下。
  4. 此时,所有团队成员举起手来,展示卡片。
  5. 找到最低和最高的卡片分值。
  6. 请展示最低和最高卡片分值的人分别在短时间内介绍他们进行此选择的原因。
  7. 请其他人就此发表评论,此类讨论会暴露一些问题或请求。
  8. 重新投票,直到达成共识。
  9. 在 CA Agile Central 中输入估算值。

计划扑克牌

示例和比较估算

如果您是新的敏捷团队,但是该团队都熟悉过去的工作,您可以使用示例和比较进行估算。CA Agile Central 开发团队已将此策略与计划扑克牌结合使用来生成情景估算。

创建各种大小情景的图表,并使团队就对应的分数值达成共识。例如:

白板上的图表

在团队工作区或您举行积压工作细化和计划会议的地方张贴此图表的副本。使用可识别的比较时,团队可能有如下讨论“我记得创建回收站所需的时间并且似乎是相同的工作量,因此此情景应该估算为 8 分。”

什么时间估算?

和计划一样,估算是一个持续的过程。估算和计划会议在迭代周期的过程中定期举行以确保团队有所准备。团队提前计划两个或三个周期,以便预见和响应潜在的更改。

在迭代计划之前,应同时排定积压工作顶部的优先级并进行估算。产品所有者的责任是按重要性排列用户情景和缺陷,以便团队可以为每个项提供估算。

无法在近期完成的项可以放入积压工作,但是不需要详细估算。积压工作靠下部分的项的估算可能会变得过时,需要在计划之前重新执行。创建用户情景作为占位符以及用于长期功能或主题的说明,这很常见。久而久之,该情景逐渐移向积压工作,并被拆分为较小的数据库以记录该功能的所有方面。

积压工作细化

积压工作细化 

由谁负责估算工作?

开发人员、测试人员、技术作家和其他参与者在团队会议中共同进行估算工作。产品所有者将用户情景添加到积压工作时,不应提供估算。产品所有者负责沟通需要完成的工作以及每一项的优先级。团队负责估算工作规模、与产品所有者沟通预期并执行计划。通过此实践,参与者可以全权负责该工作。

为什么作为一个团队进行估算?

以团队形式进行估算也可以作为融合工具,因为它涉及讨论。通过交谈,团队成员会了解到彼此的责任和能力。在未来迭代中,开发人员可以预见技术作家的工作量,反之亦然。具有类似技能组合的团队成员也可以通过这些讨论了解有关该产品的更多内容。

例如,一个开发人员认为某个情景是 8 分,而其他人认为只有 3 分。被问起存在差异的原因时,更有经验的开发人员揭露了正在编辑的代码部分的警告。现在,资历较浅的团队成员已经熟悉这一异常,并且可以在未来的估算会话中利用此类知识。

在迭代计划会议的后期,个人可以提供每小时任务估算的值,但是团队仍然参与并协作。同样,这样可以由各种角色的成员来教育其他团队成员有关工作的规模和范围,并使任务所有者认为他们的估算可靠。

如果估算值较大怎么办?

在积压工作细化和计划过程中,初步估算可能会暴露某个用户情景或缺陷可能太大而不适用于单个迭代。出现这种情况时,必须将该情景进行拆分。最好在大型用户情景接近积压工作的顶部时进行此拆分。随着业务需求和策略的更改,您可以会发现自己延迟或取消几个月以前的用户情景。不必花费时间向可能不会排定的工作添加过度细致的详细信息。

如何随着时间的推移拆分工作

新情景的估算周期是多久?

单击下图可启动交互式时间线,该时间线遵循从积压工作底部到迭代计划的新情景。您将能够看到执行各种估算活动的人员以及需要举行哪些会议来讨论该情景。

情景 
估算时间线

反馈

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