迭代回顾会议都总结什么(迭代回顾会议的内容)

迭代回顾会议

通过鼓励团队对自己的开发过程问题的挖掘及一起对解决方案进行探讨，来让迭代效率更高、结果更令人满意和更易于工作。

《Agile Retrospectives》这本书中把回顾会议分成了5个阶段：

1. 准备

2. 收集数据

3. 产生见解

4. 确定改进项

5. 结束会议

先让大家放松下来，不要觉得会被追责，这其实和平时的团队文化也会相关。

介绍本次会议时长，大概的议程(流程)安排，目的是为了让大家对会议过程和时间有预期。

按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难，不过没关系，这个时候大家就会开始脑子飞快的转起来了，到底哪个词比较合适。这样不仅把大家带到了回顾的思路里，更重要的是大家一开始就有机会开口表达自己的想法了。

方法一：发贴纸，然后大家各自写，一个问题一张贴纸...

方法二：帆船回顾法

方法三：论坛接力留言

1、分类：邀请团队成员一起来做分类，一个人做卡片宣读，允许大家讨论，一个人把相同意思的卡片贴到一起。

2、投票：每人两票，投出三个核心问题进行讨论

形式：分组讨论

1、问题根因分析：鱼骨图或者5W。

2、讨论改进方案

3、输出改进方案：符合SMART原则，可执行。

注意：避免过多改进项，也不要提太不容易达成的解决方案，要根据团队具体情况把握。

1、总结

2、互相给感谢卡

1、把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效的使得改进落地。

2、回顾上次迭代的改进项完成情况

引自： ，按自己习惯，做了一点整合，侵删。

Scrum回顾会怎么开才高效

乘风破浪这个词火了，在Scrum中也有一个乘风破浪的活动即Scrum回顾会。检视调整是Scrum重要精髓之一，迭代回顾会议是Scrum中最有价值的会议之一，团队不断的复盘不断的检视达到团队自我持续改进、高效、自组织。

敏捷迭代固定时间盒，结束的标志之一是团队开完迭代回顾会，回顾会是Scrum从计划，执行到复盘的PDCA闭环，所以开好一场回顾会对Scrum master来说也是至关重要的一个流程。

回顾会前准备

迭代回顾会参加的人员有Scrum Master、团队所有成员、产品负责人等。对会议的参与人员发出会议通知，比如开会的时间，地点，会议议程等。同时提示大家提前思考本次迭代总结包括做的好的地方，需要改进的地方以及建议的改进措施。

Scrum master在回顾会开始前需要输出本次迭代的总结，包括不限于：

1.迭代用户故事完成情况，以及环比上个迭代情况

2.迭代bug数以及bug等级

3.冲刺预估工作量和实际完成情况对比

4.燃尽图燃尽情况，本次迭代进度

5.迭代的总结（好的流程或者待改进地方）Scrum master输出

回顾会中

回顾会议的基本原则：

1.对事不对人

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

3.从产品或者系统角度思考改进

回顾会议流程：

1.回顾上个迭代回顾会提出的改进措施是否落实以及完成

2.Scrum master对本次迭代概括性总结（会议前已输出）

3.引导团队成员轮流发言

4.Scrum master做好团队发言的记录，按照做的好的地方，需要改进的地方，改进措施三个维度记录

5.团队选择下个迭代最紧急且最重要2-3个改进项

6.讨论改进项的改进措施并做好记录

Scrum master在迭代回顾会中应该扮演复盘的引导人、设问人和叙述人。可以采用“三阶九步法”即精心准备，有效引导，推进到位（详见《复盘+》）。引导团队发言，比如打分法，迭代满分10分，引导团队成员给迭代打分，思考与发言。设问一些问题，比如迭代中某个接口开发遇到了某个问题对整个用户故事的提测影响等。

回顾会后

迭代回顾会结束之后，Scrum master把会议纪要和下个迭代改进的措施发到项目沟通群，提示团队改进同时跟进改进效果。

本人参与公司某个产品，从去年5月产品团队敏捷转型开始走Scrum流程到现在产品逐渐发展壮大拆分多个子产品团队，进行了大概30个Sprint（2周时间盒），收集并总结了团队成员反馈的共性问题，并在回顾会上引导成员讨论出优化改进措施，目前这些问题都已有解决方案，有的问题已经彻底解决了，有的问题还在不断改进完善中，这正是Scrum的精髓所在“检视调整”。

如何开好迭代回顾会

组织在引入Scrum框架后，会逐步了解到Scrum的团队组建、角色分工、交付工件和相关会议/活动等内容。随着框架的逐步落地，定义清楚相关角色、明确要交付的工件之后，如何通过Scrum的“4+1”活动来进行迭代管理并达成预期的目标？就成为团队必须要面对的问题。这里所谓Scrum“4+1”活动就是指每日站会、迭代计划会、迭代评审会、迭代回顾会和迭代梳理活动，有的团队通也会把迭代梳理活动作为其中一个会议，称之为迭代梳理会。所以我们也会听到有Scrum 5个会议的叫法，为了进一步的阐述和讨论，我们在此统一称之为为5个会议，接下来我们将逐一进行解读。

会议之一：迭代回顾会，Scrum指南对于回顾会是这样定义的：

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

迭代回顾会的目的是规划提高质量和效能的方法。

也就是说回顾会是团队进行阶段性改进的有效手段之一，在一轮迭代结束之后，如何让团队成员静下心来反思迭代过程中的问题并进行持续改进，我们尝试从以下几个方面对其进行解读和说明。

首先是要明确会议的目的，迭代回顾会的目的是检视和调整过程，识别问题并制定改进计划。

本轮迭代末。

对于为期2周的迭代来讲，时长控制在1~2小时，不要超过2小时。

那么迭代回顾会都有哪些角色参与呢，他们的工作如何分工？

SM，组织者

1. 关注迭代过程，做好度量与数据收集

2. 会议组织，资源准备

3. 引导会议进行，产出改进项，制定改进计划

POTeam，参与者

1. 参与迭代回顾，进行反馈

2. 协助SM进行问题分类，参与改进措施制定

3. 认领改进问题，确保持续改进效果

会议输入：

1. 迭代过程中的度量数据

2. 团队日常问题、痛点

3. 会议需要的材料

会议输出：

1. 改进计划，包括具体措施及责任人

1. 迭代过程数据收集（会前）

2. 选取合适的会议回顾方式（三栏式、海星图等）

3. 开展回顾，进行问题反馈

4. 问题分类、合并，识别Top问题

5. 团队集体参与，制定问题的解决措施，明确责任人

综上所述，我们从回顾会的目的、时间安排、时长，参与角色、准入准出以及流程方面给出了解读，虽然方法和流程都是通用的，但是通用的流程、同样的方法，有的团队就会做得比较高效，有的团队却经常超时、达不成目的。究其原因，真正要把评审会开好，除了会前的充分准备以外，会议过程的引导也至关重要。对于回顾会来讲，围绕迭代进行检视和调整，并形成可改进的行动项是我们的目的，所以开展正确的引导，避免大家在过程中太过发散、无法收敛，导致会议超时，影响参会者的体验。

实际上任何一个新的方法、框架在落地过程中，一定会有各种各样的问题，很难立马达成我们想要的结果，所以Scrum的会议本身也是在实战过程中迭代改进的，不是靠理论就能做好的，纸上得来终觉浅，绝知此事要躬行。希望团队能够基于实际问题出发，大家一起讨论、寻求解决方案，在实践中逐步迭代、达到预期的目的。

关于迭代回顾的一些看法

上次在敏捷讲座第二期中，有个老师提到敏捷中核心的两个优化，分别是优化商业价值和优化流程。

回到快速迭代的目的，就是期望小步快跑，不断回顾，如果只是跑，不回头看，及时纠偏，问题就不能得到及时解决，迭代也就是失去了本身的意义。通过迭代验收和迭代回顾，可防止越走越偏，始终保持团队尽快走到正确的路上。

因此，在敏捷中有两个重要的会议，一个是迭代验收，另一个是迭代回顾。

迭代验收 是团队和PO以及客户一起，由团队向PO展示本次迭代成果，希望能得到PO和客户的反馈意见，以便确保在商业价值和业务逻辑上方向的正确性。

迭代回顾 是指项目团队在一起，共同一起把本次迭代所有故事的实现过程进行复盘，分析并找到问题根源。在最后将所有问题逐一进行排列，由团队共同选取前三个最重要的问题，协商讨论具体的解决办法，实施方案，落实时间，责任人，规定动作，检查机制。然后在下一次迭代中去落实。

以上是个人对回顾会议对一些看法，其目的是希望大家能够正确理解回顾会议的真正目的，因为这才是我们永远只做有意义的事情的保障手段之一。

敏捷项目管理—回顾会议

最近因为在离职，从来不总结的我，希望也能慢慢的开始总结起来，很多东西，需要深入思考（这大概就是我太肤浅的原因，扶额）。

一直以来项目组对回顾会议的效果都是持怀疑的态度，总是以没有时间为由，放弃回顾。其实回顾会议还是很有必要的，项目一直高速往前冲，每天围绕着需求和bug不停的迭代，所以一定要抽出时间来总结，看看是不是在做无用功。

回顾会议关键是要确定形式和内容，传统的回顾就是总结和计划，太空洞了。最近经历的这次回顾，我觉得效果就很好，所以记录下来。

回顾会议召开的两个前提，就是开放和信任。

所谓开放，就是营造一个畅所欲言无拘无束的交流环境。首先就是高层领导不能在场，这样大家才能平等无顾忌的交流。其次可以在会议开始进行一些简短的破冰游戏，比如每个人交流一下最近的收获或者生活上的一些有趣的事情，以此来拉近彼此之间的距离。

所谓信任，就是假定之前迭代里所有的决策和处理方式都是ok的，不去追究之前存在的不合理，我们今天这个会议就是为了让今后做的更好，对事不对人。

我们这次会议的主要流程就是：

1、所有人进行分组，因为这次参与的成员有运维，测试，研发三个部门，所以每个小组都含有以上三个部门的成员。

2、给每个小组取名，选组长，设置口号（分组的目的是为了进行评比，加强大家的合作和积极性。我们有个组叫小虎队，然后另一个组就取名老虎队，于是第三个组顺理成章取名打虎队，瞬间气氛就特别欢乐）

3、分组完毕之后，就正式开始了回顾会议的主流程。

针对之前存在的bug（我们这次会议选取的是今年以来线上出现的所有bug）

每个小组选出本组认为排名前五的影响最大的bug

然后进行投票，确定大家都觉得影响最大的三个bug

然后每组选择一个bug进行原因分析

再进行解决方案的分析

最后，汇总所有的解决方案。再次对方案进行过滤，选择最重要的两个进行改进。

落实到部门和负责人以及进度安排。

之后在每次小组例会上都汇报任务的进度情况。

（上述每个环节都为了调动大家的积极性，小组采用计分制。为了确保获取每个人真实的想法，需要每个人都能在第一时间发表自己的看法，采用写便签的方式，不能互相交流，写完贴出来大家一起看，因为每个人的想法都很重要。）

4、感恩环节，每个人用便签写出最想感谢的人，为什么感谢，有哪些具体的事情或者表现。收到的感谢最多的有奖励。其实，这个时候有没有奖励都不重要，重要的是每个小伙伴会感受到自己的付出是有价值的。能得到团队的认可，其实非常开心。没有得到奖励的也会知道自己以后要怎么去做。（其实我觉得这个环节也可以增加鼓励的内容，并不是每个人都给别人有帮助，做的不好的被人指出来需要提升也是很有价值的）

通过这次回顾，大家最大的感受就是，很多问题的根本原因其实都一样，是符合20/80原则的。所以解决bug，不要疲于打补丁，而要从根本上下决心去解决问题。

其实对我个人而言，这次回顾不仅仅只是一个项目迭代的回顾会议，更是提醒了我，定期总结分析复盘是多么重要，能确立努力的方向，能给自己建立信心。