Sprint回顾会议的一种简单玩法

来源:互联网 发布:linux显示文件内容命令 编辑:程序博客网 时间:2024/05/14 11:01

原文作者:Mike Cohn


回顾会议该怎么开?团队不同,大家的做法或许各有不同。我想介绍一种我最喜欢的方式,特别是因为这种方法经受住了时间的考验,很多年以来,我已经把它运用在了很多很多的团队里。

开始/停止/继续

我喜欢在sprint回顾会议上问团队成员3个问题:他们想开始做什么?他们想停止做什么?他们想继续做什么?这种类型的会议因此有了一个别名,叫“开始/停止/继续”会议。

开始事项是指某个团队成员想要团队把它们加入流程的那些事。一些例子如下:

  • 把软件早一点展示给客户
  • 早一点与客户确定验收测试
  • 做代码审查
  • 准时参加每日站会
  • 在当前需求没有完成之前不要开始做新需求

停止清单上的事项是指团队里的人认为效率低下或者浪费时间的那些事。团队应该停止做这些事。一些例子如下:

  • 在还没有跑通过所有测试之前就提交代码
  • 每日站会的时间超过15分钟
  • 在我们觉得当前sprint进度落后的时候跳过product backlog refinement会议

继续清单上的事项是指团队想要继续重视但还没有养成习惯的那些事。也就是说,上述开始或停止清单上的任何事项都可能进入继续清单,并且在这个清单上呆上几个sprint。

做一件事一旦变成了习惯,它便将最终从继续清单上删除。要不然,继续清单会变成超级冗长!

以不同的方式询问

Scrum Master可以用不同的方式去询问团队成员。最简单的就是,直接让他们大声说出来。团队成员可以自由地说出他们想要开始/停止/继续的事项。这是我的默认模式。

但是,如果总是这样子,一个sprint接着另一个sprint,难免会让人觉得乏味。因此,我会搞些花样,有时候我会在房间里四处走动,挨个儿叫他们给我一个事项,也许在房间里走上两遍之后才会进入下一个议程。

其他时候,我会关注在一种特定类型的事项上——常常是停止事项。我会让所有团队成员直接说出他们想要停止做的事情,除此之外什么也别说。我可能会混用两种方法。我会走到每个人的身边,挨个儿让他们指出在当前流程里他们想要停止做的一件事。

在“开始/停止/继续”回顾会议上,为了收集大家的想法,有大量方法可以混合起来使用。这些方法足够用一阵子的,不至于让大家觉得无聊或重复。

投票

在收集了足够多的想法之后,就要请团队成员投票选出最重要的一项或几项。什么时候该开始投票呢?这常常是显而易见的,也就是在创造性逐渐消失、新的想法不再那么快速冒出来的时候。

Scrum Master可以让每一个团队成员给最重要的一项投票,或者也可以使用任何典型的多投方法。举例来说,给每个团队成员3张选票,他们可以根据自己的意愿把票投出去(包括把所有3张票都投给同一项)。

我喜欢在回顾会议上采用多投这种方法。回顾会议列出来的大部分事项,实际上很多都不需要花时间去做。很多都是行为上的。考虑一下上面给出的一个例子:要准时参加每日站会。那不用花时间。实际上,也许还是省时间的。

通过多选,团队可以选择改变行为,以及做一些其他事。通常来说,我的选择不会超过3项。即使它们不费时间(或者说不费很多时间),选择太多事项也会降低那些所选择之事的重要性。

除了投票选出新增事项之外,也需要讨论一下继续清单上的那些事项,是否已经达到预期了,于是不再重要或者因为其他什么原因应该从清单上删除了。

下一次回顾

在下一次回顾会议上,我建议Scrum Master把前一次会议上收集来的想法都过一遍,包括那些被选择执行的和没有被选择的。这些可以作为下一次回顾会议的开场讨论。

我喜欢在一张大纸上把它们都写下来,然后静静地把它贴在墙上。如果团队需要,或者想要参考一下,这些事项总是静静地呆在那里。然后,我会组织新一轮的“开始/停止/继续”讨论。

有哪些好处?

我发现,这样组织回顾会议的好处是:快、容易做、没压力、有效!“开始/停止/继续”会议是非常行动导向的。我们没有花时间在员工感受上。我们没有问团队成员他们在sprint里的感受怎么样,是开心还是不快,感受到了温馨还是矛盾……

每个事项都会直接引起行为上的改变。团队将开始做一些事,或者他们将停止做一些事,或者他们将继续做一些事,直到养成一种习惯。

我可以预见,很多人会说,员工的感受才是重中之重。我们只有首先处理好人们的感受问题,我们才不知道应该怎样去采取行动。没错!有一些情况确实是这样。但是,在其他大量的情况下,我们可以直接分辨出该做的事情(比如“我们需要开始早点做测试”)。

这就是在sprint回顾会议上引入“开始/停止/继续”方法的优势所在!

2 0