如何有效进行回顾会议(上)?

2022-07-19 17:17:26
yanruiyu
翻译:
agilepainrelief
579
在Scrum团队中,回顾会议可能大家都在做,但要怎样才能做好回顾会议呢?

一、消除误解

首先我们要来为回顾会议正名:

1.回顾会议就是专案事后分析吗?

虽然这样问,大家一定会回答不是,但我们的小科普还是要继续的。传统 项目管理会通过专案事后分析来进行系统改进,但这并不代表回顾会议就等同于专案事后分析。两者具体有什么区别呢?
  • 发生阶段不同:回顾会议鼓励在整个项目过程中通过Sprint的方式进行,因此我们通常是在每一Sprint结束时进行回顾会议;专案事后分析则是在项目完成或终止后进行。
  • 关注点不同:回顾会议关注于在项目过程中不断改善,是短周期的反馈;专案事后分析则是总结本次项目过程的经验教训,在下次项目中进行改善,是长周期的反馈。
  • 产出物 不同:回顾会议产出的是执行路径;专案事后分析产出的是文档。

2.回顾会议就是评审会议吗?

同样,答案是否定的。很多人不习惯将产品改进与流程改进分开进行,所以会将两者合在一起进行。
Sprint评审会议为开发团队、产品负责人、Scrum Master、利益相关者提供了一个来对产品进行检查并做出改进决策的机会;而回顾会议是关于团队和流程改进的,主要用来检查团队如何完成工作、做出决策、成员如何进行沟通的。

3.一直是相同的议程?

我们在进行回顾会议的时候,不必拘泥于一种既定的流程,因为这种流程会逐渐演变为流于形式,回顾的效果也就大大降低。在下面也会提供回顾会议的组织形式,不要再让团队成员在回顾会议上习惯性地重复啦!

二、有效回顾会议的必备要素

1.不去过多地责备

“无论我们发现了什么,我们都理解并真正相信,考虑到他们当时所知道的、他们的技能和能力、可用的资源以及手头的情况,每个人都做了他们所能做的最好的工作。”这句话其实并不是说大家都是无可指责的,在过多的责备中,我们可能逐渐变得关注于某个人的行为而不是整个团队的行为。

举个例子:在一个Sprint中,团队发现了一个Bug。其中一名团队成员急于修复和部署,虽然这个问题解决了,但也产生了一个新的、更大的问题。 

在这种情况下,我们过多地去追究他个人的原因,反而有可能忽视团队的一些不规范的地方,如没有检查“完成”的定义、没有运行单元测试等等。在这种环境下,团队成员更有可能感觉自己受到攻击而不是承认解决了最初的问题。因此,他们不太可能从批评中学到任何东西,最重要的是,他们可能会错过深入研究系统性问题的机会。

三、回顾形式

1.故事奥斯卡回顾会

在白板上绘制一个方框,在框中将用户故事故事分成几种类型:最佳故事、最令人郁闷的故事以及最令人惊讶的故事。团队在回顾会议上来通过便利贴将上个Sprint中完成的用户故事贴在相应的框中。如果每种类型中有很多用户故事被提名,那大家再集体在这些用户故事中选出最佳/最令人郁闷/最令人惊讶的用户故事。

2.帆船回顾会

在这个回顾会上,我们乘坐的是一艘即将登上岛屿的小船,在这个过程中,我们会遇到很多推动和阻碍的因素:
  • :项目团队;
  • 岛屿:Sprint目标;
  • 顺风:推动我们的Sprint顺利进行的因素;
  • 船锚:阻碍我们Sprint实现的因素;
  • 礁石:已经识别的潜在风险。
那在这个回顾会中,每个人都要来分析在这个Sprint中,我们的顺风、船锚和礁石是什么,以及接下来为了避开礁石、提前收好船锚,我们要做出哪些努力和计划。

有了这些小技巧,我们就可以尝试开启一个崭新的回顾会议啦,接下来我们还会有更多关于回顾会议的方法,持续关注我们吧!
文章分类
联系我们
  • 联系人:阿道
  • 联系方式: 17762006160
  • 地址:青岛市黄岛区井冈山路157号中南金石国际广场A座3202室
投稿邀请

如果您有优秀的原创文章,欢迎添加联系人直接与我们联系,或通过下方邮箱发送投稿文章,一经采用,我们会付以一定的稿件报酬。

  • 投稿邮箱: yanruiyu@easycorp.ltd
  • 投稿标题:向 [敏捷开发] 网站投稿
  • 稿件要求:与敏捷开发相关的任何内容

更多投稿相关请点击 更多进行了解~