第10章 我们怎样做sprint回顾
- 在有关回顾的一切中，最重要的就是确保能够进行回顾
- Scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机！
- 如果没有回顾，你就会发现团队在不断重犯同样的错误
我们如何组织回顾
- 常用做法
- 根据要讨论的内容范围设定时间为1至3个小时
- 参与者包括产品负责人，整个团队还有我自己
- 我们换到一个封闭的房间中，或者舒适的沙发角，或者屋顶平台等等类似的场所。只要能够在不受干扰的情况下讨论就好
- 我们一般不会在团队房间中进行回顾，因为这往往会分散大家的注意力
- 指定鞭人当秘书
- ScrumMaster向大家展示sprint backlog，在团队的帮助下对sprint做总结。包括重要事件和决策等
- 我们会输液发言。每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做得更好，哪些需要在下个sprint中改变
- 我们对预估生产率和实际生产率进行比较。如果差异比较大的话，我们会分析原因
- 快结束的时候，ScrumMaster对具体建议进行总结，得出下个sprint需要改进的地方
- 我们的回顾会议一般没有太规整的结构。不过潜在的主题都是一样的：“我们怎样在下个sprint做得更好”
- 下图三列内容如下
- Good：如果我们可以重做同一个sprint，哪些做法可以保留？
- Cloud have done better：如果我们可以重做同一个sprint，哪些做法需要改变？
- Improvements：有关将来如何改进的具体想法？
- 第一、第二列是回顾过去，第三列是展望将来
- 团队通过头脑风暴得出所有的想法，写在即时贴上，然后用“圆点投票”来决定下一个sprint会着重进行哪些改进。每个人都有三块小磁铁，投票决定下个sprint所要采取措施的优先级。他们可以随意投票，也可以把全部三票投在一件事情上。
- 根据投票情况，他们选出了要重点进行的5项过程改进，在下一个回顾中，他们会跟踪这些改进的执行情况
- 不过不要想一口吃成个胖子，这一点很重要
在团队间传播经验
- 一般来说，在sprint回顾中得出的信息都特别有价值。团队之所以很难全心投入工作，是不是因为销售经理常常揪出开发人员去在销售会议上充当“技术专家”？这条信息很重要。或许其他团队也有相同问题？
- 我们的处理策略比较简单。有一个人会参加所有的sprint回顾会议，充当知识桥梁。不用太正二八经
- 另一种方式，是让每个Scrum团队都发布sprint回顾报告。我们试过这么做，但发现很多人都不会去读报告 ，而就此展开改进的就更少了。所以我们还是用了上面那种简单的方式
变，还是不变
- 把sprint回顾结果贴在团队房间的墙上会更有效
回顾中发现的问题示例
- 我们应花更多时间，把故事拆分成更小的条目和任务
场景：这个问题很普遍。每天的例会上，都会有人说“我真的不知道今天该干什么” 动作：团队很可能会在下一个sprint计划会议上自己解决掉这个问题。如果它重复出现的话，就延长sprint计划会议的时间 场景：太多的外界干扰 动作
- 让团队在下一个sprint上减少投入程度，这样就可以有更合理的计划
- 让团队在下一个sprint上把干扰因素记录得更清楚一些：谁带来的干扰，占用了多长时间。也许这可以帮助我们在下次更好地解决问题
- 让团队试着将所有的干扰因素转给ScrumMaster或产品负责人
- 让团队指定一个充当“守门员”，所有的干扰都要经由他处理，其他人就可以把注意力保持在项目上。扮演者可以是ScrumMaster，也可以大家轮流
场景：我们办公室的环境太吵太混乱了 动作：
- 试着创建一个更好的环境，或者把团队搬出去
- 如果不可能的话，那就让团队在下次sprint上降低投入程度，并明确注明这是由于嘈杂混乱的环境导致的。希望这可以让产品负责人开始找上层管理者反映这种问题
