开好「敏捷」反思会，你必须知道的8个忠告！

又是年底，各大app都推出各种年度总结，年度回顾。这些总结有的很有趣，有的很扎心，在推动年底KPI完成的同时，也给我们带来不同角度的思考。而在敏捷工作方法中，反思回顾也是很关键的一环。那么我们如何从敏捷反思**中获得更多积极成果，并由此建立一支强大的团队？

我一直觉得所谓“反思/回顾”其实是在展望未来。因为这个词表达的更多是对未来的思考，而不是停留在过去。

我们可以问自己一个问题：“就我们现在所知道的一切，接下来我们要做什么实验？如何改进我们的工作，如何给用户带来更好体验？”

反思**议应该是怎样的?

产品开发循环由两个重要的部分组成：

1. 其中一个是产出部分（左边：怎样完成迭代目标，保质保量交付）；
2. 一个是回顾反思的部分（右边：检查每个迭代的工作做得怎么样）。

不仅要找到做的不好的地方，还要找到做得好，值得扩大的地方：如何快速设计一个实验，进入下一个循环，找到改善团队工作，让用户更满意的方式。

回顾部分请看下图右边：

来源：助你成为一个优秀的协调者的敏捷回顾**议指南

当反思**让人头大的时候……

我参加过很多团队的迭代反思**，发现很多人参加反思**的时候脸色都不太好看。这些有不满情绪的人都有一个共同点，那就是他们的团队都“无情地专注着改善工作”。认真反思，专注改善有什么问题？

来听听一位程序员小哥的直白吐槽：“反思如果只强调错误的话，那叫批斗大**好了，大家都是loser。总是不被肯定，谁乐意呢？”

团队讨论了什么是有效的，再三强调了那些无效、低效的东西（也许这已经让他们觉得自己被失败的乌云笼罩），同事之间相望无言，长长地叹了口气。这时另一位工程师（已经因为反思**而在另一个**议上迟到）给**议作总结，他说：“好的，那我们就不要把代码都拖到迭代的最后一天再提交啊。”

在这个**议中，他们没有任何机**去放大团队的优点，因为他们根本没有讨论这些优点。

反思**应该是这个样子的

反面模式（anti-pattern）让回顾**议变得可怕，因为那样我们**回顾最后一次迭代，我们**划分两列，一列是有效做法，一列是无效做法，然后我们迅速得到一些可以用于下一次迭代的解决方法。

然而在这个过程中，我们没有运用任何科学方法。没有收集数据，没有研究，没有提出假设再去验证，深刻的思考也是少得可怜。

结果呢？你的团队在下一个迭代里根本不是用实验的方式快速，或做出一些真正的改进。

8招让你的反思**更有效

1. 放大，放大，再放大！放大优点！与其像老妈子一样念叨那些做得不好的地方，不如让每个成员想一个积极的闪光点来开始这次的反思**？
2. 别急着得出下一步行动。试着多思考，深入思考，和大家讨论分析，“挖”到真正的问题。立刻得出结论的解决方案往往是治标不治本，流于表面的。
3. 如果你们在没有深入分析怎么去改进（用到5whys分析法，力场分析法，影响地图分析法，或是鱼骨图分析法），那说明你可能太快跳到解决方法这一环节了。
4. 如果开完反思**不能让你对下个迭代的某个实验、某个任务感到一丝兴奋，那也许就没有尝试的必要了，再斟酌。
5. 改变你的方法。如果每次开反思**，你都**问：“哪些方法有效，哪些无效？”然后对任一列中最高的项目进行投票，你的团队很快**感到无聊。用一些敏捷反思的工具，比如：Retromat也许能帮助调动你的反思**氛围。
6. 以询问成员对「反思回顾」这一行为的看法来结束每一次回顾**议。这可能看起来有点简单，但它确实有效：不断改进反思**本身就是一种进步。
7. 消除障碍。问自己：我能做些什么来帮助团队不断改进，并用好的心态应对成员的各种反馈。
8. “迭代警察”这种东西是不存在的。所以不要像上了发条一样，你的团队应该根据实际情况偶尔停下来休息一下。从分析中得出假设并提出富有创造力的实验，这样可能**令人觉得很费劲。

所以每隔一段时间，就和整个团队一起出去玩，一起享受美食，团建+回顾反思吧（新的反思**形式get）。

这篇文章的灵感来自发布在Podojo.com网站的反思**的反面模式：反思**不应该让人感到挫败。

原作者：Catherine Louis

原文链接：https://opensource.com/article/18/3/tips-better-agile-retrospective-meetings

译者：「即能小程序」，公众号：「即能学习」

本文由 @即能 翻译发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议