最近我发现，很多团队做retro的时候，直接就开始大家写什么好什么不好如何改进。如果是一个已经何有默契的团队，这样做当然没有问题，但是，当一个全新团队，或者大家都没有卸下包袱的时候， 就需要走一个retro全流程了
记得很久前看到过一个比较全的敏捷retro流程，最近找了很多地方，居然找不到了，那我就自己写一个吧。
1. 回顾上次action
我们上次retro会有很多action，这一次需要大家一起check一下，这些action是否完成了，是否done了。
2. 定义scope
在retro的最开始，我们需要定义retro的范围，通常我们每个sprint retro一次，那我们retro的范围就是这一个sprint。追溯太久，大家都想不起来发生了什么，一个sprint刚刚过去，那么大家对于发生的事情也都还有清晰的记忆。
3. 说个原则
认真的当着所有人的面，说出下面这句话。
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
4. 安全度检查
1-5不记名投票，认为安全的投5，不安全的投1，如果出现小于等于3的数字，证明大家对这样的环境感觉不够安全，没办法说出自己想说的话。这种情况下，需要请出去以为leader。然后再进行投票。以此循环，直到所有参加会议的人员均认可Retro足够安全，每个人都可以畅所欲言。
5. retro维度方式上墙
最常用的 Well， Less Well，Suggestion，Puzzle，Action
Well：我们过去一个sprint做的好的，需要继续保持的
LessWell：我们过去一个sprint做的不好的，包括环境，任何方面
Suggestion：一些建议
Puzzle：我看到一些现象，但是我也不知道是好是坏，也没有什么建议
Action：针对需要改进的点，我们需要采取的行动
6. 开始写sticker
5-10分钟，写sticker，每个人都写，然后上墙，需要有人做timebox 哟~
7. 唱读归类
对于well，我们需要保持，大家给自己打气
对于less well，我们需要归类，看看属于什么问题
对于Puzzle，我们一起判断是好是坏，分类进well 和less well
对于suggestion，我们进行可行性和合理性判断，之后和action一起，后续执行。
8. 投票
对于归好类的less well我们投出1-2个最关心的问题，每人2-3票，选出自己最关心，最想要解决的问题。
9. 给action
针对票数最高的less well大家一起给出action，并且达成一致，给出的action可以解决对应的less well。action必须可落地可衡量，
比如说：story不能过大，就是一个不可衡量的action，那我们怎么说呢，可以说，每个story不能超过3个点，超过的要重新拆分。这就是一个可以落地衡量的点
10. 找出owner
给每一个action找出owner，owner不一定是执行者，可以是监督者，
比如说，我们有一个action是迟到发红包，那一旦有人迟到，这个action owner就要追着迟到的人 发红包~~
完事儿~ 等着下次retro回顾一下你的action吧~
收工~
