序  言

谈起敏捷，很多人并不陌生，可能你的公司依旧在使用瀑布开发模式，可能已经转型为敏捷或者DevOps，也有可能正在处在这个转型期。不可否认的是，这个开发模式已经越来越热，甚至很多在几年前接触到但是抵触敏捷开发模式的公司，现在也慢慢的开始转型。从互联网公司到银行，从欧美公司到国内企业。

本人在上述三种“可能”的公司里都工作过，也帮助过一些公司从瀑布模式转型敏捷，有了一些经验。工作之余喜欢思考，这里就和大家分享一些个人的想法和遇到的事情。希望大家多多指教，互相交流。

本文是作者所在的桃花岛的分享会上，黄药师指点总结出的一些问题，相信很多开始使用Scrum框架的团队都会遇到其中的几条，希望能帮助到打架。

如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目  录

序  言.. 2

1   概述... 5

2   八项Tips. 4

3   回顾回顾会议... 4

4   题外话... 4

1          概述

本文是在一次桃花岛的黄药师小课堂上，黄药师分享的针对Sprint回顾会议的八项Tips，也是过去多年辅导企业转型中遇到的问题而总结出来的，妥妥的干货。敏捷团队本身对回顾会议都不陌生，但是相信文中提到的问题，你总会遇到几个。希望能帮助到大家。

2          八项Tips

直接上干货。

1.Better项。我们常常的做法是，列出三列，做的好的地方，待改进的地方，解决方案。其实做的好的点里，有一些是还有提高空间的，我们在这一列里额外加一项，叫它Better，并对其讨论，以期望下个迭代在这个方面做的更好。

2.分类。说完做的好的地方后，将其分类。同理，在讨论完每一项待改进点之后，也要分类。

3.不一言堂。Scrum Master收集完做的好的地方后，每一项都需要询问大家，是否认可这项是我们做的好的地方。有的时候，一个团队成员提出来的点，其他成员会有异议，可能他就不认为是团队做的好的地方。

4.排出前三名。做的好的地方和待改进的地方都要排序，建议大家投票排出前三项，汇报高层，并重点注意保持。

5.限制写内容时间。开会前，Scrum Master要声明限制多长时间，超时不让继续贴了。因为最开始写，大家是互不干扰的。大家开始讨论之后，再写出来的，就是受干扰了的项目。

6.分类要细。如果分类不细的话，会出现一种情况，比如做的好的里有一类叫流程，待改进的里面有一类也叫流程。那么就会带来一个误解，到底流程我们做的好还是不好。同时会带来另外一个问题，带改进项分类过大，导致出解决方案的时候不好写，因为我们需要根据具体的方面给出方案。分类细一点的话，可以帮助问题更聚焦，我们针对性的去解决问题更有效果。

7.鱼骨图分析。在分析待改进项的时候，我们可以参考鱼骨图来做分析。

8.限制改进项数量。即使待改进项很多，重要的也很多，我们也要限制数量，针对其中最重要的几个做解决方案，因为我们要考虑下个Sprint我们能改进那些。如果都列出来也许都改不了。

3          回顾回顾会议

What？回顾回顾会议，听起来好拗口，然而作者并没有写错字。

Scrum框架的特点就是易理解，难精通。其中的回顾会议也是如此，并不是说看了本书或者几篇文章就能开好，或者说开好了也不见得就能达到预期的收益。并且每个团队的情况还是不一样的，所以建议大家隔一段时间开完回顾会议之后，再回顾一下最近的回顾会议哪里有做得好的地方，哪里有待改进的地方，那么下一次开的时候，我们改善一下。敏捷的精髓，不就是持续改善吗？

4          题外话

照例，张教主给出一个题外话，分享一个小故事。

曾经在一次workshop上，有企业问到，“我们公司回顾会议起初开的挺好，不过后来就变成形式了，因为提出了太多的问题和方案，最后测试推给开发，开发推个测试，没人真正的行动起来，后来就都不爱在会议上发言了”。

之所以单拿出这个问题，是因为它太典型了。能发现问题是好事，但是问题太多的话，如上面第八项所说，聚焦于最严重的几项，可以是2-3项或者更少，优先解决他们，那么在下个迭代中，团队就会看到改进，士气受到鼓舞，之后的回顾会议就更有积极性了。至于方案实施的互相推诿，那么在这种情况下，就需要有一个有决策力的领导出面解决。然后当其真正的实施起来之后，团队看到了解决问题带来的好处了，以后的流程就通顺了。