指标引领有效的Sprint回顾

在The Atlassian的攻略中，它指出，Sprint回顾展的目标是通过反思什么管用，什么不管用，以及为什么，来确定如何改善团队合作，通常会议包括集思广益，讨论团队做得好的是什么，团队需要做得更好的是什么。

在我的旅途中，我参加了很多这样的会议，有时参与，有时促进。我注意到写便条对某些人来说很痛苦。当每个人都在发言的时候，工程师们在会议期间卡住了，想不到其他的事情。

然后会议一结束，就出现了很多情况和问题。他们想要讨论这些话题。然而，他们要等上几个星期才能举行下一次会议。他们很少记得这个问题。我不认为会议会尽可能地有效。

为了提高效率，我认为管理者应该提倡一种文化，在这种文化中，当问题发生时，人们应该举手。他们应该尽快进行讨论，并且尽可能保持头脑清醒。

如果问题需要更深入的讨论，团队可以将其添加到Evernote、Concept、GitHub Gist或任何其他可共享的文档中。用几句话结合一些上下文来说明这个问题就行了。

这支球队可以做到和做得好的事情一样。会议期间可能会冒出更多的明信片。然后，Scrum Master或辅导员可以阅读文档。

当会议开始时，团队已经有了一个要讨论的基本项目列表。它节省了时间，提高了工作效率。

我谈论拉取请求、交付期和吞吐量已经有一段时间了。如果你熟悉术语周期时间，我建议阅读我的文章，为什么我宁愿使用提前期而不是周期时间。

明确地说，在本文中，Pull Request Lead Time衡量合并一个Pull请求需要多少天，而Throughput是合并的Pull请求的数量。

这两个指标可以真正帮助团队了解他们的表现。此外，当团队在寻找几周内的可变性时，也会从中受益。这些数据带来了有价值的见解，并允许团队质疑他们的决策。

我以这张图表为例。假设我们回到2020年1月。我们已经开始了Sprint回顾展，在2019年12月的最后几周为团队的问题和评估制作便利贴。

我们已经讨论了一些，现在有人分享上面的图表来分析拉取请求的交付期和吞吐量。

如果冲刺持续两周，我们可以使用这些指标来问自己这样的问题：

为什么与11月25日相比，我们在12月2日这一周合并的拉式请求较少？

我们在11月25日这一周做了什么，使我们能够合并比过去几个冲刺更多的拉取请求？

问这样的问题是最基本的。然而，任何人都不应该指责或指责其他人。这既不健康也不有效。

我们在上周合并了较少的拉取请求，因为我们正在进行大规模的重构。

在11月25日的那一周，我们修复了在前一周部署了一个有问题的功能后弹出的几个小错误修复。

因为每个人都在进行评审，所以交付期增加了，我们成立了一个特别工作组来合并重构。

数字本身并不重要，重要的是它们背后的故事。现在是时候问一下，从上一次迭代中学到了什么。以下是解决这些问题的一些替代方案：

我们是否应该避免大规模的重构，因为它们会减慢每个人的速度？我们应该把它作为团队指导方针的一部分吗？

部署复杂的功能可能会导致更高的漏检率。如何将影响降至最低？我们是否应该在测试上投入更多的精力？我们是否应该提供较小的更改？我们是否应该采取更渐进的方式呢？我们是否应该考虑逐步推出？

特遣部队是一个有效的战略吗？也许同时致力于重构的人更少，发货速度更快。

如您所见，这些数据允许团队推导出回顾的相关方面。讨论是一个巨大的知识来源，应该会为改进开发流程带来深刻的见解。

使用度量可以更有效地进行Sprint回顾。团队可以通过询问拉式请求、交付期和吞吐量来提取有价值的知识。事实上，其他指标也很有用。

关键点是使用度量来提取隐性知识并将其形式化。什么做得好，什么做错了，应该促进过程中的变化，提供指导方针，并激励新的实践。