回顾反思会：是执行敏捷项目管理的朋友们都不陌生的字眼。
简单交代一下，基本上我们项目是按迭代（2周）开展的，每个迭代开始之前产品将将要推进迭代的需求都梳理好，按照规则录入到管理工具中。迭代开始第一天，全体召开迭代需求评审会，产品经理面向团队所有成员逐条讲解需求的内容以及设计的假设约束等，这个过程团队成员有问题可以问，直至清晰。大家都没问题了。开始领任务，大家各就各位开始干活。等到迭代尾声时候，针对迭代实现的内容进行评审。这就算这个迭代的活儿干完了。但是有一个问题及时要回顾总结并且反思一下这个迭代里面那些做的好，哪些做的不好可以改进的地方。由此，就祭出我们的“回顾反思会”。
大家心目中，按理说，这就是一个类似“茶话会”呗。还有什么比坐着听别人说，自己象征性说点话更省劲的工作呢。
可能，大家最初心里都这样想把。
然而，真正的回顾反思会，并不是这样的。
回顾反思会是有几个要点的：
第一，趁热打铁的作用。
第二，过程改进。跟以前我们熟悉的PDCA、过程改进同等的作用。藉由刚刚结束的迭代工作，大家的表现。从团队建设贡献的角度，大家要将整个过程中做的好的点说出来，后面重点标杆；仍有上升空间的地方找出来，群策群力回顾一下过程识别一下问题，问题的原因找出来，试着看看下个迭代能不能有改善的办法或建议；最后回顾整个过程里面有没有做的不好，后续迭代可以不做的冗余项，或者改正它或者废掉它。这也是对大家一个迭代工作的尊重。
所以，它一定不是批斗会、忏悔道歉会。跟批斗会最大的区别在于，我们就是团队的主人，没人应该批评我们。其次跟忏悔道歉会不同的是，只是为了寻找改进的点，问题追责不是这个会议的主要目的。当然它也不是表彰会或吐槽会。
站的视角是：我们自己就是团队的一员，我想让我的团队在下个迭代变得更好，我有如下想法......
说到这，大家可能理解了。但是仍然觉得这是个形式化的会议。确实形式化，但是如果我们换个词“仪式感”，而且是要当做团队每个迭代都走执行的仪式，那么在整个项目的多次迭代顺延下来，我们是否就会每次都提高一点点了哦。
基本原理性思路交代完毕！是不是很好理解，看起来也很好执行吧！
接下来，到具体实操啦！
第一次 回顾反思会：在经历了多次的需求梳理、规划、评审之后，我们召开了第一次迭代回复反思会。这一次仪式感特别强烈。所有人都在。大家畅所欲言，气氛相当热烈。积极的人一下子能说出好多，不爱说话的同事轮到他是也能凑合一条。就这样我们轰轰烈烈的开了小半天。最后一整理洋洋洒洒四五十条，分分类合并同类项，也有三是多条；进一步看。好家伙，有的说架构不稳-建议重构，有的说测试服务慢-耽误效率。有的说对接口总约不上时间......就这样又花了一小时问题捋清楚了。大家发现，重构--暂时解决不了。测试服务器--暂时解决不了....等等逐条过完之后，整整占用了一下午的时间。于是就有开发人员开始抱怨，又是形式主义，耽误了半天开发时间，好像没有解决太多问题。于是开发人员一个接一个假装接电话离场了，剩下产品和几个爱说的人员继续扯来扯去.......等到再约第二次回顾反思会时，开发经理面有难色的问：可不可以派个代表去？！！！
经历了第一回顾反思的失败。大家总结：
1、主要有主持人。控制时间、控制节奏。能说的人别带节奏，别瞎扯。
2、区分技术和非技术。技术在说的时候，其他人基本听懂。其他人说时候技术根本关心。
3、界定好规则。说什么类型的有些已知的就不要说了。尤其架构这种不是不能说，但是至少是架构是级别的经过评估之后的慎重结论会更有意义。大家扯来扯去容易陷入进去，像是方案PK。
4、说出来的内容记录后，要有跟踪和落问题实方案。每个人说问题就要说出自己认为比较好的建议方案。不能只提问题。这样会帮助大家深度的思考问题，不是在会上凑数。
5、落实改进项要可执行。只有对团队有帮助了，大家看到效果才有积极性去参与。只是记录问题，大家只是知道问题，后续没有配套下个迭代进一步的改善性安排。大家参与度不高。
团队针对以上主要问题进行了部署和调整，敏捷教练专门负责记录、跟踪等。
第二次 回顾反思会：
经历了第一次的失败，大家显然谨慎多了。主要是主持人把话题及时拉回来。然后也提醒大家提前思考和总结。有的就说，没有的可以不用说；尽量是问题不是感受；更主要区分了管理类和技术类。同时，我们约定不管会上梳理了多少个问题。我们将问题由大家标记优先级1~正无穷的编号。会上只针对TOP5进行针对性讨论和下个迭代落实措施的建议。并由敏捷教练负责在迭代中观察改进项的落地情况。下个迭代会上进行通报。
先在各小组负责人中我们进行了试点，效果好了很多。相继又在技术团队开展，有了基本的成效。
大家反馈：至少有一个问题反馈和建言建议的渠道。这点就很不错。
以上，感谢阅读。感兴趣可以加微信：js_alice
转载请微信先告知，谢谢~
网友评论