Agile Alliance 论回顾会的正确打开姿势-京东云开发者社区

我们是敏捷成熟度三级的团队，我觉得我们的团队挺优秀。但是，我们一样会遇到很多头疼的问题：测试看不懂prd，提测后不清楚应该测什么、值班问题多、系统总是“生病”等，这一度让我不禁怀疑，难道这是”敏捷“的“后遗症”？不，不，我们不会被这些问题难倒。

------------

#### 我们的现任ScrumMaster敏锐的抓住了团队面临的问题，于是我们近几次的回顾会主题如下：
- 代码质量与业务需求，谁的优先级高？
- 应用系统偶尔生病怎么办？如何使他一直健康？
- 如何让值班效率更高,更爽？

针对我们团队面临的问题和困惑，我们通过回顾会的形式，PO、SM、测试、研发激烈"混战"后，有了我们现在的**上线流程规范**、**团队敏捷公约**，以此为契约，我们对三方都提出了更高的要求。如：产品提需求一定要在行云中写清“**验收标准**”，否则研发有权拒绝开发；研发上线日定为周二、周四，并需要依次走单测用例回归通过、合并主干、自动化回归通过的标准上线流程；研发在行云提测需要有prd+功能测试点+自测记录或单元测试用例+冒烟测试截图；需求评审和代码review需要邀请测试同学参加等。

#### 下面我谈一下，我们团队回顾会是怎么做的：

敏捷教练团队出品的敏捷工具箱曾给出了回顾会的正确打开方式->《<a href="https://developer.jdcloud.com/article/1669" target="_blank">Being Agile！提升自信的路径：敏捷回顾会</a>》，在经历了尝试、调整、再尝试后，我觉得开好回顾会有几个关键要素：

##### 一个有痛点话题、一个吸引人的题目：发现问题要比解决问题更重要。
作为ScrumMaster，并非只是在让组内事务有序轮转就行了（地球少了谁都转，优秀的团队没了这样的SM，依旧会有序迭代），SM需要融入团队去感受去发现团队正在面临或即将有可能会面临的困扰和阻碍，进而发现问题提出问题。回顾会主题要提前一周或三天告知团队所有成员，可以在行云专门开设回顾复盘空间用作回顾会的通知、结果输出整理、后期实施跟进。

**tips：**一个有痛点的话题和一个吸引人的题目能激发团队成员的参与度，选对话题后，起名字也很重要，就“质量内建”这个话题为例，以下两个话题你更觉得哪个更好呢？**如何保证系统稳定、上线安全？ VS 应用系统偶尔生病怎么办？**如何使他一直健康？题目切入点不要太大、太宽泛（你付出模糊得到的一定是更模糊），如果能把题目起的生动有趣，那回顾会就会事半功倍。

##### 产研测三方对峙：一定要保证PO、SM、测试、研发同学们都到齐（退而求其次的是保证产品、研发、测试都有人在场）。
团队问题的解决或改善离不开每一个角色的同学。回顾会上**当面**发表看法、提要求，效率会更高，更容易落实。

**tips：**大家从不同角度进行问题的讨论，有利于更全面的分析问题，也保证了解决方案的合理性以及大家对于解决方案的认可度。

##### 矫枉必须过正: 
经过三方激烈对峙，不不，三方激烈讨论后，输出的解决方案或者规范一定优先保证其正确性、合理性、全面性，一定要输出会议记录或SM整理输出相应执行规范，先不过多去考虑会不会推不动这些问题。就事论事，做好每个环节。

**tips：**后期在执行相应规范的时候，由SM或team leader把控，条件不要太苛刻（大家都觉得麻烦，无法坚持），也不能松懈（和以前没什么区别，回顾会讨论完全浪费时间）。要在实践中去验证规范中的哪些点是必须严格执行的，哪些是可以简化的，从而形成组内精简又有效的“实际”执行规范。

有人提出疑问：怎么感觉越推广敏捷，反而觉得比以前更麻烦了呢？个人认为，不论要不要“敏捷”，这些东西我们该有还是会有的，比如严格的上线流程、测试分层、测试自动化，再比如产品的prd不清晰，一句话概括问题等。敏捷中的自主是建立在纪律之上的，敏捷帮我们从可视化到规范化，再向数字化进步。

最后，祝愿这个活力与问题并存的神奇团队---灰化肥发黑会挥发团队（你会读吗😊）越来越棒，敏捷成熟度四级，我们在路上。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：灰化肥团队 中台技术部 杨建民