Retro

Retro，又可以称为回顾，它的目的是对团队的激励、改进。它的模式的特点就是让我们更关注于 Less Well，即不好的地方。当我们无法变得更好的时候，它可以帮助我们反观团队自身，即不要让现状变得更差，避免让破窗效应^破窗难以发生。

在敏捷团队里，Retro 通常会发生一个迭代的结束与下一个迭代的开始之间，这看上去就是我们的除旧迎新。相信很多人都会对自我进行总结，随后改进。而 Retro 便是对团队进行改进，即发生了一些什么不好的事，而这些事可以变好，那么我们就应该对此进行改进。

Retro 是以整个团队为核心去考虑问题的，通常来说没有理由以个人为对象。因为敏捷回顾有一个最高指导原则，即：

无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。

下面就让我们来看看在一个团队里是如何 Retro 的。

它不仅仅可以帮助我们发现团队里的问题，也可以集思广益的寻找出一些合适的解决方案。Retro 的过程和我们之前说的数据分析是差不多的，如下图所示：

Retro 流程

即：

设定会议目标。在会议最开始的时候我们就应该对会议的内容达成一种共识，我们要回顾的主题是啥，我们要回顾哪些内容。如果是一般性的迭代 Retro，那么我们的会议主题就很明显了。如果是针对某一个特定项目的 Retro，那么主题也很明显。
Retro 的回顾。即回顾上一个 Retro 会议的 Action 情况，并进行一个简单的小结。
收集数据。收集数据需要依赖于我们收集数据的模式，要下面将会说到的四种基本维度，或者是雷达图等等。不同的收集数据的形式有不同的特别，团队里的每个人都应该好好去参与。
激发灵感。当我们寻找到团队中一个值得去庆祝的事，或者一个出了问题的事，我们就应该对这个问题进行讨论。并且对其展开了解、调查，让大家进一步看到问题，看到问题的根源。
决定做什么。现在我们已经做了一系列的事，最重要的来了，就是决定我们去做什么。我们应该对之前的问题做出怎样的改进。
总结和收尾。记录会议成果，更新文档等等。

以我们为例，我们以下面的三个维度去进行 Retro:

当然最后还会有一个Action：

该模式的特点是会让我们更多的关注 Less Well，关注我们做的不好的那些。

Retro

Well。我们在 Well 里记录一些让我们开心的事，如最近天气好、迭代及时完成、没有加班等等，这些事从理论上来说应该继续保持（KEEP）下去。

Less Well。关注于在这个迭代的过程中，发生了一些什么不愉快的事。一般来说，我们就会对 Less Well 加以细致的讨论，找出问题的根源，并试图找到一个解决方案。换句话来说，就是改变（CHANGE)。

Suggestion/Puzzle。如果我们可以直接找到一些建议，那么我们就可以直接提出来。并且如果我们对当前团队里的一些事情，有一些困惑那么也应该及早的提出来。

Action。当我们对一些事情有定论的时候，我们就会提出相应的 Action。这些 Action 应该有相应的人去执行，并且由团队来追踪。