在公司组织的 Agile Community 终于正式开始活动了。第一研讨会大家在谈回顾会议遇到的问题。

说起 Retrospective Meeting 总得来说，就团队自我能力的提高而言，我觉得它是最有效的手段之一。或者说，它至少是设计者，企图推进团队提高的一个重要思想。如同我们自己也常说的 “午日三省”。从自己的成功和失败中，是成本最低也最易做到的实践。一个被中国人都已经实践了两千年以上的方法，怎么可能会没有用处呢？

可实际的操作效果并不如看起来那么美好。我们要知道过程只是形式，形式本身不具备任何意义，做了回顾会议并不代表你得到了想要的东西。最更重并不是如何做？而是你取得了这个会议本来期望的Goal吗？实际工作中碰到的问题大概有着几个。

项目太忙，这次的回顾就不做了吧 ...

在任何时候都应该挤出时间来做的唯一原因就是，它能够带来“效益”，而且只有当我们持续不断地做，能让大家养成习惯，而好的习惯能贯穿每一天的工作，能够真实地提高效率。

组员对回顾会没有积极性，一种可有可无，无所谓的态度 ...

如果是本身不了解Scrum，那么需要好好培训一下。如果是工作态度有问题，更得好好谈一下。有一个小技巧是，在刚开始回顾的时候，不要死板板地直接进入主题，不妨同时也回顾一下这个Sprint发生的轻松愉快的事情。让大家放送心情，好的开始是成功的一半。

回顾工作的时候只记得做过什么任务。需要写做得好的和改进的意见时，憋不出来 ...

回顾会议一个Sprint才能做一次。其实它旨在大家做交流。而合格的程序员，应该在平时就对自己的工作细节了如指掌，有必要应该多做一些纸头笔记。个人能力的提高，当然是团队之福，更多得还是个人得益。对于有的就是想不出东西来的人，怎么办呢？首先，需要做适当的引导，他们他可能还不懂如何从工作中整理经验。还有一个技巧是，可以尝试 7 个帽子的方法，给它们带上一顶，“强迫”它们去思考。

没有明确可执行的改进Action

有时候，会出现这样的情况，好的和改进的意见特别多。多到无法衡量和跟踪。一定要给它们也排序，大家选择最重要的先改进。有时候，提出的意见太模糊，比如 “写程序的时候要小心，不要犯错。” 这个是无法跟踪和改进的，因为它几乎没有说什么，应该根据具体情况写得可实践。比如是因为常出现拼写问题，那么我们可以说 “安装Spell Check” 。 改进并不求多，但一定要落到实处。