定义敏捷度量的正确方式
敏捷度量是用于跟踪敏捷项目团队的进展和成功的衡量标准。
当正确定义这些度量标准时，它们可以提供有关团队绩效、质量、测试效率或整体效果的见解，并展示其随时间的变化。
敏捷度量的终极目标是帮助团队确定改进的领域，并做出基于数据的决策，从而在团队进展的同时实现更好的产品。
大多数情况下，公司定义的度量标准要么属于虚荣度量，要么是原始数字，从左到右逐渐增长。它们在某些仪表盘上看起来不错，但对于团队本身来说通常是无用的。
它们的目的不是以任何方式帮助团队，而是填写一些领导层的报告，然后得出一些战略决策。不幸的是，团队不明白为什么会有这样的决策。
为了满足这些错误的度量标准，团队假装自己的流程良好，以使度量标准看起来好。但团队的输出根本没有改善。
基本度量标准
有很多方法来划分度量标准。其中最基本的方法可能是自上而下和自下而上。
➡️自上而下表示：我们领导层将为您创建我们希望您所有人都达到的度量标准，您的最终目标是适应这些标准的绿色区域。我们不介意您是否喜欢它们，这是我们想要跟踪的。
➡️自下而上表示：我们 – 团队需要在这些领域改进，为此，我们需要专注于这些事情。因此，我们定义了一些度量标准，这些度量标准将允许我们跟踪团队朝着我们的目标的进展，并向您 – 领导层展示它如何随着时间推进改善了我们的工作。
好的度量标准的定义
那么，任何好的度量标准应该包含什么，或者如何描述它呢？
最重要的属性是具有改变行为的。这意味着每次查看度量标准的结果时，清楚地知道团队内部必须发生什么变化才能取得改进。
然后它必须是简单的。如果你无法用几句简单的话来解释清楚，以便所有相关的听众都能理解，那么就不是真正好的。
好的度量标准是可以随时间进行比较的。在某个时间点上获取结果快照，然后再次获取。将它们并排放置。如果无法将两个结果相互比较，那么应该重新考虑这个度量标准。
最后，尽可能使用比例或百分比而不是纯数字。例如，“冲刺期间有10个新的未解决缺陷”并没有太多意义。这取决于您通常有一个还是100个。
以下是我认为符合所有这些定义标准的度量标准的一些示例。它们专门针对敏捷团队。主要分为三个类别：绩效、质量和士气。
度量标准的类别
绩效度量标准
目标是了解团队在追赶冲刺内承诺的故事方面有多好。评估是否过度承诺是否是常规做法，或者追赶故事是否成为冲刺与冲刺之间的标准。
从敏捷绩效的角度来看，团队应该努力将在冲刺开始时团队承诺交付的计划冲刺内容交付出来。
这并不意味着在冲刺期间我们不应该灵活地进行故事交换。但这应该始终是一种导致交换的协商，而不是一种添加。团队的能力不会因为有人在冲刺中添加了新的故事而增长。
我们引入这个度量指标来警惕这种情况，并引导团队中的每个人保护他们在冲刺中拥有的能力。
这提高了团队的可靠性和可预测性。
#1. 冲刺能力与已完成故事点数
观察冲刺能力与已完成的故事点数（sp）随着冲刺的历史变化。
冲刺与冲刺之间的小偏差是可以接受的。任何方向上的巨大跳跃都意味着有些不对劲。
总冲刺能力-一个团队成员的可用工作日增加了总能力的一天。例如，如果团队有10个人，并且他们所有人都将全速可用，那么本次冲刺的总能力是100。
从冲刺到冲刺验证冲刺能力与已完成的sp。如果团队在计划期间承诺的sp数量明显高于团队通常完成的数量，向团队提出这个风险。
目标应该是每个冲刺的总计划sp等于或小于总完成sp。
如果团队在计划中重复交付的sp少于计划的sp，团队需要调整计划，在下一个冲刺中接受更少的sp。
像monday.com、atlassian jira software或asana这样的工具都提供了一种简单的方法来保存和提取每个冲刺中的故事点数。它们甚至可以在每次冲刺计划后自动生成这些内容。
#2.燃尽图
这是大多数scrum团队在仪表板上隐藏的度量之一。我同意这可能看起来是一个无用的东西。团队很少考虑它。相反，经理们喜欢指出故事从高层看起来如何以及它们的进展不好（因为它们在整个冲刺期间都是开放的）。
我想要强调的是，尽管如此，你作为一个团队应该去检查燃尽图，这是为了你们自己的好处。如果所有的故事在整个冲刺期间都是开放的，并且只在冲刺的最后一天关闭，这会在团队内部和冲刺目标完成方面产生不确定性。
审查你的冲刺看板上已完成的故事。
与团队核实，确定为什么小故事仍然是开放的，即使它们在冲刺开始时就开始了。
与团队合作，树立这种思维方式，不要让故事保持开放的时间超过必要的时间。
理想的燃尽图通常是一种理论状态。然而，我们越接近它，我们的故事处理就越有效。
敏捷管理工具如asana可以为每个迭代自动生成燃尽图。
#3. 迭代目标完成度
这追踪了每个迭代中您完成的迭代目标的百分比。
您可以单独记录迭代目标，例如在confluence页面/link_6>或jira software/link_7>上的每个迭代上。必须分配状态以确定它们是否在迭代中完成。
即使团队没有在迭代中完成所有故事，他们仍然可以实现迭代目标（例如，只有一些附属故事未完成）。
我们应该每个迭代都力争实现100％的迭代目标。如果不是这样，请找出团队的问题所在。
- 如果每个迭代中有太多并行主题，则减少它们的数量。
- 如果在迭代期间添加了太多的临时故事，请减少这些故事，以免影响原始迭代目标。
- 如果迭代目标过大或过具有挑战性，请简化它。无论如何，如果在迭代结束时无法实现迭代目标，则没有意义。
代码质量指标
此项指标应跟踪代码的质量随时间的变化情况。它有助于保持健康的开发流程，并减少解决问题所需的时间，或者开发人员在开发和测试活动期间等待代码执行时的空闲时间。
#1. 自动化测试
开发人员应为每次更改创建自动化单元测试。
- 通过自动化测试来衡量代码覆盖率-使用azure pipelines或sonarcloud运行测试。目标是达到85％的覆盖率。超过90％实际上并不高效。
- 确保自动化单元测试创建是新故事的定义完成的一部分。
- 作为积压中的技术债务故事的一部分，补充旧代码的测试覆盖率。
#2. 代码复杂度
评估代码随时间的不必要的复杂性，并通过技术债务故事积极修复它们。或者在可能的情况下防止它们发生。
定义代码标准和准则以教育开发人员遵循。确保他们遵守编码规则，以减少代码复杂性的不合理增加。根据团队的经验定期更新准则。
识别代码异味-代码中潜在问题的指示器，例如重复的代码，长方法和未使用的变量。
同行评审应确保新创建的代码符合代码标准。
使用azure ado或sonarcloud仪表板和报告等工具发现代码问题。
#3. 部署中的手动步骤
跟踪团队在发布代码到测试或生产环境时需要执行的手动步骤。
- 我们的目标是在未来实现0。
- 如果需要，创建技术债务故事来提升部署/发布流程，使其符合自动化路线图。逐渐减少从冲刺到冲刺的剩余手动步骤。
士气度量
这是一个跟踪团队对他们的工作和他们每天处理的流程的感受的度量指标。
#1. 冲刺回顾达成
您可以跟踪下一个冲刺中实际完成的行动项目数量。
- scrum master应将回顾会议的结果收集到团队的页面中，以跟踪约定的行动项目。
- 然后团队会跟踪进展。
- 项目管理随后可以审查行动项目是否在进展，或者团队无法完成它们的原因。然后修改环境以使团队能够在约定的行动项目上取得进展。
前一个冲刺的行动项目中至少有33％或1个（取决于何者更高）将被采纳到下一个冲刺中。
如果低于该比例，则需要进行更改，以使团队能够实施他们约定的改进。
项目管理工具中包含用于冲刺回顾活动的现成模板。这里是来自monday.com的一个示例：
#2. 团队协作
跟踪成对编程。
- 每个故事组成一个自然的团队，共同工作，分享观察，知识和成功。在不同团队成员拥有的故事下创建子任务。
跟踪同行发起的代码审查。
- 同行被要求或积极采取行动来审查其他人的故事输出。
可以从monday.com/asana/jira软件板的子任务中提取该指标。
冲刺中至少有50％的故事应由团队成员共享。如果比例较低，应调查原因并采取相应行动。
对于自愿的同行审查，请跟踪具有专门子任务的故事。初始阶段，以此方式审查的代码故事的比例为20％是一个良好的开始。逐渐地，在冲刺中，您应鼓励和激励团队更多地进行协作，并将其提高到每个冲刺中50％的代码故事作为目标。
#3. 技术债务与新功能故事
给团队解决自己的技术债务故事的机会将提高团队对他们工作的满意度。
- 相反，如果不制定解决这些技术债务问题的计划，并逐步累积它们，将会使团队逐渐失去动力。解决方案也会变得更不稳定，复杂，并且难以在没有大幅重做的情况下解决。
团队最清楚解决方案中存在什么问题，即使利益相关者或最终用户没有看到。这些故事对开发团队本身的影响最大。对于利益相关者来说，它们可能是看不见的。这就是为什么让团队有机会处理能够帮助他们减少开发活动的故事是很重要的。
目标是追踪解决了多少个技术债务故事以及这些故事的积压是否只增不减。
团队可以在积压中将这些故事标记为techdebt，并从团队中给予它们优先级，这样它们就可以位于顶部并在迭代中被选择。
根据项目所处的状态以及在积压中识别出的技术债务数量，您可能希望确保techdebt积压在每个迭代之间的增长不超过10%。
优先处理技术债务故事，并将它们纳入迭代中，以控制技术债务积压的增长，使团队每个迭代有10-20%的时间处理技术债务故事。
最后的话
每个项目最终都需要一些指标，无论是因为领导层想要它们，还是因为团队决定衡量自己的成功。
你能做的最好的事情就是开始建立你的度量库，准备随时使用；越早越好。在这样做的同时，确保你始终首先选择能够改变行为的指标。
接下来，查看 可能破坏你的迭代的不健康流程。
