第十二讲 Sprint Retrospective

一个冲刺里有4种事件。Sprint Planning、Daily Scrum、Sprint Review和Sprint Retrospective。第十一讲谈到Sprint Review。第十二讲，详细介绍Sprint Retrospective。Sprint Review和Sprint Retrospective这两个会议都是“检视--调整”活动，但目的不同。Sprint Review，检视的是产品本身。而Sprint Retrospective，检视的是产品构建的过程。

讨论主题 

1.怎样组织Sprint Retrospective?

2.观摩一个Sprint Retrospective的例子

3.Sprint Retrospective与信任、容错的敏捷文化

一、怎样组织Sprint Retrospective

时间安排：团队在Sprint Review以后，下一个Sprint Planning之前，进行Sprint Retrospective。对于为期4周的Sprint，时间盒为3小时，时间短的Sprint，会议时间相应缩短。

会议主题：改进Scrum团队的工作方式

会议围绕三个基本问题：哪些事情做的好？哪些事情做的不好？哪些事情可以换一种方式做？什么是换一种方式呢？举个例子。开发者单兵作战，各干各的，是一种工作方式，团队协作，也是一种工作方式；手工测试是一种工作方式，自动化测试也是一种工作方式。从单兵作战到团队协作，从手工测试到自动化测试，工作方式越来越好，这就是改进工作方式。

一个团队的工作方式与“人、人与人之间的关系、过程和工具” 这些要素紧密相关。所以要改进工作方式，就要关心团队成员的情绪，让团队成员之间配合更加默契，气氛更加和谐。通过优化过程，辅以工具，使得团队工作的更加愉快而高效。虽然改进随时都可以做，但Sprint Retrospective提供了一个正式的机会，关心Scrum团队自身。

我们强调，不要在Sprint Retrospective会议上指责个人。那么有没有个人引起的问题呢？当然有。个人的问题，通过其他途径解决，比如经理和员工个人的绩效谈话。Sprint Retrospective的重点在于，为团队提供一个专门的途径，通过改变工作方式，帮助团队成长。

参会者：Scrum团队

开发团队里的每一个人，包括做设计、构建和测试的人，都必须参加。Product Owner原则上应该参加。

Scrum Master必须参加。第5讲谈到，对于Scrum团队来说，Scrum Master履行主导过程改进的职责。她可以指出团队在哪些地方没有遵循团队一致认同的过程，鼓励团队基于Scrum过程框架，实现和改进自己的开发过程和实践。Scrum Master可以主持Sprint Retrospective，也可以让团队成员轮流主持。

会议流程：

A.Scrum Master需要确保会议如期召开、参会者理解会议目的、在时间盒内达成会议目标。

B.会前准备（输入）

1.定义回顾重点。例如，重点关注真正的需求，搞清楚为啥我们做的并非客户所想要的。又例如，重点关注如何提高我们的测试驱动开发的技能。

2. 选择活动。例如头脑风暴、分组投票。

3.收集客观数据：例如Sprint燃尽图和已经开始但还没有结束的Product Backlog Item数量。

C.议事日程

议事日程包括5个环节

1、营造气氛：为了让大家愿意参与讨论，需要营造一个轻松和缓的气氛，人们在表达意见的时候有充分的安全感，不担心受罚。

2、建立共同背景：为了不使Sprint Retrospective这样一个过程改进活动退化为争执，需要分享数据，基于事实，为团队建立共同的认知基础。

3、识别见解：通过头脑风暴等活动得出见解，哪些事情做的好？哪些事情做的不好？哪些事情可以换一种方式做？

4、确定行动计划：定义具体、可行的行动计划。

5、结束会议：重述团队决定采取的行动。对参会者，特别是Scrum团队以外的参会者表示感谢。感谢大家抽出宝贵时间，参与分析，贡献见解。

D.会议成果(输出)：识别出的行动计划

二、观摩一个Sprint Retrospective的例子

百闻不如一见。Agile Retrospectives: Making Good Teams Great 这本书的第一章为我们展现了一个Sprint Retrospective的例子(有删减)，我们一起观摩一下。

这是一个财务软件的开发团队，他们的Sprint Retrospective每两周一次。团队成员轮流担任会议主持人，这周轮到黛娜。

1. 营造气氛

所有的团队成员围坐成半圆形，前面有一块很大的白板，在白板上贴着几张图表。等大家都坐下后，黛娜开始发言：

我们将用1小时的时间，检查刚刚过去的这个迭代，反思我们的工作方法。这次，我们把重点放在开发流程上，因为我们都注意到软件缺陷的数量有所增加。在看有关具体数据之前，我们先做一个快速登记：请每个人用一到两个词形容一下，你此时此刻有什么感觉？

团队的6名成员分别给出了简短的回应。

困惑。

第一个人说。

好奇。

第二个人说。

失望。

第三个人回答。

在营造气氛这个环节，团队成员坐在一起，就有了交流的气氛，看着白板上的图表，自然会关注要讨论的重点。主持人请各位说说感觉，大家就这样开口了。

2. 建立共同背景

黛娜接着往下进行。

我们先来看一下软件缺陷的统计数据。

黛娜边说边指向一张大的图表，上面显示着开发出来的每项功能，对应着他们测出的缺陷数量。

在建立共同背景环节，大家要看同一张图，这是建立共同背景的方法。如果没有图，或者参会者只在会前看局部信息，就不容易建立共同背景。

3. 识别见解

黛娜问：

到底出现了什么问题？当你看到这些功能项和缺陷数据的时候，请给出一个你的解读。

她拿出一些即时贴：

让我们回顾一下这次迭代开发过程中发生的事情， 写在即时贴上。哪些事情让你感到受挫，请用橘黄色的即时贴写出来。写好之后贴到墙上的白板上。

5分钟后，团队成员们走到白板前，将各自的即时贴贴在白板上。

这些事情中的哪些可能是由相似的原因导致的呢？

黛娜问道。大家开始移动这些即时贴，把两三个由相似原因导致的事情凑在一起。

10分钟后，分出了4组，大家给这4组分别起了一个标注名称：不一致的匹配，急于进行开发，软件设计缺陷，和遗留代码问题。

大家发现了什么？哪一条是导致大多数软件缺陷的原因？

黛娜问道，大家开始就这些因素进行讨论。讨论结果，大家一致同意是遗留代码问题。

在识别见解这个环节，我们要注意学习主持人是怎样做引导的。她邀请每个人独立的在即时贴上写出记得的事情，用橘黄色表示感到挫折。这样每个人都能独立思考，发表见解。她引导大家自己进行分类，分析根本原因，最后找到最主要的原因。整个过程主持人重在引导团队，而不是发表自己的见解。

4. 确定行动计划

我们再用1分钟的时间头脑风暴一下，哪些办法能在下一个迭代周期中降低软件缺陷率？

大家很快的给出了5个不同的改进办法。

圆点贴投票。每人两个圆点贴，自己决定。

黛娜说。

2分钟后，大家选出了得票最多的一个办法。

现在，我们来制定一下具体实施细节。

黛娜提出。

大家又讨论了15分钟，找出了具体实施细节的行动步骤。

1.和支持小组的莎莉不定期地会晤

2.针对我们用到的遗留代码编写测试程序。

3.邀请莎莉每周用一两个早晨的时间来我们团队指导一下。

好，时间快到了。我们怎么才能知道遗留代码问题得到了解决？

黛娜问道。

如果我们看到软件缺陷数减少，就表明这个问题已经得到解决了。

一名成员说。其他人表示同意

是的，这是一个关键指标。那我们就在下次的Sprint Retrospective会议上看一看这个指标。

在确定行动计划这个环节，有两个重点：1、行动计划是大家投票表决得出来的，有承诺才有执行力。2、怎么知道问题得到解决？问题是软件缺陷的数量，如果缺陷数量减少，就说明这个action item有效，问题得到解决。实践中容易犯舍本逐末的毛病。例如，制定的action item是编写测试程序，于是就增加一个KPI，测试覆盖率。测试覆盖率达到100%，缺陷数量不减少，问题还是没有得到解决。所以问题得到解决才是关键。

5、结束会议

最后黛娜说：

谢谢大家的积极参与，明天早上9点的计划会议上，我们按照这些行动步骤进行。

这个例子完整的体现了5个环节：营造气氛、建立共同背景、识别见解、确定行动计划、结束会议。其中重点是识别见解和确定行动计划，希望各位根据自己团队的具体情况，因地制宜，灵活运用。

三、Sprint Retrospective与信任、容错的敏捷文化

如果希望Sprint Retrospective行之有效，如果想改进，首先需要了解情况，正视过去走过的弯路，碰过的钉子，发生过的问题。我们谈论过去，绝不是为了秋后算账，而是希望从中学到宝贵的经验教训，为了将来能够更好，为了make good team great。有句成语，吃一堑、长一智，说的正是这个道理。《敏捷教练》这本书有个生动的比喻，把从过去的经验教训中学习，比喻成开采金矿。这个比喻有意思，为什么说，过去的经验教训是金子呢？因为，和向其他的团队学习成功经验相比，团队从自己的经验教训中学习，成长的更快。

话虽如此，做到却不容易，团队需要一定的文化氛围。敏捷文化倡导信任、容错。这样的文化氛围是Sprint Retrospective的基础，它使团队成员在表达意见的时候有充分的安全感。《敏捷主教练》这本书里有个最高指示，是这样说的：

无论我们发现什么，我们理解并且真正相信，考虑到他们当时所知道的信息，他们的技能，可用的资源和手头的条件，每个人都已竭尽所能。

这句话相当于对团队说“赦你无罪”。作者建议进行Sprint Retrospective的时候，把这个最高指示贴在墙上，并为团队解释。如果讨论出现走向负面的苗头，Scrum Master需要提醒大家，多考虑当时的客观条件，而不是指责个人。

讲个故事吧。有位高管，谈到质量问题，批评团队“重视程度不够！执行力不强！哪个不好好干，我fire掉他！” 他这样说了，团队原来啥样还是啥样，质量问题丝毫不见改观。后来Scrum Master深入团队，利用Sprint Retrospective，引导团队讨论，找到原因，尝试解决方案。Scrum Master首先给团队声明最高指示，然后和团队分享质量方面的数据，请团队回顾开发的过程。有人说：“bug主要来源是集成方面的问题。” 又有人说：“使用公共服务器做集成，要排队等好几个小时。一周一个Sprint，只来得及做一次集成。第二次还没排到，Sprint就结束了。” 最后有人说：“我们自己搭一台服务器吧~” 会后，Scrum Master帮助申请了一台服务器，开发团队又花了几天把集成环境搭好。从此以后，开发团队每天都可以在自己的服务器上做集成。这样改进的效果立竿见影，集成方面的bug明显少多了。

看到了吧？在当时的客观条件下，排队使用公共服务器，开发团队已经竭尽所能了。以前被领导批评，大家都很郁闷，每天来上班，就像头上顶一块打石头，压力山大，谁也不敢说话，问题也得不到解决。敏捷文化倡导信任、容错。当团队有安全感的时候，就敢于把过去的情况说出来。大伙一起讨论，情况弄清楚了，问题自然迎刃而解。

小结 

第十一讲讨论了怎样组织Sprint Retrospective，观摩一个Sprint Retrospective的例子，还讨论了Sprint Retrospective与信任、容错的敏捷文化。为了更好的理解“信任、容错”的敏捷文化，为了Sprint Retrospective行之有效，我建议大家和我一起，再次把最高指示朗读一遍：

无论我们发现什么，我们理解并且真正相信，考虑到他们当时所知道的信息，他们的技能，可用的资源和手头的条件，每个人都已竭尽所能。