经过几个迭代的改进，我们组成员在回顾会议上，越来越能主动地参与到总结和分析中。但是看完此书，发现我们总结会议还有很多不到位的地方。
一、回顾检视的目标不明确。
现在回顾时一般流程是让成员分别写下本次迭代做得好的地方，做得不好的地方，可以改善的地方，然后分别投票出前三项。再进行讨论，最后总结出行动方案。虽然通过投票可以一定范围内的收敛讨论范围，但是几个迭代下来仍然觉得过于发散。比如上个迭代延期转测了一天，进过讨论认为是引入Typescript技术导致的，然后决定加强技能分享。看完此书后，觉得“在迭代中平滑引入新技术的方法”应该作为一次单独的回顾检视目标，结合本迭代的遇到的问题进行专项讨论，可能会更有效果。
二、分析手段过于单一
现在对讨论数据的分析还是缺乏分析手段，只有讨论和投票。结合上一迭代延期转测的问题，我觉得“五个为什么”就非常合适。假设有以下场景：
为什么会延期转测？
因为对Typescript不熟悉。
为什么不熟悉？
没有提前学习。
为什么没有提前学习？
...
那可能更能激发灵感，可以制定出更好的行动计划。
三、行动计划过于模糊
还是以上次回顾的结论为例：
后续要多注意实现方案的review，同步设计方案。
这就和SMART目标就严重不符。它不是具体的，没有讨论出哪种类型的方案需要review。没有可衡量性，怎么样才算通过review。
总之，结合实践，看完本书后还是非常有帮助的，里面许多激发灵感的方法，后续也可以尝试引入到我们回顾检视会中。我们微信公众号马上要停止服务了，是不是也可以举行一次项目的回顾检视会？
网友评论