定义敏捷指标的正确方法

敏捷度量是用来监测敏捷项目团队进展和成果的工具。

当这些度量标准被恰当定义时,它们能够深入揭示团队的效能、产品质量、测试效率以及整体表现如何随着时间推移而变化。

敏捷度量的最终目的是帮助团队找出需要改进的方面,并做出基于数据的决策,这些决策将推动团队进步,并最终带来更优质的产品。

然而,很多时候,公司定义的度量要么是无意义的指标,要么是仅仅从左到右增长的原始数字。 它们在某些仪表板上可能看起来不错,但通常对团队本身毫无帮助。

它们的目的是为领导层生成一些报告,从而制定一些战略决策,而不是以任何方式帮助团队。 不幸的是,团队往往不明白这些决定的缘由。

为了满足这些不合理的指标,团队可能会为了让指标看起来更好而扭曲流程。 但这并不能真正提升团队的产出。

基本指标类型

指标的分类方式有很多,最基本的可能是自上而下和自下而上两种方式。

➡️ 自上而下的方式:管理层设定所有团队都必须达成的指标,你们的最终目标是进入这个指标的绿色区域。我们不在乎你们的团队如何运作,我们只关心这些指标。

➡️ 自下而上的方式:团队自行确定需要改进的方面,并专注于这些方面。因此,我们定义了一些指标,以跟踪团队在实现目标方面的进展,并向管理层展示我们的工作是如何随着时间推移而改进的。

优秀指标的定义

那么,一个好的指标应该具备什么特征,或者如何描述它呢?

最重要的属性是能促进行为改变。这意味着每次查看指标结果时,团队都能清楚地知道为了改进需要进行哪些调整。

它必须简单易懂。如果无法用几句简单的语言向所有相关人员解释清楚,那么它就不是一个好的指标。

一个好的指标必须能够进行时间上的比较。在不同的时间点进行测量,并将结果并排比较。如果无法比较这些结果,则应重新考虑该指标。

最后,尽量将指标转化为比率或百分比,而不是仅仅使用原始数字。“冲刺期间有10个新的开放缺陷”本身并不能说明问题。它取决于你通常有1个还是100个缺陷。

以下是一些我认为符合这些标准,并适用于敏捷团队的指标示例。它们主要分为三类:绩效、质量和士气。

指标类别

绩效指标

目标是了解团队在完成冲刺中承诺的故事方面的表现如何。评估是否存在过度承诺,或者故事结转是否是常态。

从敏捷绩效的角度来看,团队应该努力交付在冲刺开始时承诺的冲刺内容。

这并不意味着我们不能在冲刺期间灵活地交换故事。但这种交换应该是经过协商的,而不是仅仅添加。团队的能力不会因为有人在冲刺中添加新故事而增加。

我们使用这个指标来关注此类情况,并指导团队中的每个人维护他们在冲刺中的能力。

这有助于建立团队的可靠性和可预测性。

#1. 冲刺容量 vs. 已交付的故事点数

查看冲刺容量与冲刺期间交付的故事点(SP)的历史记录。

  • 冲刺之间的细微差异是可以接受的。任何方向的巨大跳跃都表明存在问题。
  • 总冲刺容量——一个团队成员的可工作天数计为一个单位。例如,如果团队有10人,并且每个人都参与了整个冲刺,那么冲刺的总容量为100。

验证从一个冲刺到另一个冲刺的冲刺容量与完成的SP。如果团队(在计划期间)承诺的SP数量明显高于团队通常可以完成的数量,请向团队指出这种风险。

目标应该是使计划的总SP等于或小于每次冲刺完成的总SP。

如果团队完成了(接近冲刺结束时)所有计划的故事,并且仍然有能力接受额外的故事,那么你可以交付比计划更多的SP。

  • 如果团队反复交付少于计划的SP,则团队需要调整他们的计划,并在下一个冲刺中使用更少的SP。

诸如monday.com、Atlassian Jira或Asana之类的工具提供了一种简单的方法来保存和提取冲刺中每个故事的故事点。他们甚至可以在每次冲刺计划后自动生成报告。

#2. 燃尽图

这可能是大多数Scrum团队隐藏在仪表盘中的指标之一。我承认它看起来甚至有点没用。团队很少会仔细研究它。相反,管理人员喜欢从高层次上指出故事的进展情况,以及它们为何进展缓慢(因为它们在整个冲刺中都处于开放状态)。

我想强调的是,尽管如此,你们作为一个团队应该为了自己的利益而查看燃尽图。如果所有的故事在整个冲刺中都处于开放状态,并且只在最后一天关闭,这会在团队内部以及冲刺目标的实现方面产生不确定性。

  • 查看冲刺板,了解已完成的故事。
  • 与团队核实,以确定为什么即使在冲刺开始时就启动的小故事仍然处于开放状态。
  • 与团队合作,建立不让故事开放时间过长的观念。
  • 理想的燃尽图通常是一个理论上的状态。然而,我们越接近它,我们处理故事的效率就越高。

像Asana这样的敏捷管理工具可以为每个冲刺自动生成燃尽图。

资料来源:asana.com

#3. 冲刺目标完成情况

这会跟踪在每次冲刺期间完成的冲刺目标的百分比。

你可以为每个冲刺单独记录冲刺目标,例如在Confluence页面/Jira上。无论在冲刺中是否实现,都应该标记状态。

即使团队没有在冲刺中完成所有故事,他们仍然可以实现冲刺目标(例如,只遗漏了次要的故事)。

我们的目标是每次冲刺都100%完成冲刺目标。如果没有达到这个目标,请找出阻碍团队的原因。

  • 如果每个冲刺中并行进行的主题过多,请减少它们的数量。
  • 如果在冲刺期间添加了太多的临时故事,请减少它,以免影响最初的冲刺目标。
  • 如果冲刺目标太大或太有挑战性,那就让它更简单。无论如何,在冲刺结束时没有实现宏大的冲刺目标是没有意义的。

代码质量指标

这将跟踪代码随着时间推移的质量。它有助于维持健康的开发过程,并减少解决问题所花费的时间。或者减少开发人员在开发和测试活动中等待代码执行而导致的空闲时间。

资料来源:azuredevopslabs.com

#1. 自动化测试

开发人员为他们所做的每个更改创建自动化单元测试。

  • 通过自动化测试测量代码覆盖率——使用Azure Pipelines或SonarCloud运行测试。力争达到85%的覆盖率。超过90%的覆盖率可能并不总是有效的。
  • 确保创建自动化单元测试是新故事完成定义的组成部分。
  • 赶上旧代码的测试覆盖率,作为积压工作中技术债务故事的一部分。

#2. 代码复杂度

评估随着时间推移代码中出现的不必要的复杂性,并通过技术债务故事积极地修复它。或者尽可能阻止这些复杂性的发生。

定义代码标准和指南,以教育开发人员遵循它们。确保他们遵守编码规则,以尽量减少代码复杂性的不合理增加。根据团队的经验定期更新指南。

识别代码中的“坏味道”——代码中潜在问题的指示器,例如重复代码、长方法和未使用的变量。

同行评审应确保代码标准适用于新创建的代码。

使用Azure Ado或SonarCloud仪表板和报告等工具来发现代码问题。

#3. 部署中的手动步骤

跟踪团队必须执行多少手动步骤才能将代码发布到测试或生产环境。

  • 我们的目标是随着时间的推移将手动步骤减少到0。
  • 如有必要,创建技术债务故事,以将部署/发布管道引入自动化路线图。从一个冲刺到另一个冲刺,逐渐减少流程中剩余的手动步骤。

士气指标

这是一个衡量团队对其工作和日常流程感受的指标。

#1. 冲刺回顾的执行情况

可以跟踪在下一个冲刺中实际完成了多少行动项目。

  • Scrum Master应将回顾会议的结果汇总到团队页面中,以跟踪商定的行动项目。
  • 然后,团队将跟踪进度。
  • 之后,项目经理可以检查行动项目是否正在取得进展,或者是什么阻碍了团队完成这些项目。然后,可以调整环境,使团队能够在商定的行动项目中取得进展。

至少33%或1个(取较大值)上一个冲刺的行动项目应该被纳入到下一个冲刺中。

如果小于这个值,则需要进行更改,以便团队能够实施他们商定的改进。

项目管理工具包含用于冲刺回顾活动的现成模板。这是一个来自monday.com的例子:

资料来源:monday.com

#2. 团队协作

跟踪结对编程。

  • 为每个故事形成自然的工作搭档,共同分享观察、知识和成功。在不同团队成员拥有的故事下创建子任务。

跟踪来自同行主动发起的代码审查。

  • 同行被要求或主动采取行动,审查其他人的故事输出。

可以从子任务的monday.com/Asana/Jira面板中提取指标。

冲刺中至少50%的故事应该由团队成员共同完成。如果比例较小,请调查原因并采取合理的措施。

对于自愿同行评审,使用专门的子任务来跟踪故事。一开始,以这种方式审查20%的代码故事是一个好的开端。在冲刺过程中,应该逐渐鼓励和激励团队加强合作,并将目标设定为每个冲刺审查50%的代码故事。

#3. 技术债务 vs. 新功能故事

资料来源:atlassian.com

让团队有机会处理他们自己的技术债务故事,将提高团队对工作的满意度。

  • 相反,随着时间的推移,如果不计划逐步解决技术债务问题,它们会不断累积,这会使团队失去动力。 如果不进行大量返工,解决方案将变得更加不稳定、复杂和难以维护。

团队最清楚哪些方面不适用于解决方案,即使利益相关者或最终用户看不到它们。这些故事对开发团队本身的影响最大。对于利益相关者来说,它们可能是不可见的。这就是为什么让团队有机会处理这些故事,以帮助他们整理开发活动非常重要。

目标是跟踪随着时间推移解决了多少已提出的技术债务故事,以及这些故事的积压是否仅仅是在增加。

团队可以在积压工作中将故事标记为“技术债务”,并给予团队优先权,以便它们可以优先被选中并在冲刺中被处理。

根据项目所处的状态以及在积压工作中确定的技术债务量,你可能需要确保每个冲刺中的技术债务积压的增长不超过10%。

确定技术债务故事的优先级并将它们包含在冲刺中,以控制技术债务积压的增长,这样团队就可以在每个冲刺中有10-20%的时间处理技术债务故事。

最后的话

每个项目最终都需要一些指标,无论是因为管理层希望有这些指标,还是因为团队决定衡量自己的成功。

你能做的最好的事情就是尽快开始构建你的指标库,以供选择和使用。在这样做的时候,请确保你始终将重点放在那些能促进行为改变的指标上。

其次,检查可能破坏你的冲刺的不良流程。