开好敏捷反思会你必须知道的个忠告

　　又是年底，各大app都推出各种年度总结，年度回顾。这些总结有的很有趣，有的很扎心，在推动年底KPI完成的同时，也给我们带来不同角度的思考。而在敏捷工作方法中，反思回顾也是很关键的一环。那么我们如何从敏捷反思会中获得更多积极成果，并由此建立一支强大的团队？
　　我一直觉得所谓＂反思/回顾＂其实是在展望未来。因为这个词表达的更多是对未来的思考，而不是停留在过去。
　　我们可以问自己一个问题：＂就我们现在所知道的一切，接下来我们要做什么实验？如何改进我们的工作，如何给用户带来更好体验？＂
　　反思会议应该是怎样的?
　　产品开发循环由两个重要的部分组成：
　　其中一个是产出部分（左边：怎样完成迭代目标，保质保量交付）；
　　一个是回顾反思的部分（右边：检查每个迭代的工作做得怎么样）。
　　不仅要找到做的不好的地方，还要找到做得好，值得扩大的地方：如何快速设计一个实验，进入下一个循环，找到改善团队工作，让用户更满意的方式。
　　回顾部分请看下图右边：
　　来源：助你成为一个优秀的协调者的敏捷回顾会议指南
　　当反思会让人头大的时候……
　　我参加过很多团队的迭代反思会，发现很多人参加反思会的时候脸色都不太好看。这些有不满情绪的人都有一个共同点，那就是他们的团队都＂无情地专注着改善工作＂。认真反思，专注改善有什么问题？
　　来听听一位程序员小哥的直白吐槽：＂反思如果只强调错误的话，那叫批斗大会好了，大家都是loser。总是不被肯定，谁乐意呢？＂
　　团队讨论了什么是有效的，再三强调了那些无效、低效的东西（也许这已经让他们觉得自己被失败的乌云笼罩），同事之间相望无言，长长地叹了口气。这时另一位工程师（已经因为反思会而在另一个会议上迟到）给会议作总结，他说：＂好的，那我们就不要把代码都拖到迭代的最后一天再提交啊。＂
　　在这个会议中，他们没有任何机会去放大团队的优点，因为他们根本没有讨论这些优点。
　　反思会应该是这个样子的
　　反面模式（anti-pattern）让回顾会议变得可怕，因为那样我们会回顾最后一次迭代，我们会划分两列，一列是有效做法，一列是无效做法，然后我们迅速得到一些可以用于下一次迭代的解决方法。
　　然而在这个过程中，我们没有运用任何科学方法。没有收集数据，没有研究，没有提出假设再去验证，深刻的思考也是少得可怜。
　　结果呢？你的团队在下一个迭代里根本不是用实验的方式快速，或做出一些真正的改进。
　　8招让你的反思会更有效
　　放大，放大，再放大！放大优点！与其像老妈子一样念叨那些做得不好的地方，不如让每个成员想一个积极的闪光点来开始这次的反思会？
　　别急着得出下一步行动。试着多思考，深入思考，和大家讨论分析，＂挖＂到真正的问题。立刻得出结论的解决方案往往是治标不治本，流于表面的。
　　如果你们在没有深入分析怎么去改进（用到5whys分析法，力场分析法，影响地图分析法，或是鱼骨图分析法），那说明你可能太快跳到解决方法这一环节了。
　　如果开完反思会不能让你对下个迭代的某个实验、某个任务感到一丝兴奋，那也许就没有尝试的必要了，再斟酌。
　　改变你的方法。如果每次开反思会，你都会问：＂哪些方法有效，哪些无效？＂然后对任一列中最高的项目进行投票，你的团队很快会感到无聊。用一些敏捷反思的工具，比如：Retromat也许能帮助调动你的反思会氛围。
　　以询问成员对「反思回顾」这一行为的看法来结束每一次回顾会议。这可能看起来有点简单，但它确实有效：不断改进反思会本身就是一种进步。
　　消除障碍。问自己：我能做些什么来帮助团队不断改进，并用好的心态应对成员的各种反馈。
　　＂迭代警察＂这种东西是不存在的。所以不要像上了发条一样，你的团队应该根据实际情况偶尔停下来休息一下。从分析中得出假设并提出富有创造力的实验，这样可能会令人觉得很费劲。
　　所以每隔一段时间，就和整个团队一起出去玩，一起享受美食，团建+回顾反思吧（新的反思会形式get）。
　　这篇文章的灵感来自发布在Podojo.com网站的反思会的反面模式：反思会不应该让人感到挫败。
　　原作者：Catherine Louis