您的复古行动项目无效。这就是原因。

回顾展是我们团队回顾的时刻。然而，它的功能是改善我们前进的方式。让我们从Scrum中消化原始定义：

Sprint Retrospective是Scrum团队的一个机会，可以检查自己并制定一个改进计划，以便在下一个Sprint期间实施。

前两个组件是活动，第三个是结果。虽然大多数团队都会进行富有成效的对话并创建行动项目以产生结果，但很少有系统能够确保实际创建积极的变化。

1. 检查✔
2. 制定计划✔
3. 制定改进?♀️

问题始于“改进”的概念。它既模糊又主观，所以即使是一个活动计划也感觉就像是朝着正确方向迈出的一步（Spoiler：它不是）。但是，如果您采取措施具体地定义改进，您可以让自己和您的团队对您的行动项目负责。为此，我们可以使用SMART目标。

SMART目标将改进情境化

研究表明，具体和有时限的目标比通用行动项目更有可能产生结果。

为每个追溯行动项目添加数字和日期可确保：

1. 该部门理解并协调成功的原因，并且
2. 实现这一目标的进展是黑白 – 朝向或远离目标。

虽然有很多系统可以为目标设定数字和日期，但为了这篇文章，我们将坚持一个经过验证的：SMART（具体，可衡量，可实现，相关，有时限）目标设定。

为了使您的团队能够最好地使用SMART目标，您需要调整复古的所有三个组件。您将使用更多数据进行检查，使用SMART目标创建计划，并通过使团队中的每个人都能获得透明来实现改进。

检查：使用数据来诊断最大的问题

大多数团队仅使用定性反馈来决定目标。团队成员提出他们认为是一个大瓶颈，整个团队立即开始尝试缓解这个问题。这种方法优先考虑个人的记忆和感受，不一定是最大和最紧迫的问题。

但是，如果您将更多数据点用于诊断问题，则您更有可能全面了解每个瓶颈。定量数据有助于抵消新近度偏差，并使您能够根据问题对团队生产力的实际风险进行优先排序。

假设一个给定的工程团队正试图诊断为什么他们没有获得与他们预期的sprint一样多的功能。一位工程师Hannah提出以下假设：

我觉得在任何一个给定时间都有比平时更多的拉动请求。我认为这是因为人们太忙而无法进行代码审查，因此工作堆积如山。

几位工程师点了点头。他们还注意到在GitHub中有比平时更开放的PR。

汉娜和她的团队不再立即集思广益，而是进一步调查。他们首先看看他们回顾过去冲刺的时间，并意识到它相对较低 – 仅仅6个小时。这与Hannah的评估相矛盾，即评估过程比平常慢。从那里，他们看到他们的平均回顾周期数约为1.2，其中大多数回请请求在一次审核后获得批准。而且，看起来还不错。

最后，当他们看到他们的合并时间时，他们发现了一面红旗。随着开发人员转向新的工作轨道，他们意识到许多拉动请求在被审查后会长时间保持打开状态。

团队的直觉本能识别出症状 – 长时间运行的拉动请求 – 但不是原因。没有数据，他们就无法发现并解决更深层次的系统性问题。

您可以考虑查看的其他数据点：

• 所有最近的活动，包括Pull请求，代码评测和门票，以提醒您的团队他们在最后一个sprint上工作的内容，以及他们可能遇到的问题。

Velocity的活动日志表示具有形状的每个工程活动。将鼠标悬停在上面，了解团队成员的工作情况。

• 最重要的拉动请求最后冲刺。查看对代码库有重大影响的pull请求，以及比其他请求更大或更旧的pull请求。

Velocity显示活动水平，年龄和健康状况正在进行中。快速查看最有可能阻碍您的团队的拉取请求。

• 处理指标包括周期时间和拉取请求吞吐量等结果指标，以及代表软件开发过程更具体区域的指标，如开放时间，审核时间和合并时间。

Velocity可让您直观地了解从开放到合并的拉取请求的过程。下面，您可以看到代表这一旅程的成分的指标，以更好地诊断减速。

计划：与SMART目标保持一致

一旦您的团队使用定性和定量数据完全诊断出问题，他们就必须决定一个可以用作SMART目标的具体指标。

具体

击中或丢失指标的成功应该是黑色或白色，因此您需要在目标中使用具体数字。 “改善我们的审查时间”是模糊的，“将我们的审查时间减少到4小时以下”是具体的。

此外，请确保指标足够窄，以便团队知道哪些行为会向上或向下推动此指标。过于宽泛的度量标准可能会掩盖进度，因为它们受到许多不同类型的无关数据的影响。例如，Hannah的团队希望选择像Time to评测这样的指标，而不是总周期时间，这样当团队注意到负面方向的指标趋势时，团队就可以轻松自我纠正。

可测量

衡量指标的方式取决于您的目标。例如，如果您正在测量输出，那么简单计数就可以解决问题。如果您希望遵守特定的标准 – 例如保持拉动请求较小，或者将停机时间保持在最低限度 – 那么您需要决定跟踪简单平均值并将其作为一种服务级别目标（SLO）进行跟踪。百分。

这里有一些例子：

虽然平均值更常用于流程指标，但SLO可以让您的团队在少数情况下偏离目标，而不会妨碍他们达到目标的能力。

可分配

选择一个人拥有并跟踪此目标。研究表明，只有一名团队成员定期检查，大大增加了攻击目标的可能性。 Apple支持所有计划的直接责任人（DRI）的想法，而像Microsoft这样的领先技术公司的团队已将DRI模型应用于所有与DevOps相关的功能。

所有权还将帮助您获得将数据带入回溯的买入。考虑首先要求发现问题的人拥有目标。

实际

确保您的目标可以实现，因此如果他们为实现目标付出了共同的努力，您的团队就会感到成功。

执行：提高可见性以保持目标

复古后，你的行动项目的真正考验。您的团队多久会考虑这些指标？团队成功是否会成功？如果您的团队不成功，他们是否可以尝试不同的调整？

为了保持目标，您需要让团队中的每个人都能看到进度。许多管理人员在共享空间或普遍可访问的仪表板中使用信息雷达。

Velocity提供了一个Target仪表板，可让您直观地了解SMART目标的进度。

提高透明度使团队能够将结果导向的讨论带到他们的回顾之外。在立场，1：1甚至配对会议期间将提出有效的目标。重复将确保重点，并将进一步统一团队的成功。

?让工程师?

当Bizzabo的创始人兼首席技术官Boaz Katz开始设定具体目标时，他发现分享成功促使他的团队找到更多改进方法。他告诉我们，“我的团队形成了一种成功的态度，并且渴望更快地发货。”

当整个团队每次复古都感觉成功时，动量会产生飞轮效果。团队成员渴望发现更多改进机会，创造一种围绕对流程实施积极变革的文化。