(13)回顾会议

其实个人以为，回顾会议在scrum所有的events中是最重要的一个

正如上图所示，我们可以看到在整个scrum的价值流上，每个会议都有不同的对应意义：

planning meeting用来将目标分解并给团队，standupmeeting 则用来对team每天的工作进行跟踪，review meeting则是检视和调整目标，以适应当前的工作状态，而retrospective meeting则是team用来进行持续改进的一个过程。

所以从敏捷的核心价值–持续改进来说，回顾会议也是相当重要的一个环节。

关于回顾会议的意义，内容等，笔者在这里就不在多说了，因为很多文章和书籍都已经讲述了这个会议的重要性。那么在这里，笔者希望从个人的经验来阐述一些点，能够更好的进行回顾会议，从而让这个会议更好的为团队持续改进而服务。

1. 回顾会议不仅仅是回顾，更重要的是着眼于未来

很多团队在召开回顾会议的时候，更容易把它变成一个lession learn,找出做的不好的地方，然后总结经验等。这样做并没有什么不好，但是要注意的是，回顾会议更注重的是在下一个迭代我们要如何做才能做的更好，而不仅仅是总结以前失败的经验教训。团队要带有一定的目的性，就是在回顾会议上要形成真正的“决议”，这些“决议”能够对即将到来的迭代有更好的正面促进作用。这样才能使得回顾会议真正的成为一个不断推进团队进步的催化剂。

2. 回顾会议不能解决所有事情，它应该注重在最迫切的一些需求上

笔者在辅导过的一些团队中，往往在回顾会议上，大家打开了话匣子，气氛非常热烈，也有很多中肯的建议和看法，但是，我们要知道，一个迭代只有1-2个小时的回顾会议，实际上是解决不了很多的事情的，所以教练在这里要辅导团队，把视野看的更高远一些，让团队成员的思路更high level一些，找出2,3个点用来让团队在下个迭代做的更好，这样也可以更好的集中团队资源来进行一些改进。

3. talk is cheap, show me the action

回顾会议很容易转变成吐槽大会，因为团队会在开发过程中发现很多问题，但是有一些问题却不是团队自己能够处理或者搞定的，或者大家只是提出问题，并没有提出解决方法等，这样长期下来，回顾会议就会变成一种形式主义，大家的参与度也不会很高。所以团队要在每个迭代会议之后，列出一些迫切要解决的问题，并且提出一些切实可行的解决方案，并且指定owner,这样来保证在下个迭代，这些方案能够执行并起到效果。同时如果是团队无法解决的问题，也要记录下来，反馈出去，找相关负责人，看看能否尽快解决。

当然了，要做好回顾会议还需要很多工作要做，这里我只是提出了一些自己在这方面的一些经验之谈，如果大家有兴趣，我们还可以进一步的讨论这个话题。
最后一句话送给那些总是说太忙了，无法参加或者召开回顾会议的人们：

是的，他们是太忙了没有时间，他们总是忙于把时间用来生产错误的产品上。。。