回顾会议集锦（retrospective meeting）是scrum中最有价值嘚会议集锦之一虽然这个会议集锦很重要，但是在实际的工作中我们会发现往往最容易被砍掉的也是这个会议集锦
为什么这个会容易被砍掉呢？项目工作太多大家太忙只是一个明面的借口，深层次的原因应该有如下几个：

• 会议集锦过程和形式太枯燥重复没有新意，讓人厌倦
• 会议集锦产出的改进计划不明确不能落实，没有跟踪更没效果
• 团队缺乏持续改进的意识，只是停留在埋头处理手上的工作

如果你发现你们团队大家对回顾会议集锦不感冒也许你们就有上面这些问题，本文的目的是介绍一下我个人常用的回顾会议集锦套路仅供参考。

回顾会议集锦是Scrum检视与调整的一个重要的环节,在这个会议集锦上，我们鼓励团队对自己的开发過程进行改进并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
就像我们频繁的迭代和交付是为了快速的获嘚外部用户的反馈进而帮助我们做产品需求的调整一样，每个迭代的回顾会议集锦就是想更快的得到大家对团队工作问题和改进点的反饋帮助团队内部的工作效能和能力成长的不断改进。

回顾会议集锦的过程和我常用的手段

那我就按这几个阶段来讲讲我是怎么做的

准備阶段其实是非常重要的，一些初次主持回顾会议集锦的scrum master往往会忽视这个阶段一上来就让大家写小卡片，这样不仅效果不好更给人枯燥重复的感觉。

准备阶段我往往会选择做下面几件事：

回顾会议集锦不仅仅希望大家能参与进来更重要的是能敞开心扉，大家没有顾虑嘚把问题暴露出来找到改进的办法。但事实是肯定有人担心回顾会议集锦会成为一个批判会议集锦在认为这个会议集锦的目的是找到這个迭代中犯错的那个人，并把他拎出来痛批一顿看以后还有谁敢再犯。如果这样大家肯定会有所保留担心说错话，会议集锦上就找鈈到真正的问题
一般我们会直接声明这个会议集锦的目的，绝对没有想追究任何人的责任的意思不仅如此，我们还需要在会议集锦过程中避免讨论任何个人责任的问题

这是个很有意思的事情。会议集锦本来就令人沮丧更何状是回顾会议集锦这种非时间工作内容的、錦上添花的会议集锦。与会者都是带着什么心态来参加的呢这里有一种非常有意思的收集与会者心态的小活动，叫做“ESVP”：

这四个角色玳表了四种与会的心态可以通过与会者不记名的统计（匿名的在贴纸上写上代表自己真实心态的角色首字母）就能知道会议集锦室里大镓的实际情况。统计的结果不一定总让人欢欣鼓舞但这个小小的活动往往能有效的唤起大家内心的思考，很有价值

事实证明，一个会議集锦上如果一开始大家就可以不需要发言，只是听那么很大机会大家在整个会议集锦上都将保持沉默，有没什么想说的尽管会议集锦中后期你希望更多人参与发言。办法是一开始就破冰简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难不过没关系，这个时候大家就会开始脑子飞快的转起来了到底哪个词比较合适。这样不仅把大家带到了囙顾的思路里更重要的是大家一开始就有机会开口表达自己的想法了。

把大家带到这个迭代历史的回忆中来

在开始收集数据之前让大镓先回忆这个迭代到底发生了什么，这个至关重要不然暴露的问题很可能变成天马星空的抱怨。上面用一个词描述这个迭代的感受是一個很好的方法但除此之外还有心情曲线法也是很有意思的方式。方法很简单就是让大家画一条基于时间轴的心情曲线。如图是一个团隊真实的曲线结果每个人都不一样，分享这个曲线的过程甚至能加强团队成员的相互了解加强信任感。

如果团队有制定会议集锦的基本原则的话那我们需要在这个会议集錦上同样需要遵守，常见的比如不适用电脑不在会议集锦上打电话等等。
还有需要介绍本次会议集锦时长和大概的议程（流程）安排讓大家对会议集锦过程和时间有预期。
当然这条是应该在最开始就介绍的只是觉得没有特色，所以我放到最后才写^_

收集数据一般包含收集做的好的部分，做得不好的部分有时还会创新想法部分。这个环节是回顾会议集锦最具代表性的发贴纸，然后大家各自写一个問题一张贴纸... 如下图就是一个真实的例子：

上面这个方式用得非常广泛，就不多讲了除此之外还有一些变形的方式：

• 通过视觉化的、隐喻性的方法做引导，比如帆船回顾法
• 模拟论坛接力留言的方式通过书写来收集数据

收集到了数据只是第一步，如果顺利到此为止我们僦能收集到大量的、反应真实情况的好的和需要改进的点。接下来我们需要整理了
先分类，因为大家是各自独立写的所以肯定会有重複的，所以把同类的放到一起我们才能让满墙的纸片不那么凌乱分类需要花一点时间，但这个过程也是刚好让大家都了解其他人写了什麼的好机会所以我往往会邀请组员上来和我一起来做分类，一个人做卡片宣读允许大家讨论，一个人把相同意思的卡片贴到一起
对莋的好的部分，我们需要提出来鼓励大家希望我们能坚持下来，甚至做得更好这个部分在实际操作中往往比较忽视，大家更愿意快点調到待改进部分无论如何，如果发现团队士气低落需要鼓励的话，这时就是很好的机会每个做得好的地方你都能有感而发。
对待改進的部分这个是本次会议集锦的核心内容，不过很不幸往往团队总结出来的待改进方面会比较多（>5个就算多吧），可会议集锦时间有限对这个部分，我们首先要做的就是确定优先级最高的核心问题（不超过3个）确定的办法最常用的就是投票，比如每人两票

当我们確定了待改进的重点之后，我们就需要讨论得出针对这些问题的改进方案
不过别急，不要这么快就跳到了改进方案上来针对问题我们偠先分析问题的根源，找到问题最根本的原因我们再针对原因采取改进行动，这样才能对问题做到根本的解决

鱼骨图或5W的方法寻找问題根源

最常见的方法有鱼骨图法，如下图使用方法就不解释了，大家自己google

讨论寻找问題根源的的过程往往非常费时，这里常用的一个方式是把组员分组每个小组专门讨论一个问题，我们可以限时让他们讨论出问题的根源囷推荐出改进计划这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度

一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了这点说得容易，但做起来往往困难很大大家非常容易产出一些类似建议一样的东西，完全没办法执行这個要避免。

当然还有一个陷阱就是改进计划过多到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免不然也没法落实。

结束会议集锦如果有必要的话我们可以简单对本次会议集锦的组织做个总结建议可以帮助我們提高下次回顾会议集锦的组织能力。

但我最喜欢的结束会议集锦的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人并附仩理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法写好纸片之后，我会请大家当众宣读一下卡片内容并亲手交给洎己感谢的人，纸片格式如下：

1. 一般情况不建议团队的经理参加回顾会议集锦这有悖于准备环节中提到的设立一个安全的环境，大家会擔心在会议集锦上暴露团队问题会对他们绩效产生不好的影响但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重嘚问题但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题
2. 会议集锦产生的改进计划怎么有效的跟踪？┅般我们建议把这些action之间放到团队下个迭代的工作列表中和普通开发工作一样对待跟踪，只有这样才能有效的使得改进落地
3. 前后回顾會议集锦产出相同或类似的改进计划。这说明老问题一直没有解决有的时候会发现每次改进计划都完成了，但是老问题仍然还在一般洳果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影面对这样的问题，团队最好能计劃一些长期的（周期跨迭代的）改进计划下次回顾会议集锦可以监控进展，而不是提重复的问题
4. 如果需要，别忘了在回顾会议集锦前媔简单过一下上次回顾会议集锦产出的改进计划完成情况

原标题：敏捷回顾会议集锦怎么開华为PM这么说

开篇小故事：前几年，因为前某国家领导人“摆案头读百遍”，一本叫《沉思录》的书在国内突然曝光度大增《沉思錄》是古罗马皇帝马可·奥勒写给自己的书，内容大部分是在鞍马劳顿中写的。其中有一句“ 我们所听到的不过只是一个观点，而非事实峩们所看到的不过只是一个视角，而非真相”

全员都参加的回顾会议集锦，其实就是希望能通过全员视角全员的观点来回顾做的好的，做的不好的改进之。从敏捷宣言到敏捷的诸多实践（如Scrum），再到DevOps都一直提倡回顾这种形式。

其实回顾这种形式并不是敏捷/DevOps专属嘚，在华为最早的CMM流程中也有类似的活动。有时候团队碰到郁闷、痛苦的时候还会主动自发的开回顾会议集锦。

所以我一直认为“囙顾”是人类作为一个智慧物种相比其他生物的一个重要区别。我有的时候会通过回顾会议集锦来判断这个团队会不会成功最极端的，洳果一个团队都没有人想着要约大家一起回顾这个团队极大概率要凉了。

华为内部除了研发交付团队连一线的市场团队也包含在内，茬重大的市场项目、交付项目的过程中都会定期进行回顾会议集锦这算是华为内部这么多年积累的一个很好的实践。

必须鲜明表达的观點——回顾有三个不是

“顾”和“溯”一字之差在中文的语境中，却会导致变成刨根问底

2.不是“批评与自我批评”

“批评与自我批评”是一个很好的形式，但是会导致团队陷入一种不必要的紧张和犯错感

3.不是“问责和处罚”

软件的不确定性、不可见性、复杂性和易变性决定了软件开发过程总会有些磕磕绊绊，我们提倡的是改进不是惩罚。从华为这么多年的实践来看上面的三种情况都出现过，所以提醒大家要小心

这么些年实践过来，我们发现出现以上情况也是因为步子走得太快，低头玩手机忘了“回顾”的初心：

举个例子，峩们可以说“代码评审不充分所以代码缺陷较高”，不能说“某帅哥评审不认真”当然夸人帅还是可以的哈。

2.聚焦于下次能否做得更恏

还举同样的例子我们可以说“这个迭代代码评审不充分，下个迭代我们怎么才能保证更充分的评审”

3.从系统角度思考改进，而非个囚

我们可以说“团队的工作安排上导向上是不是不重视代码评审？”

1. 确定参与人（Who）

a)团队所有成员都参加。

b)领导是否参加视情况确萣，如果领导参加利大于弊就邀请，否则就算了

c)如果是重大的项目发布或项目结束的回顾会议集锦，还应该叫上所有对项目有付出的荿员

d)建议指定一个会议集锦引导人，可以是敏捷教练也可以是团队成员轮流来做（团队成员建议熟读本文）。

2.选择合适的场所（Where）

a)如果条件允许离办公位尽可能远一点，避免有同学中途又回去处理工作了

b)尽可能不要使用传统会议集锦室的布局，围坐一个大桌子那种鈈好可以拉几把椅子围成一个半圆形。

c)需要有白板或者墙壁可以贴个大白纸。

3.准备回顾的内容（What）

a) 准备上个迭代的客观数据特性、需求、缺陷等数据，如果使用了像DevCloud这样的敏捷管理工具准备数据其实很快的，甚至不用特别准备现场打开就可以，类似如下这样

b) 团队荿员上个迭代的感受可以认为是主观数据的收集。

c) 每日站立会议集锦的要点每日站立会议集锦中都会提出并跟踪解决一些问题，回顾這些问题也可以帮助我们审视过程中的情况

d) 准备一个规则，会议集锦开始前贴出来或打印出来或投影仪投出来规则是为了保证会议集錦的纪律和效率，比如不能随便打断别人讲话每人发言时长，会议集锦时长（建议10~12人的团队限定在1小时内)。

4. 回顾会议集锦的过程（How）

a) 准备和引导——明确目标重申回顾会议集锦的目标和原则，让成员重拾回顾的“初心”发布公示的回顾宣言，重申会议集锦纪律时長。准备和引导环节是让大家放下手机进入回顾会议集锦状态的必要环节，无论开过多少次都不应该省掉。

b) 数据、过程的回放——建竝共同的全景展示本迭代的度量数据，如果有使用类似DevCloud的敏捷管理工具可以直接打开系统。全景的数据展示回顾让视角更全面。对於一些“历经劫难”的迭代可以画一个时间线，把这个迭代发生的重大的一些事件按照时间顺序展示出来帮助团队成员回顾都发生了什么。

c) 提出见解——我们如何才能做得更好可以通过头脑风暴，全员参与有很多种分类的方法，如下图中是分为Good（下个迭代哪些好的方法可以继续保持）Could Bette”（下个迭代可以哪些地方可以做得更好），Improvements（新的改进的具体想法）可以采用“有限投票”的方式，每个成员囿5票（比如小磁贴或直接记正字）大家共同选出团队层面需要重点改进的。其实投票未排进Top的改进如果不需要组织和团队来推动，个囚也可以实施的改进也应该支持。

d) 确定措施——想清楚就干才有诚信。识别了重点的改进项为每一个改进项指定计划，执行的措施需要更高层面去解决的措施需要单独列出来，项目Leader会后要发挥“死缠烂打”的精神去骚扰领导了同时每个改进措施都应该明确一个责任人，如果没有明确的责任人大家都会认为是别人的事情。

e) 结束会议集锦——果断结束绝不拖泥带水。将会议集锦中达成共识的措施囷计划整理记录下来如果使用了敏捷管理的工具系统，可以直接输入到系统中记录为Story或者任务。

来自实践中的一些坑和雷

几天打鱼几忝晒网的可不行

团队级的回顾会议集锦应基于现实，而非理想或者说理想可以有，诗和远方也可以有但是回顾会议集锦还是应接地氣。

程序员有的时候特别认真容易把问题引入到技术细节，这样会导致议题发散

4.只开会，没有吃的好饿

皮一下，为了调节会议集锦氛围可以准备些吃的，补充能量大脑才能激发。

最后每个迭代回顾会议集锦，都不要忘了感谢自己也不要忘了感谢为了心中教堂洏努力的所有团队成员。

作者： 刘恒 华为云DevCloud项目管理服务产品经理

开好回顾会议集锦并不简单是否曾遇到这些问题：

回顾会怎么开，才能创建出群策群力的氛围
计划1小时的回顾会议集锦经常2个小时才能完成？
如何破解有人滔滔不绝有人沉默不语，甚至有的人就是不想来
如何引导团队做出高效决策，而不是乱成一团、无法收敛
领导要参加回顾会议集锦，该如何咹排
会议集锦确定改进为啥总完不成？
同样的错误为啥一犯再犯？

在上一篇中我们讲了回顾会议集锦的理论基础、核心目的、好处忣最高指导原则，重点讨论了回顾会议集锦的参与者及会议集锦流程。在这篇文章中将讨论开好回顾会议集锦的“十大坑”和“七个關键点”。

一、不做回顾或参加的人很少

有的人可能认为自己的工作就是特定工作，其他事情都不值得投入时间（例如他们认为除了編码和测试，其他时间都是浪费时间）；有的人认为现在项目工期特别紧做回顾不如多完成几个故事点。

实际上这些都是重视度不足嘚表现，回顾会议集锦作用是持续改进通过定期停下来反省，才会让团队找到更好的优化点从而提升效率。

每周至少要做一次回顾洳果太忙，那就两次

另外，希望团队每个人都能参加会议集锦回顾会议集锦本身是个学习机会，另外大家角度不同，贡献也不同恏的回顾会议集锦，还会创建一个更好的团队氛围

原因2：出现很多沉默的队员

会议集锦中，要关注沉默的队员如果出现此种情况，可鉯试试用书写方式或轮流发言（但一定要声明可以跳过，给人足够安全感）回顾会议集锦形式可以适当变化，目的是保持大家对会议集锦的热情千篇一律的会议集锦会给人呆板感觉。

此外会议集锦中ScrumMaster和ProductOwner发言可以放在最后，以免对团队有过多干扰

原因3：人们被分配箌多个项目中

该问题是个组织管理问题，需要由高级管理者处理

原因4：远程参与者不方便加入

可以考虑调整时间，找个大家都适合的时間进行可以借助在线会议集锦工具、视频工具等，让大家可视化都参与进来。

事实上后面很多“坑”，也会影响该问题解决所以努力让每一次回顾会议集锦都开的有意义，可执行

二、不着边际，空洞无物

原因1：没有重点内容不着边际

讨论没有重点，天马行空戓者不着边际，更像讨论新奇玩法而不是在改进。

建议：会前做好准备特别是准备好回顾重点。会议集锦过程中做好时间分配，什麼时间回顾什么时间收集改进建议，什么时间落实行动及落实到人讨论的内容，默认当前冲刺的事情

回顾会议集锦讨论的是冲刺过程，而不是整体过程如果有必要可以考虑几个冲刺后，设置个整体回顾讨论过程中，对于不在控制范围内的内容不建议过多讨论。（有些问题超出团队影响范围ScrumMaster可以帮助清除障碍）

原因3：得出的是“伪行动”

会议集锦最后要落实行动，但行动如果是改善沟通多做偅构、提高技术水平等，实际上是无法落实的具体行动内容，可以参考SMART原则

三、对重大问题视而不见

借用 Lisa Guan 的话，该问题要么懒要么鈈敢动。

原因1： “懒”的问题

可能是能力不足这个就需要提升能力（可以参加培训，新老结合网上学习等等）。

可能是价值观问题需要找到真正的内驱动力（比如玩一下5W，做一下愿景展望澄清一下团队工作的真正价值等）。

谁影响了安全的表达环境 

团队里有没有┅些不安全的因素，比如上文提到的强势组长导致大家走形式，不愿去触及真正的问题

团队内部是否存在某些隐形的对立？

最近发生過什么事情影响信任，开放勇气？

建议：有时候需要对团队坦白大家共同面对问题；有时候是个别人情况，需要教练一对一的沟通解决总之，如果对重大问题视而不见将会严重影响团队的参与和改进，ScrumMaster 可将其当做团队障碍寻求其他敏捷教练帮助，或找项目外相關人员解决

不能贯彻执行的原因很多，这里挑几个主要原因说明这一环节中，ScrumMaster要帮团队持续改进如果不能落实，要和团队一起找根源扫除障碍。

原因1： 没有总结和跟进

有些回顾会议集锦最后提出很多改进点然后就结束了。实际上缺少进一步的跟进。比如落实到具体的人（甚至设置一名监督人员）下次回顾会议集锦时，先针对上次改进点讨论等

原因2： 没有获得足够的支持

常见问题是团队没有達成共识，比较PO更关注交付时间团队打算提升质量；选择了团队不想解决的问题，虽然是的大家选的但仍不愿意具体落实。

建议：要保证团队目标统一在此基础上达成共识；行动具有可执行性，可以大行动分解为小行动逐渐取得进展，增强团队信心

如果一件事每個人都负责，结果就是没有人负责这就是『旁观者效应』。

当团队确定行动计划后一定要落实到人；如果每个人都有责任，可以考虑引入监督者在下次回顾会议集锦时，可以汇报执行情况

原因4：改进措施没有固化

有时出现某项改进措辞，执行了一两个冲刺后问题叒反复了。比如代码走查执行一两次后不再执行了。

建议：有些改进行动如同习惯养成需要大家认同并共同遵守；可以设置目标、适當奖励（不一定是物质哦）等，让大家拥有进展感；ScrumMaster或具体负责人需要多次强调（如在早会时提醒）；隔几个冲刺后，可就这个行动做┅次整体回顾

原因5：无效的独立改进流程

有时为了操作方便，或者更加“重视”团队希望把改进流程独立出来。但事实上这种做法是無效的团队会专注于每个Sprint，如果还有额外的改进流程显然也违反敏捷原则。

建议：把改进放入Sprint中甚至可以与PO协商，给改进留出适当嘚时间进行对于较大的改进计划，可以进行拆分放入每个Sprint中。

又称野心勃勃主要原因在于“贪”字：贪多、贪大、贪快。

贪多：一丅子想解决所有问题；
贪大：目标太大无法一下完成；
贪快：忽略改变的过程，想一下达成目标但无论是能力、环境和心里接受程度嘟不成熟。

建议：减少改进计划从小目标开始。比如可以一次设置一两个目标，并且有明确的完成定义达到了再进行下一步改进。

陸、没啥可回顾的发现不了问题

可以关注工作之外，比如团队氛围方面的改进
跟大家一起做一些小的创意目标，为固定的环境添加一些"变数"说不定会带来惊喜。
制定一个小的学习目标要共同完成的那种。回顾会议集锦就可以从多个视角分享心得并且共同制定改进計划了。

如安全性不足；会议集锦流于形式总是一个套路；会议集锦结果无法落实等等；

常见问题是没有准备；只留5分钟做个回顾。解決方法参考大坑一，不做回顾或参加人很少

七、变成指责游戏、吐槽大会

团队整体是相互指责，每个人都做职责内的工作工作失误叻，首先想到的是责任是谁的问题。如此团队整体都是担心失败，不敢担责

建议：该问题属于管理范畴，敏捷团队应该在一定空间內容忍大家犯错会议集锦上，如果出现该问题引导师要积极制止，重申会议集锦原则建立共同背景。面对抱怨和有情绪的参与者請求以帮助改进的形式表达想法，而不是指责

原因2：被一两个人主导整个会议集锦

总有一些特别强势，又善于说的人可能会主导整个會议集锦。

建议：遇到该情况引导者尽量注意避免比如恰当时候中断其谈话，让其他人讲讲或者通过写卡片方式，每个人轮流发言等

原因1：任务失败、或项目延期

出现该情况时，更应该回顾通过总结，找到改进方向用动力做好下一次冲刺。即便任务失败或项目延期大家也是在一起努力了，可以互相鼓励并互相感谢（比如加个感谢环节），良好的团队氛围有利于快速调整状态。

引导者恰当嘚把大家从失败中引导出来，把注意力集中在积极的改进措施上

另外，如果团队恰巧处于企业调整期可能出现人心惶惶情况，或许此時要先解决外界干扰问题

原因2：会议集锦沉闷，没有生气

多花点时间活跃氛围比如增加些开场游戏，更好的让大家全心投入进来会議集锦议程适当变化一下，甚至引导者可以让团队成员担任

计划1小时的会议集锦，开了3小时讨论起来就没有头，会议集锦更像大家的總结会

建议：提前通知大家做好准备；设计会议集锦流程，通常先发散后收敛目标是寻找到改进点，并落实到行动；注意会议集锦中發言的人及其内容既要让大家尽量都参与，又要适当控制发言时间发言内容也要紧扣主题，防止天马行空；有些改进需要进一步讨论嘚可以考虑设立一个讨论区，先用便签把问题贴出来以后再找时间讨论。

准备应是引导者可以做好的但很多新手会因为收集数据不准，重点把握不当造成会议集锦效果不佳。

建议：引导者需要平时有收集数据收集流程改进点或案例的习惯。多观察与团队交流，總结找到改进点，并让团队看见

原因2：帮助团队做决定

可以通过引导，让大家发现问题但不能帮助团队做决定；同时要注意团队中┅些强势的人，防止个别人代替团队决定（改进内容应该来自团队）；更不能将话题引导到自己喜欢的话题；有些争执时，要保持中立不可以偏袒某一方。

过度关注整个团队不能掌控的那些障碍及关注超出范围。可参见“二、不着边际空洞无物中讨论整体过程”处悝方法。

开好回顾会议集锦不可忽视的七个关键

好的会议集锦都是有准备的Sprint之前，确定项目整体流程落实各类活动及事件安排。回顾會议集锦时针对整个Sprint进行回顾，言之有物并为下个Sprint做好准备。

会议集锦前告知团队提前做些思考，总结些改进点重要的是确定大镓能够重视，准时参加

准备好会议集锦需要的各类工具和材料、落实参与人员与召开时间等。

关键二明确会议集锦总体原则、目的、關注点

回顾会议集锦总体沟通原则：无论我们揭示了什么，我们必须理解并真正相信：考虑到当时的已知情况、每个人的技能和能力、可鼡资源和情境每个人都做到了最好。

回顾会议集锦相信每个人当时都做了最好的选择不为此而责备任何人。发现问题不是为了找责任而是为了改进。所以需要统一团队对回顾会议集锦的认识新团队有必要对回顾会议集锦的背景、目标、形式、规则等知识进行宣导。

鈈同项目情况回顾关注点不同：

● 一次性的项目（项目结束后团队解散）：从做的好的和不好的点，总结相关的经验关注每个人的成長和收获，大家在其他项目中可以做的更好
● 新成立的项目，大家摩拳擦掌准备大干一场的：关注项目成员的配合协作、项目流程完善、统一的规范（可以包括统一的编程规范、沟通方式等）关注改进点；
● 项目问题比较多，士气不高的团队：关注团队的进度、发现优點激励士气为主，同时不断从最核心的两三条改进开始；
● 成熟团队经历了长期合作的：团队资产的不断积累、精益求精：包括团队嘚技术积累（模块的架构提升、代码亮点、经验库建设等），和业界标杆、周边优秀团队的差异对比等

对于新团队，会前可以共建团队約定注意不要替团队写好。可以适当举些以前的约定激发大家思考与参与、认同，但不能擅自加入更不能强迫团队接受。

耐心听取怹人发言不随意打断他人笔记本、手机放一边积极分享个人观点尊重不同观点尊重每个人讨论对事不对人，不互相指责产品是大家的多說I少说you不许迟到把需要详细讨论的话题，放入停车场
会议集锦上讨论内容只能保留在房间里重述听到的内容，确保正确理解........

除了约定外更多要考虑建立一种平等的文化氛围。如不责备对给些正向反馈；开诚布公，做不到的可以自我批评建立与团队成员间信任等等。

会前的游戏热身或购买些小吃的东西，也会让大家更放得开

关键四，多鼓励大家发言

回顾会议集锦需要畅所欲言理想情况可以听見每个人声音。所以建立自己的引导工具箱让大家可以从多角度、多方面回顾。比如时间线索、测试或产品功能模块角度，从开发过程出发、从引入新技术、新工具出发等等做的好的发扬，不佳的改进

通过引导，保证会议集锦顺畅每个人有机会发言（非强迫）；鈳适当建立些规则：如每个人要写2张以上卡片、大声读出大家想法等。

关键五让团队自己做主

改进点是大家提出来的，通过投票方式选絀1～2个具体落实关注会议集锦上是否有强势人员或跑题者，需要及时纠正；关注引导者是否保持中立；关注团队每个人是否认同

最后，明确执行人员甚至可能需要有监督人员。

关键六把握节奏，感受氛围留意会议集锦“异味”

注意时间节奏，设计好会议集锦议程在限定时间内，确定下个冲刺改进点并能落实到人。会议集锦中感受氛围大家是否积极思考、参与讨论；是否出现良性争执（争执絀发点是为了改进）。

会议集锦本身结束并不代表结束要做好进一步总结：

留意回顾活动取得的成效，和阻碍改进措施落实问题；会议集锦的最后也可以留几分钟针对回顾会议集锦总结，让会议集锦本身持续改进；设立中期改进目标并定期复盘，增强团队成就感；如果上次回顾会议集锦行动未完成要先找出原因，再考虑增加新行动；发生的事情只留在回顾会议集锦里。对于照片和会议集锦纪要鈳能会因为大家没有具体上下文产生误解。

本文针对回顾会议集锦常见问题进行收集、总结和整理并对问题给些解决方法。针对高效回顧会议集锦总结了七个关键点

由于本人能力有限，难免会有不足和纰漏有任何问题，欢迎大家批评指正

《项目回顾：团队审核手册》Norman Kerth

《回顾会 | 百度敏捷教练》郭驰 Jennifer

《干货：敏捷回顾会议集锦实践分享》庄荣墩

《如何让回顾会议集锦更有效果》公众号：软件工程之思

《囙顾会的持续改进》魏来

还有部分内容来自网络搜索