这是《落叶》文集里第 97 片落叶，希望你能喜欢，不为别的，只为这份坚持。
No matter how good a Scrum team is, there is always opportunity to improve. Although a good Scrum team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.
The sprint retrospective is usually the last thing done in a sprint. Many teams will do it immediately after the sprint review. The entire team, including both the ScrumMaster and the product owner should participate. You can schedule a scrum retrospective for up to an hour, which is usually quite sufficient. However, occasionally a hot topic will arise or a team conflict will escalate and the retrospective could take significantly longer.
为什么先引用 Sprint Retrospective Meeting 的原文解释呢？因为很多名词的释义在被翻译成中文之后，要么比较晦涩，要么就有偏差，通过原文能更精准地理解这个 Scrum 里重要的工件之一。
今天我这个老兵来理论结合实践的说说 Sprint Retrospective Meeting 在 Scrum 里到底有什么用，后续会结合更深入的学习实践继续改进更新。
1、Spring Retrospective Meeting 是 Scrum 三大会议中最重要的一个，它通常是在每个 Sprint 结束的时候，由 SM 组织，全员参与的一个反思会；
2、这个会议经常会被团队在实施 Scrum 的时候省略，他们往往忽视了总结、分析、持续改进对于团队战斗力的提升价值，认为每个 Sprint 结束时都要开一个反思会，太浪费时间了。其实套用中国一句古话，磨刀不误砍柴工。这个会议其实就是一个磨刀的过程；
3、SM 在这个会议上，需要组织团队成员，把刚刚结束的 Sprint 里，做的不好的地方和做的好的地方都说出来，好的实践要总结、提炼，形成自己团队的规则保持下去，不好的实践就需要去对其做3W分析，找出其根本原因和解决方案，列入需要改进的清单里，最终从待改进清单里挑2~3个合适的、优先级高的改进点放入下个 Sprint 去优化实践。
4、主持 Retrospective Meeting 需要注意以下几点，也可以理解为就是营造会议氛围的注意事项：
4.1 就事论事，对事不对人，不能把反思会开成批斗会或吐槽会；
4.2 国人习惯，很难当面指出自己或其他人的问题，不能把反思会开成 SM 一个人的分析汇报会，前期可以采用匿名提交便笺纸的形式，参会者每人在纸上写上3件好的实践和3件不好的实践，然后交给 SM，再列到白板上，挑出票数最多的2~3件实践，大家一起集中讨论，因为有可能可改进点比较多，但时间和精力毕竟有限，所以需要集中优势兵力，依次击破；
4.3 养成每个人都要发言，都要积极参与的习惯；
5、Retrospective Meeting 的参会人员必须由 SM 和团队共同决定，PO是否参与取决于 PO 和开发团队之间是否信任和有安全感，管理者不建议被邀请，那会使整个反思会趋于“安静”或“正常”；
6、反思会这种形式其实在我们的日常工作生活里也经常被使用，比如职场中的月度总结和年度总结，还有家里每个月或者每个季度的财务盘点，或者个人的按周按月的阅读计划写作计划的盘点，都是不同场景下的反思会模式。
到这里，Scrum 的七把剑都聊完了，这七把剑其实不仅仅只能应用于 Scrum，在工作生活的方方面面，都可以灵活应用它们。我个人理解，这种所谓的方法论，本身就来源于生活，它们都是跨界而来的，是敏捷的先行者们从制造行业等其它百年行业中汲取改造而来，所以它们能被跨界应用到其它领域中也就顺其自然了。
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
