敏捷开发-回顾会议

保持透明性、检视与调整是Scrum的三大支柱，
以此作为支撑我们才可以对整个开发过程进行持续的改善。

回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上，ScrumMaster鼓励团队在Scrum过程框架和时间范围内，
对自己的开发过程进行改进，并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。
检验要确定好的做法继续保持，以及需要摒弃或改善的做法。

这些包括：Scrum团队构成、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。
在Sprint回顾会议的最后，Scrum团队应该确定将要在下个Sprint中实现的有效改进方法，并在接下来的Sprint中付诸行动。

然而，开好回顾会议，让其起到促进团队持续改善的效果并非易事。
要开好回顾会议对会议的形式、主持人的协调能力都有很高的要求。

如果回顾会议过于形式化和刻板则会使团队丧失参与的兴趣，
不利于团队成员说出真实的想法，也不利于发掘更有效的改进建议。

ScrumChina linkedin group（http://www.linkedin.com/groups?gid=3343227）
对此进行了热烈的讨论，也分享了不少有用的实践，许多参与者认为回顾会议应该保持轻松愉快的氛围，
让大家畅所欲言，在这里挑出其中的一些供大家参考：

Jingbin Liao：建议增加一个感谢环节，每个人都可以感谢其他人对我的帮助，感谢某某某对团队做出的贡献。

Kai Wang ：我们的实践一般会再加一个问题：对于not working的，
我们要采取什么行动 如果这个sprint提的行动，到下一个sprint还没有执行，就加大一个字号，
到下下一个sprint还没有执行，就再加大一个字号，以此类推。

Hongquan Yin ： 讨论什么不好，然后就要想出解决的方法。
另外反思会另外一点就是增进团队成员之间的情感交流，因为我发现在做scrum task的时候，更多的是就事论事，比较干燥。

Fred Liu ：retrospective是对过程的反思，形式不固定，搞点活泼的也挺好，不过主题不要跑偏了。 说不定可以来点禅家的冥想
Mike Li ：制作一些表情符，用这种方式让大家表达一下对Sprint的感受，高兴？沮丧？激动？无所谓？

Mark He ： 个人觉得Retrospective最重要还是要能听到真话，Team和个人的Pain Point是什么，以便持续改进。
所以除了什么方面做的好，什么不好之外，一般我会在回顾会议开始加小环节，
总结通报上次会议定下来的行动列表，哪些做了，哪些还没有，没有做的联系人是谁，原因是什么，接下来会怎么做。
回顾会议的结尾，也会做个小结，根据会议内容列出行动列表，便于后期检查。
见过有Team开了会但是没有行动列表的，没有实实在在的解决问题，结果每次开讨论的问题都差不多，最后Team就皮掉了。
当然这个方法未必就一定好，只是个人几次实践下来发现效果还可以，至少Team知道确确实实重视他们的意见，也在不断改进，就会更加愿意说真话，良性循环 。

De Yi (Linda) Liu：我们的做法是（个人感觉很有效）：每人发三张便签纸，
分别写下： – What to Keep – What to Change – What to Try
每张纸上不能超过三条。如果实在没有，也可以不写，或少于三条，但不能一张也不写。
（可以记名，也可以不记名，由Team自己决定） 然后把所有的纸条收集到一起，贴到白板上，总结出每一项的Top 3。
经过小组一致同意，确定下来。在新的Sprint中随时跟踪执行情况，并在下一个Retrospective的时候总结。
这样做有很多好处： – 每个人都得以发言 – 大家不会受到某些比较“积极”发言的人的影响 我们在使用这种方法前，往往只是Scrum Master或少数几个活跃的成员发言，其他人”默许”。
但是用了这种方法后，每个人都能提出很有建设性的建议。 另外，如果是记名的，还可以用来评选Sprint Champion。
比如谁的“What to try”的建议被采用得最多。
这又引出我们活跃团队气氛的一个方法：Sprint Champion。
我们的Scrum Team在Sprint Review、Plan、Retrospective时，都会评选不同的Sprint Champion。
经过实践，效果非常好。当然，Champion的内容要选择有利于Team work的项目，而不是突出个人贡献。