Being Agile！提升自信的路径：敏捷回顾会-京东云开发者社区

#### 一、为什么要开回顾会
“学而不思则罔，思而不学则殆”；回顾会的设计是一个集体思考，并付之于集体行动的活动。
我们是软件交付的急行军，回顾会就像一个暂停键，让团队停下来，在一个安全的环境下，对团队、对交付过程、对自己进行反思，从而发现：
- 障碍与问题
- 经验与机会

团队通过对这些洞见的分析，确定改进措施，并贯彻执行，让团队得到成长。
#### 二、回顾会基于的原则
我们希望在回顾上，大家能开诚布公并相互支持，所以团队需要理解并认可以下原则：
- 我们相信每个人在过去的迭代中都尽了最大的努力。
- 我们理解并相信每个人都是自己问题的专家。
- 回顾要基于事实与数据，而非个人主观判断。
- 没人在团队之外，团队的进步离不开每一个人。

#### 三、回顾会的基本要素
![](//img1.jcloudcs.com/developer.jdcloud.com/d764a2ac-2d2d-4f87-a231-b28b4520c04520210118163108.png)

#### 四、回顾会流程
##### 4.1 会前准备
**Step 1.定义回顾重点**
回顾会默认的重点是从各方面回顾交付的过程，同时，Scrum Master可以定义一个聚焦的主题，帮助团队在接下来的时间里重点改进：
- **从产品所处的发展阶段：**如：“我们如何能构建出客户真正想要的产品？”
- **从团队建设的不同阶段：**如：”初建团队，如何促进团队成员之间相互了解，加强信任“；
- **从团队遇到的具体问题：**如：”本次的迭代回顾会议将讨论并解决我们在迭代质量中存在的问题，帮助我们在后续的迭代中提升迭代质量“。

**Step 2.量化迭代（Scrum Master需要收集客观数据）（添加敏捷成熟度的指标）**
量化迭代的目的是要收集这次迭代内的数据，让大家可以直观的感受到基于事实的现状，达成共识。
**迭代数据主要包括：**
**1.交付效率**
- 完成进展，迭代结束时需求、卡任务完成情况：
① 迭代完成率 （已完成的卡任务/总的卡任务*100%）
② 当前迭代卡片状态（非跨迭代需求是否在已完成泳道）
③ 团队空间本次迭代总卡片数
④ 团队空间本次迭代需求类型卡片占比

- 交付速率数据：
① 需求交付吞吐率
② 需求研发交付周期
③ 需求交付周期
④ 上述数据主要观察数据趋势，是否有剧烈的变化。
![](//img1.jcloudcs.com/developer.jdcloud.com/25193740-9ce8-40d7-9e20-8a721fcdb70420210118163542.png)

**2.交付质量**
分析本迭代的质量数据，观察交付过程质量与结果是否稳定，是否有异常或需要重点分析的缺陷。
- 自测直接上线需求数
- 自测直接上线需求占比
- 单测覆盖需求数
- 单元测试用例数
- 冒烟通过率
- 缺陷个数
- 提测的需求个数

![](//img1.jcloudcs.com/developer.jdcloud.com/47c82f99-f2f4-4069-9668-9e7b68a5c6cd20210118163649.png)

**Step 3.安排日程**
回顾会建议采用线下的形式最佳，远程团队或疫情期间，考虑线上形式。

**1.线上回顾会：**
- SM需要确认团队空间内，会前内容准备完毕（会前Step 1和2）
- SM提前发送会议邀请，写明会议主题，确认线上会议进入方式
- 团队成员需要确保所处环境不要太嘈杂，保持会议秩序不被外界干扰

**2.线下回顾会：**
- SM需要确认团队空间内，会前内容准备完毕（会前Step 1和2）
- SM提前预定会议室，发送会议邀请，写明会议主题
- 团队成员需要准时参加会议，如有时间冲突，需要提前向SM请假

**Step 4.创建内容（团队每个人分别提出想法，创建卡片）**
团队需要围绕这次会议重点，每个人提出自己的想法，想法分为几个部分：
- 哪些是个人\团队做的好的部分，应该继续发扬
- 哪些是个人\团队需要改进或提升的
- 应该怎么做？
- 创新想法
每个人在Good、Need或创新泳道创建卡片，一条内容创建一个卡片，个人根据团队设置好的标签打到卡片上进行分类。
这里推荐从个人和团队两个视角分析，个人与团队获得共同的进步。
**标签建议:**
- 沟通类
- 计划类（包括估算、时间对齐等问题）
- 规范机制类
- 能力补齐类
- 跨团队协作类

![](//img1.jcloudcs.com/developer.jdcloud.com/701d1689-3ee0-4059-b1ca-35e5b7a2746720210118163910.png)

##### 4.2 会中步骤
**Step 1：营造氛围（破冰游戏）（10-20min）**
对于不太熟练的团队，需要Scrum Master先跟大家说明会议的流程及回顾会的原则（详见本文第二节）。
接下来，Scrum Master需要根据团队情况来判断是否需要破冰，选用什么方式来破冰，这些破冰游戏可以形成团队自有的仪式。

**1.一词总结**
- 操作说明：大家按顺序轮流用一个词形容自己对这个迭代的感受。
- 只让用一个词可能有点难，这个时候大家会开思考到底哪个词较合适描述感觉，Scrum  Master不用过于关心发言者为什么选择那个词，重点引导大家能开口表达就好。

**2.心情曲线**
- 操作说明：Scrum Master首先按迭代周期，画一个坐标系，横轴为时间轴，纵轴为心情愉悦程度。大家每人画一条基于时间轴的心情曲线，阐述自己的心情曲线原因。分享这个曲线的过程能增强团队成员的相互了解，加强信任感。

![](//img1.jcloudcs.com/developer.jdcloud.com/e64f089b-f684-4e70-b371-509da446bcb120210118164011.png)

**3.感谢有你（彩虹屁）**
- 操作说明：团队每个人会前提准备，将想感谢的人在空间内创建卡片，卡片内写明原因，在卡片上打上被感谢人的标签（或创建个人任务）。会上轮流表述这次迭代最想感谢的人，说明原因。增强团队凝聚力。

**4.360°赞赏**
- 操作说明：每个人写下他对其他参与者的赞赏，让所有人围坐一圈，让其中一个参与者坐到圆的中心位置，围成圈的每个人说出对坐在中心位置的参与者的赞赏反馈。依次轮换中心位置的参与者，直到每个人都收到反馈。提升团队士气、增进人际关系。

**5.心情象限**
- 操作说明：在白板上画个大十字，每个人用便签记下所有让他感到”抓狂，沮丧，开心“的事情，对应贴到不同的象限。此外团队成员可以在右下角的鲜花象限贴上对一名或者多名成员的”感谢“。
![](//img1.jcloudcs.com/developer.jdcloud.com/c5054c4e-9dba-4ed6-af90-bdc4513c7efe20210118164138.png)

**Step 2：陈述主题及数据(5min)**
- Scrum Master跟大家再次同步本次回顾会的重点。
- Scrum Master总结迭代过程。就迭代完成情况，进度情况，质量数据等进行团队内说明。

**Step 3：团队分享观点(30-40min)**
**1.陈述观点：**
- 首先陈述Good泳道中的卡片，每人一次陈述一个不同观点的卡片，轮流进行
- 陈述的过程中，如其他人有相同的观点，可以在当前人说完后说明，相同内容的卡片就不用再复述
- 所有Good卡片完成。然后陈述Need泳道中的卡片，依然是每人一次陈述一个卡片，团队进行讨论直到完成所有

**2.分类调整：**
在分享过程中，对于分类定义不准确的卡片进行分类调整。

**3.决策筛选：**
当所有卡片都分享并讨论后，团队决策选出所有卡片里面最需要改进或落实的2-3项（可根据团队情况调整数量）进行下一步讨论工作。

**决策工具箱：**
- 选择矩阵：通过两个维度: 难易程度、价值，来定义待落实工作优先级。
![](//img1.jcloudcs.com/developer.jdcloud.com/f49bc691-41b7-408c-83d9-f1fc5324db8420210118164333.png)
- 投票表决：各自写下所选择的落实项，进行唱票即可。
- 圆点投票：线下回顾会上，团队将所有卡片张贴在一面墙或白板上，成员通过圆点贴到自己认为最需要跟进的便签上，进行投票决策，选择圆点最多的便签进行下一步原因分析环节。
![](//img1.jcloudcs.com/developer.jdcloud.com/661ca381-9fdc-4b07-ab0b-919c24162c0520210118164414.png)

**Step 4：得出见解，最佳办法(30-40min)**
**问题原因分析：**
如团队选出了一些问题，则需要进行根因分析后，才能找到更好的解决方案。
**工具箱：**
**1.鱼骨图：**看上去有些像鱼骨，问题或后果标在"鱼头"外。在鱼骨上长出鱼刺，主干鱼刺是一些大的原因类型（如人员、资源、依赖、机制、方法、环境等），上面按出现机会多寡列出产生问题的可能原因。
- 原因型鱼骨图（鱼头在右）
![](//img1.jcloudcs.com/developer.jdcloud.com/d546c11c-dc16-4f19-b69c-f705f7d8054220210118164535.png)

- **5 Why分析：**对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止，有时可能只要3次，有时也许要10次，直至找出原有问题的根本原因。
![](//img1.jcloudcs.com/developer.jdcloud.com/ce642d15-9248-4cef-9fb4-a03a5082972320210118164634.png)

- 因果回路图：（CLD）描述了系统中不同变量之间的因果关联及相互影响的方式。它由标识不同变量的若干点组成。不同变量之间的关系由标示正向影响或负向影响的箭头来表示。途中的变量名称总是名词，并且最好是可量化的。
![](//img1.jcloudcs.com/developer.jdcloud.com/382bb131-6349-4829-9a10-76af572d679620210118164733.png)

**制定改进方法与计划**
找到根本原因后通过头脑风暴的方法，列出改进办法并讨论。
在寻找解决方法的时候，可以用“如果……，你还没有做的是什么？”；这样的假设句式，可以帮助我们突破偏见和固有限制。比如“如果给出单元测试的时间，你还能做什么可以提高单元测试的质量？”
- 标杆做法：在组织内外寻找可以当作标杆学习的对象。用卡片尽可能广泛列举实例做法，找到适合团队的方法。
- 对策型鱼骨图：（鱼头在左，特性值通常以“如何提高/改善……”来写）

**Step 5：落实行动(10min)**
使用行云看板，在对应的卡片内创建卡任务，确定“谁”（Who）"什么时候"（When）"完成什么"（What），落实到具体行动。最后再确认希望做到什么程度。
- 卡片名称：待改进的问题描述
- 卡片内容：问题原因和改进计划
- 验收标准：希望改进能够做到的程度
- 个人任务：落实行动的改进内容（What）
- 处理人：跟进落实行动的负责人（Who）
****起止日期：落实行动的具体时间（When）
例子：
![](//img1.jcloudcs.com/developer.jdcloud.com/3e2be36c-5f6c-4ca0-8eae-c9718b5f0fe220210118164951.png)

##### 4.3 会后行动
- 在下一次迭代中，持续跟进回本次顾会确认需要改进的行动。行动的负责人要在站会上同步工作进展。
- 在下一次回顾会上，对落实行动的工作进行检查，确认完成情况。以帮助团队做到持续改进。

##### 4.4 回顾会使用行云管理Demo
- 迭代名称建议：对应团队空间当前迭代的名称/日期
![](//img1.jcloudcs.com/developer.jdcloud.com/952eb60b-9722-4013-9821-35365a8e7d6620210118165055.png)
- 泳道设计：Good、Need、创新、感谢的人、落实行动、完成
![](//img1.jcloudcs.com/developer.jdcloud.com/39c431e3-30b3-44c8-ac1b-6678f4144a6720210118165120.png)
- 标签建议:
沟通类
计划类（包括估算、时间对齐等问题）
规范机制类
能力补齐类
跨团队协作类
![](//img1.jcloudcs.com/developer.jdcloud.com/2e507ac5-a2a8-4d29-8a9b-1dd66ec6512a20210118165146.png)

#### 五、常见问题处理技巧
##### 障碍一：许多讨论没有结果
很多没完没了的会议没有清晰的结论。整个会议就是不断的讨论，直到超时。结果虽然可能有一些有价值的讨论，但是没有创造任何有形的结果，所以它对任何人都没有帮助。以下是回顾会没有结果的原因，需要我们去避免
- 冲突的观点
处理技巧：如果出现了两个完全矛盾的立场，导致团队无法达成一致，则需要中断讨论。首先重申两个立场，然后从矛盾的立场中寻找任何可能存在的共性。尽管是矛盾的立场，但仍然会有很多共性的东西。团队可以基于这个共性来选择他们的下一步。

- 缺乏清晰的时间表
处理技巧：需要判断出讨论环节是再推动会议顺利进行，还是陷入了无休止的循环。如果是顺利进行，讨论可以继续。如果陷入了循环，则需要Scrum Master保证让团队持续知道在每个阶段还剩多长时间，那么遵守预定时间表就不会有压力。这样会促使与会者停止无休止的讨论并回归正题。

##### 障碍二：太多结果
团队在最开始举行回顾会时通常会给自己安排太多的待改进项。在回顾会结束时会发现有数十条建议需要在接下来的迭代内解决，这会让选择成为困难。做出的改变越多、越大，来自系统内部的阻力也将越大。要实现所有这些变化将异常艰难。同时团队也无法花费非常多的时间去改变所有待改进项。
- 处理技巧：团队尽可能减少待改进项的个数，每次迭代只选择最重要的2-3项进行改进。建立以结果为导向的改进过程。

##### 障碍三：对进一步改进不感兴趣
虽然回顾会确认了待改进项，但团队可能明显没有兴趣做进一步改进，可能是由下面三种原因之一造成的。
- 改进从未被执行
大多数情况下，改进从未被执行的原因是它们迷失在日常工作中。
处理技巧：上一次回顾会中产生的任务是这一次回顾会的一个组成部分。在旧的改进项还没有实现的情况下，制定新的改进项没有任何意义。可以将改进任务放置于迭代任务内，进行跟踪落地

- 改进没有效果
处理技巧：为改进项制定一个验收标准，在下一次回顾中，检查上一次的改进项是否达到了预期效果，如果没有，可以在当前回顾会重新定义改进方法，持续跟进，直到满足验收标准。

- 没有给团队足够的时间
团队成员因为需要处理日常工作中的任务，而没有对改进项做出真正的行动。
处理技巧：需要将行动落实到个人，并确定预计完成时间，将改进项作为一项任务规划到迭代内。即使小的改进也有助于持续的改进过程。

##### 障碍四：关注负面因素
许多团队会犯这样的错误：忽视积极因素的收集，在回顾中只关注负面因素。这常常会导致我们把注意力集中在错误和失败上面。团队容易陷入到一个消极的氛围。

处理技巧：Scrum Master要确保积极的状态在回顾会中不被丢失，为团队注入正能量，才能促进产生更好的结果。

##### 障碍五：未专注于事实的议题
不基于事实的议题没有实际价值，容易让成员就”虚幻无形“的问题进行发散，并总结出不切实际的解决办法。也容易引发冲突。
处理技巧：每个议题基于事实，围绕事实进行讨论，可以促进团队透明并加强信赖。只有在团队成员开放并相互合作时才有可能进一步发展。

##### 障碍六：不想说，不敢说
- 冷场
很多团队会遇到回顾会冷场的情况，全员沉默场面尴尬，最后有的同学勉强说出几点已经重复过多次的内容。大家毫无兴致。可能的原因是会议形式单调，缺乏活力，没有明确的主题。
处理技巧：在会前确定会议主题。参照上文中的小游戏，设计一些不同的暖场游戏，带动成员的情绪，营造一个温馨的会议气氛，为会议的进行创造良好的条件。

- 不敢表达
团队有时会遇到一些显而易见的问题，但是大家似乎不愿意说真话，有些问题明明就在那里，大家还是假装忽略。可能的原因是团队缺乏信任，害怕造成冲突。
如果大家不能开诚布公，敢于暴露存在的问题，反思团队（包括自己和其他人）在过去存在的一些问题或者待改进的地方，团队就无法真正得到提高，也就失去了召开回顾会议的意义。
处理技巧：为了在会议中创造安全和信任的环境。Scrum Master需要和大家一起把保证安全和信任作为会议原则在全组加以讨论和认可。Scrum master最好主动示范如何保证良好的会议环境。比如和大家拉拉家常。主动，坦诚地告诉他们自己的真实情况，有时是失败的经历，以此显示自己和大家没什么两样，甚至吐槽一下，发发牢骚都是可以的。另外在别人说话的时候，始终保持专注，欣赏，鼓励。建立信任是逐步的过程。

- 鼓励有建设性的冲突和讨论
不要害怕不同意见，不要担心自己的权威被挑战，不同意见是创新的来源。
建设性争论的前提是互相信任。否则争论很容易变成互相攻击。我们还要注意提出问题，意见的技巧，不要让争论变成互相指责和攻击。首先要掌握对事不对人的原则。我们要尽量从客观的角度描述事实，而不是轻易加入自己的判断。讨论问题的时候，不要针对某一个人。第二，明确争论的目的。要让所有人明白，争论不是为了责备某个人，也不是为了吵架，而是为了从组织的角度看看如何改进流程，提升工作效率。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者： 勇敢者俱乐部

------------
更多敏捷相关，推荐可与下方优秀作者聊一聊
![](//img1.jcloudcs.com/developer.jdcloud.com/49008aa0-9cd5-41d3-95a7-05df7aa159a220210118165557.png)