敏捷回顾会：经验教训的总结
在一个sprint中哪些方面做得好，哪些方面做得不好，哪些方面需要提高？在每一个敏捷回顾会中都应该回答这些问题。
很多团队（包括我(译者注：作者
)的团队在使用Scrum或敏捷的流程之后）在第一次做回顾会的时候都会试图回答下面的问题：
- 在sprint中哪些方面做得好？
- 哪些方面做得不好？
- 哪些方面需要改进？
会议室中每一个想回答上面问题的人都会贡献自己的答案。经理将回答整合在一起，并找出应对措施，记下来，执行。整个过程大约需要15到30分钟，但是这完全没有用。
我们所做的只是遵循了回顾会的字面意思，而没有达到它的本来目的。
怎样才是一个真正的敏捷回顾会？
回顾会是对过去已完成工作的一个反映。通过自我评估，判断事情进展如何以及如何改进。上面3个问题经常被问到（即便不在同一次会议中）。但是为什么问这些问题与怎样问以得到最大的好处同样的重要。回顾会的目标是提出一个行动计划来尝试在下一个迭代中提高效率。我用“尝试”是因为这个行动计划是一个实验。通过它在下一个迭代中的实施来判断这个行动计划是否成功。
哪些方面做得好？
回顾会的一个目的是看看sprint中哪些方面做得好。有两个目的：
- 一是庆祝成功。不管是大还是小，你做了一些好的事情，它应该被承认。
- 二是看看这个成功可否在其他的领域被复制。或者它是否可持续？
我刚刚完成了一个Scrum项目。我们是一个BAU(Business As Usual)小组，主要关注系统而不是开发。在最近的一个项目中，决定采用Scrum。这是我们团队的第一个Scrum项目。在最终的回顾会中，我期望团队能反映的一件事情是什么实践是可以由Scrum项目带到我们的BAU工作中的？
哪些方面做得不够好？
这意味着“承认自己的错误并承诺改进”
回顾会的一部分有点像这样。如果做的很合适，敏捷可以暴露一些问题。问题可大可小，但是回顾会的一个目的就是承认这些问题并找到解决他们的方法。
在西方文化中，错误意味着失败，尽管没人这么说。他们被视为坏事情，要么被忽视，要么被污辱（通过责备和嘲笑），或者变通过去。只有很少的错误被跟踪，然后更少的被真正落实。是的，所有的系统都有问题，但是如何处理这些问题很重要。
如何回答哪些方面做得不好？我喜欢的一个办法是用10分钟的时间让团队抛出在这个sprint中他们不喜欢的任何事情。例如计划没有很好的被执行。其他的可以是：这个sprint很匆忙、太多的打扰，部署失败，测试失败，任何可以抨击的事情。
下面我会做的事情是找出对于团队优先级前3-5的问题，然后寻找他们的根本原因。基于根本原因，我们头脑风暴可以尝试做什么，并确定一个方向。最后回顾会的一个重要产出是制订一个行动计划来缓解问题。我只关注3-5个问题，并确保他们分布在开发周期的不同时段。这样不至于关注的太多而导致团队处理不过来。你也会发现几个问题有相同的原因。
对于行动计划，在下个sprint中至少完成1个，最多不超过3个。太多团队处理不过来。
哪些方面可以改进？
最后这个问题是想审视一下在这个sprint中你的所作所为并看看有没有更好的方式来做它。改进可以是任务的自动化，或者尝试一个不同的方法，或不同的开发语言。也可以只是更好的解释一些东西。
对于改进，我喜欢用精益的方法来消除浪费。浪费来自：
- 缺陷
- 过度生产
- 等待
- 没有利用的人才
- 运输
- 库存
- 运动
- 额外的流程
如果一个建议的改进造成了浪费的增加，那么它就需要调整。
其他需要考虑的事情
一个敏捷回顾会可以把其他事情考虑进来以帮助提高效率。这可以是团队的幸福水平。一个快乐的团队是一个高效的团队。另外一个审视生产率水平的例子是团队在上一个迭代中所学到东西的数量。开回顾会有很多方法，在文章的最后我会提供一些资源。
规则
在Scrum中对于1个月的sprint，其回顾会不要超过3小时。对于更短的sprint，占用的时间应该更少。例如2周的sprint，我把回顾会的时间最多设为1个小时30分钟。这是针对Scrum。对于其他的敏捷方法，这些规则可能不适用。
我个人还有另外两条强制性规则：
- 不要责怪别人。这不是大清洗。我们在试图解决问题而不是为了指责。
- 没有借口。我不在乎你是否必须花2天时间解决生产问题，以至于不能做你的工作。我们关注怎样才能防止生产问题发生而再次干扰我们的工作？
最后一个可选规则：
- 不发言没有甜甜圈
这是我能想到的关于回顾会的最后一件事。食物。在周围放些食物，这个简单的动作可以使团队轻松。它引发讨论。有些Scrum Master跟喜欢玩一些破冰游戏。我发现这要放些食物就可以得到同样的效果。
最后一点：只有回顾会中提出的行动真的被执行了，那么回顾会才是有意义的。如果它们只是被记下来然后存档，没有被执行，那么这个会本身没有意义。正是通过这些行动的实施，团队才能提高。如果你持续改进，你的团队会变得更好。