迭代回顾

进公司之前只听说过敏捷，上第一个项目果然经历了文化不适应。和十多个小伙伴在客户现场，第一次看到物理墙，参加站会，IPM...短短一个月时间见识了敏捷的形。

在我司，你随便找谁都能聊敏捷，各种培训、session、workshop也扎根于敏捷。所以我司交付项目基本都不会设置敏捷教练，人人都可以是Scrum Master，敏捷教练的职责融入了每个角色，项目上的敏捷实践也都是轮流负责。就这样经过几个项目的洗礼，从一开始按部就班的run着各项实践，到利用敏捷实践促进团队深度协作，不断对项目进展进行审视、调整、改进，越来越理解敏捷精神。

这里想聊聊敏捷实践里最容易被忽略的活动 —— 迭代回顾（Sprint Retro）。迭代回顾的目的是让团队在每轮迭代结束时都可以对scrum过程进行检视并作出调整。先简单说一下Retro的大致流程：

1.团队第一次Retro或有新成员加入时首先宣读Retro原则以及做安全度调查。这个仪式感很有必要，明确会议目标，让每个人都感到被尊重，鼓励大家发表意见。

2.快速回顾上个迭代的Action list。

3.然后设定timebox，团队成员开始按well，less well，suggestion几个维度将这个迭代的记忆点写在sticker上贴出来。Well的部分往往是团队需要继续发扬光大的好实践，让大家看到项目成果，提升信心。Less well和suggestion可能是需要作出调整和改进的点。

4.快速过一遍所有sticker并将同一类事件分为一组。投票出最想进一步讨论的三个问题。

5.对这三个问题进行深入讨论，制定改进意见，列入Action list。每个Action应该由合适的Owner持续跟进，直至问题解决（可参考PDCA循环大法）。

下面从我参与过的项目给出一些仅供参考的数据。

我上过的几个项目的Retro情况

其中未进行或无法持续进行Retro的原因（排名不分先后）

Retro的价值很容易被低估。比如我的第一个项目走看板，而且在客户现场没有场地支持，就没有retro这回事。还有个onsite项目每次发布后做一次回顾，由于间隔时间太久参与人数又多，往往贴完well，less well，suggestion，归类投完票一个多小时已经过去了，有时候甚至来不及制定action就结束了，也没有follow-up。还有个不到两个月的项目，进展非常顺利，到项目结束了大家觉得应该回顾回顾，retro了才发现，原来项目还有许多值得改进的地方，并不是想象中那么完美。

随着我对敏捷越来越了解，逐渐体会到，当项目进展不顺时，Retro鼓励我们聚焦问题，快速调整；当项目进展顺利时，Retro提醒我们消除自满，持续改进。

记录几次比较好的Retro吧。

第一个例子是在项目大概运行了3个迭代之后，我们发现每个迭代完成的点数有逐步下降的趋势，于是专门用一次retro进行根因分析。步骤如下：

1.申明复盘原则：对事不对人。聚焦问题 => Velocity差。

2.通过头脑风暴对问题域进行发散和收敛。先尽量找出所有潜在问题，然后对每个问题进行投票，聚焦排名前三的问题：环境不稳定、上下文不足、技术支持（主要是客户方TL）不足。

3.分组讨论，从技术，流程，合作这几个维度对这三个问题进行深度分析，给出解决方案。小组讨论的时候也应遵循发散-收敛原则，最后的产出应该是按优先级排好序的可行方案。具体方案就不在这里列出了。

4.将产出方案落实到人，确定复查计划，确保后续跟进。

再说第二个例子。记得有一个迭代做legacy flow enhancement，需求颇为复杂，开发们对用到的技术栈又不熟，在啃老旧代码时纷纷陷入遗留下来的各种问题大坑中无法自拔，加班加点的赶工。于是这次迭代的retro上我们做了团队健康度调查，自己的感受是唯一的打分标准，这样才能了解大家的实际情况。

我们知道激励模型，人最舒适的工作状态是有85%的任务在自己能力范围内，15%需要挑战才能完成。如何让每个组员达到这个平衡，首先需要我们认识到每个人所处的状态。

最后总结一下，Retro鼓励每个团队成员在做项目过程中不断发现问题、思考解决方案、反思总结，提升每个人在项目中的参与度和ownership，获得团队成员和团队整体的持续提升。

项目出现问题时，如果团队没有及时意识到发生了什么，就有可能如蝴蝶效应一般导致项目失控。当我们一起停下来正视问题并合力分析解决问题，经过这个团队磨合、积累经验的过程，会发现项目会进入到一个新的“境界”（柳暗花明又一村）。