《硝烟中的Scrum和XP》第10章 我们怎样做sprint回顾

第10章 我们怎样做sprint回顾

• 在有关回顾的一切中，最重要的就是确保能够进行回顾
• Scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机！
• 如果没有回顾，你就会发现团队在不断重犯同样的错误

我们如何组织回顾

• 常用做法

1. 根据要讨论的内容范围设定时间为1至3个小时
2. 参与者包括产品负责人，整个团队还有我自己
3. 我们换到一个封闭的房间中，或者舒适的沙发角，或者屋顶平台等等类似的场所。只要能够在不受干扰的情况下讨论就好
4. 我们一般不会在团队房间中进行回顾，因为这往往会分散大家的注意力
5. 指定鞭人当秘书
6. ScrumMaster向大家展示sprint backlog，在团队的帮助下对sprint做总结。包括重要事件和决策等
7. 我们会输液发言。每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做得更好，哪些需要在下个sprint中改变
8. 我们对预估生产率和实际生产率进行比较。如果差异比较大的话，我们会分析原因
9. 快结束的时候，ScrumMaster对具体建议进行总结，得出下个sprint需要改进的地方

• 我们的回顾会议一般没有太规整的结构。不过潜在的主题都是一样的：“我们怎样在下个sprint做得更好”
• 下图三列内容如下

1. Good：如果我们可以重做同一个sprint，哪些做法可以保留？
2. Cloud have done better：如果我们可以重做同一个sprint，哪些做法需要改变？
3. Improvements：有关将来如何改进的具体想法？

• 第一、第二列是回顾过去，第三列是展望将来
• 团队通过头脑风暴得出所有的想法，写在即时贴上，然后用“圆点投票”来决定下一个sprint会着重进行哪些改进。每个人都有三块小磁铁，投票决定下个sprint所要采取措施的优先级。他们可以随意投票，也可以把全部三票投在一件事情上。
• 根据投票情况，他们选出了要重点进行的5项过程改进，在下一个回顾中，他们会跟踪这些改进的执行情况
• 不过不要想一口吃成个胖子，这一点很重要

在团队间传播经验

• 一般来说，在sprint回顾中得出的信息都特别有价值。团队之所以很难全心投入工作，是不是因为销售经理常常揪出开发人员去在销售会议上充当“技术专家”？这条信息很重要。或许其他团队也有相同问题？
• 我们的处理策略比较简单。有一个人会参加所有的sprint回顾会议，充当知识桥梁。不用太正二八经
• 另一种方式，是让每个Scrum团队都发布sprint回顾报告。我们试过这么做，但发现很多人都不会去读报告 ，而就此展开改进的就更少了。所以我们还是用了上面那种简单的方式

变，还是不变

• 把sprint回顾结果贴在团队房间的墙上会更有效

回顾中发现的问题示例

• 我们应花更多时间，把故事拆分成更小的条目和任务

场景：这个问题很普遍。每天的例会上，都会有人说“我真的不知道今天该干什么” 动作：团队很可能会在下一个sprint计划会议上自己解决掉这个问题。如果它重复出现的话，就延长sprint计划会议的时间 场景：太多的外界干扰 动作

1. 让团队在下一个sprint上减少投入程度，这样就可以有更合理的计划
2. 让团队在下一个sprint上把干扰因素记录得更清楚一些：谁带来的干扰，占用了多长时间。也许这可以帮助我们在下次更好地解决问题
3. 让团队试着将所有的干扰因素转给ScrumMaster或产品负责人
4. 让团队指定一个充当“守门员”，所有的干扰都要经由他处理，其他人就可以把注意力保持在项目上。扮演者可以是ScrumMaster，也可以大家轮流

场景：我们办公室的环境太吵太混乱了 动作：

1. 试着创建一个更好的环境，或者把团队搬出去
2. 如果不可能的话，那就让团队在下次sprint上降低投入程度，并明确注明这是由于嘈杂混乱的环境导致的。希望这可以让产品负责人开始找上层管理者反映这种问题