如果有人问“计划会、每日站会、回顾会中只能留一个，你会留哪个”，我一定会选回顾会。计划会和每日站会的目标是保证项目进度，而回顾会的目标是改进项目组。
我们的流程特点
从流程来说，回顾会非常简单：定期地把大家聚到一起，或三言两语地吐一番槽，或七嘴八舌地甩一通锅，然后就各回各家各找各妈。但是显然，这种回顾会对项目组的成长没有什么帮助。
甩锅一时爽……然而解决不了任何实际问题
从流程来说，我们项目组的回顾会有几个不同之处。
首先，我们项目组召开回顾会的第一件事，就是检查上次会议的后续任务的落地情况——有时甚至要检查上上次会议的成果，因为一次回顾会的“决议”有时需要好几个迭代周期才能真正开花结果。毕竟，回顾是为了改进，改进绝不能停留在会议室、也不能停留在会议纪要上，而一定要有能落地的方案、要有方案的落地结果。否则，除了吐槽一时爽之外，回顾会开了也是白开。
这跟巡视组的“回头看”、“回马枪”是一个道理
其次，与自愿发言或者主持人点名发言不同，我们的回顾会要求每个人必须发言。发言的内容么，不外乎至少要说三个“做的比较好应该继续坚持的点”以及三个“做得不太好需要改变的点”这种。其实每个人都对必须发言这点是刚开始时的无奈之举，因为无论是自愿发言还是点名发言，都存在大家没有准备而随便说几句的问题。但是在推行一段时间以后，项目组每个人都会在日常工作中就留心哪些地方有问题、哪些事情挺不错，也会在日常工作中思考应当怎样改进和提高。只有这样，回顾会上才有得可说，不至于被主持人“还有没”“就这些”“还有吧你再想想”追问得哑口无言。
有些项目组的回顾会要求参会者把“做得好的地方”和“做得不太好的地方”先写在纸条上，然后逐一翻纸条来讨论。这样做当然无可厚非，不过我还是更倾向于公开发言的形式。第一，写在纸条上的内容通常都很简练，讨论时往往需要作者站出来做详细说明。这样一来，纸条就失去了它的匿名作用，与公开发言没有差别了。第二，公开发言有助于培养团队内开诚布公的交流氛围。就解决问题而言，最好的方式不是在回顾会上去反思、总结、改进，而是在问题发生时就发现、提出和解决它。如果内部都不能开诚布公的交流、而要靠小纸条这种方式来提意见，那这群人还能称作是一个团队吗？第三，公开发言对程序员是个不小的锻炼。程序员们总是有意无意地忽略表达与沟通的技巧——例如提出问题、列举事例、凝练论点、论述证明、总结发言，等等，以至于当在面试、晋升、技术分享、甚至是甩锅或者撩妹时，程序员们往往表现得张口结舌或者语无伦次，导致整个群体都被贴上了“木讷”“不好沟通”的标签。在回顾会上公开陈述自己的观点，无论对个人的表达能力还是对团队的沟通方式来说，都是很好的提高方式。
因为会上必须发言，所以我在回顾会前就会准备好发言提纲。这是我云笔记里记录的一篇提纲。
最后， 与个人发言一样，回顾会一定要有总结。这个总结，不仅是把参会者的发言复述一遍，更要把其中的最核心、最重要的意见和建议转化为可行的流程、举措，并指定负责人、以便于在下一个迭代周期内开始推动落实。这个事情说起来简单做起来难。为什么简单呢？因为办法总比问题多，回顾会上提出来的每个问题都能找出至少10种解决办法来。为什么难呢？因为我们必须从这10多种解决办法中，找到一个能够与项目组现行流程相契合的、在现行流程下最可行的方法来。
为什么强调现行流程呢？如果每一次回顾会都要在现行流程之外增加流程，很显然，日常工作流程会飞速膨胀，管理成本急剧上升，工作效率则会急剧下降。最后的结果一定是工作流程被丢到一边，大家怎么方便怎么来了。这样一来，回顾会的努力就完全成了水中捞月了。当然，有时回顾会也会删减工作流程，但这终归没有跳出对现行流程进行调整的五指山。
但是修改现有流程其实非常困难：不管是否合理、是否高效，现行工作流程一般是项目组成员在长时间的磨合、积累之后自发形成的，也是项目组成员非常熟悉和认可的。要想对它做出改变，就像要挪动一张桌子、在墙上开一扇窗户一样困难。这项工作不仅要求良好的流程设计——既能达到目标，又简便易行，还要求有力的推行、越挫越勇的毅力和长期的耐心。没错，即使简便易行，也要长期的、在挫折和阻力中，耐心地、一点一点地推动改变发生。
流程变更有点像火车并轨
我们的回顾成果
我们项目组就曾用这样的方式把代码评审加入到了敏捷开发的流程中来。
众所周知，代码评审是提高代码质量和编程能力的一个非常好的举措。我们项目组在调研了一些工具之后，也尝试着把它加入到我们的迭代流程中来。
最开始的方式是组织代码评审会，大家坐到会议室中一起看代码。但这样的评审会存在明显的弊端，在之后的回顾会上就被取消了，取而代之的是每个人在日常工作中自己去做评审。但这样也行不通。我们在回顾会上再一次讨论后，决定每个人都要在周二和周四的下午优先对其他成员的代码进行评审。这个法子收到了比较不错的成效，但还有一些不足。我们在又一次的回顾总结后，确定了每周二下午做开放式评审、每周四下午做回归评审的代码评审流程。再后来，我们还对代码评审结果做了量化分析……这样经过了若干次回顾会的讨论总结和若干个迭代周期的尝试推行，我们项目组才找到了适合自己的代码评审的方式。
这是在推行代码评审的过程中，我们的一次回顾会上的讨论记录
回顾会的“软条件”
不过，除了合理的流程之外，要想让回顾会发挥它应用的作用，还需要一些“软条件”。
首先，一定要建立起开诚布公的沟通氛围。回顾会的目标是改进团队的工作方式、让团队更愉快的合作、让团队成员更顺心的工作。回顾会绝不能用来追责、甩锅，这种事情只会让与会者越发地离心离德，让以后的合作由目标导向变成甩锅导向，最后无论要做什么事情都举步维艰，效率和成绩更是无从谈起。
岔开说一句，追责、甩锅这种情况在回顾会上也许比较少见，而在复盘会上更加常见。毕竟，一般都是出了问题才会开复盘会，而一般思维里，出了问题总要有人来负责和背锅。但是我认为，无论是回顾会还是复盘会，都应该着眼于未来而不是过去。过去已经过去，tomorrow is another day.
合作，而非对立，是teamwork的先决条件。
其次，开会一定要有会议纪要。纪要是会议的灵魂，任何不记录会议纪要的会议都是浪费时间。回顾会的会议纪要和其它会议的没什么两样，核心都在于后续任务以及任务负责人。有了这样的会议纪要，我们才能检查此前的任务有没有落地、落地的效果如何。这里可以给有道云笔记打个广告：它的会议纪要模板就挺不错的。
再岔开说一句，怎样组织一个高效的会议其实也是一门不大不小的学问。例如会前分发会议材料、会上记录会议纪要、会后跟进后续任务等工作，有时只是举手之劳，却能避免开一个会浪费十几个人的时间。
这是有道云笔记提供的会议纪要模板
最后，回顾会的主持人需要了解和使用一些引导大家开口的小技巧。有时，参会者的发言太过简练或者肤浅；有时，主持人知道——或者认为——参会者还有某些事情可以发言说一说；有时，主持人希望参会者能往某个方向多聊几句。这些情况下，主持人都会、也应该用一点小技巧来推动或引导参会者继续发言。例如，我们的回顾会主持人总会不停的追问“还有么”“就这些”“你再想想”，“逼”得参会者不断地去想、不断地去说。他的这点小技巧、小心思，也算是我们项目组的回顾总结会的一个小特色了。
组织会议和主持会议一样，是有技巧的