Scrum – 回顾会议(Retrospective Meeting)

回顾会议是 Scrum 中最重要的一个会议, 它让有机会反省在上个 sprint 所做的一切事情. 老中很努力工作, 可是却不检讨做事方法, 所以工作的很辛苦,却不见得有效率.

要开会, 第一件事情就是要决定谁要主持这个会议. 在当开始的时候, 是从 manager 开始, 而且是从我先中奖. 这是因为没有人教我们如何进行回顾会议(retrospective), 我们家的 RD lead 教我要先牺牲一下. 之后我们主持的顺序如下:

(1) 所有经理: 我们有管项目进度和范围的经理(JM), 开发人员的经理(DM), 和测试人员的经理(QM)(2) Lead (RD 和 QA 的lead)(3) 每位成员轮流

这样作法有些好处:

(1) 一开始可以由经理示范会议要如何进行, 当然这不是绝对, 后面的主持人还是可以修改部分进行的方式

(2) 让大家轮流可以增加参与感, 不会认为这是某个人的事情

(3) 让大家都有准备资料, 会更知道项目目前整体的状况

参加会议的成员, 基本上有开发人员, 测试人员, Human Interface Engineer, UI engineer, SQA 和团队的经理(JM, DM, QM).偶而会有产品经理(PM), 和一些慕名来插花的人员. 像是别的团队想要引进Scrum的人.

基本上, 大家都可以发言, 不过别的团队的并不会发言, 最多是私下询问 JM 一些相关的问题. 我们并没有像 Agile中Pig/Chicken, 这样壁垒分明. 因为只要对团队有用的, 都可以提出建言, 虽然不一定会采用, 但至少我们保持开放的心态.

一开始RD lead有给我一堆数据, 要我好好恶补, 到底要怎么开会

本来的一开始我们是套用XXXX方法, 列出三项事情来讨论: Good, Could have been better, Improvment. 之后变成: Happy, Unhappy, Do more, Do less, Confuse和XXX. 最后演变成Happy, Unhappy, Do more, Do less.

进行的方式类似IDEO brainstorming的process, 步骤如下:

(1) 请大家把想法写在便利贴上面.

(2) 写完后贴到白板上(放到上面不同的项目中, 像是Happy或是Unhappy…等等), 并且大声说出的想法.

(3) 第一和第二的步骤反复进行, 直到大家用尽所有的想法

(4) 接着大家开始对这些便利贴做分类, 但是此时不能出声, 不能交谈, 只能移动便利贴. 若是有冲突, 会在数次来来回回移动中, 自然达成共识.(也可能不会, 但是我们最后总会有人屈服, 呵呵)

(5) 然后开始对这些分类后的群组投票, 票选出大家认为前三重要的群组.

(6) 挑选出来后, 便开始对这个群组讨论要如何改进.

这样做可以有以下好处:

(1) 大家可以畅所欲言, 不管是好的坏的, 让每个人有抒发的管道, 以及感谢的时间点. 以下就是类似的对话

A: 感谢JM提供零食B: QA不要只是先写测试程序, 应该要先手动验证功能是否正确C. SQA都会适时提醒我们要注意的地方D. RD要先解show stoppers…..大家会感情比较融洽, 因为不会有事只能放在心底.

(2) 将问题可视化, 不会讲完后就被遗忘, 在白板上就能看到这些想法. 且因为有人抛砖引玉, 而促使大家想出更多的想法

(3) 因为是写在便利贴上面, 字体不会太大, 所以大家需要几到前面去才能看得见, 可以让团队开会更专心, 更紧密. 只要是坐在后面的, 便知道他并没有想加入讨论.

(4) 解答是大家想出来的, 所以大家会比较愿意去执行, 不是经理们强迫大家去接受它.

不过这里有些规则要遵守:

(1) 没有主意是坏主意, 不要有人一提出想法, 就加以批评.

(2) 每次只有一个人说话

(3) 可以鼓励成员发言, 但是不用要求每个人依序发言

会议的流程, 本来是只讨论这些东西(Happy, Unhappy, Do more, Do less). 后来有人建议需要加上一些项目的数据, 让大家清楚目前做的状况. 若是正常一般 Scrum 团队会看 burndown chart. 可是我们是列出以下项目:

(1) Task board : 让我们概念性知道多少完成, 多少没有完成. 因为这里我们只是拍下照片来检视, 并没有任何加工

(2) 故事完成度信息: 我们会列出每个人在每个故事中预估要做的点数, 实际达成的点数. 这里是比较详细的资料, 目前由我们JM来维护这份资料

(3) 现存错误个案(defect)的状况: 列出每个人手上有多少未处理完的错误个案, 以及这些错误个案都是发生在那些功能上

(4) 未来主要的milestones: 让大家了解那些大的event在什么时候要发生

(5) 下一个循环(iteration)要做的故事: 所有人可以先心里有谱, 接下来有哪些事情要做项目看起来不少, 但是除了第一次简报这些项目外, 之后我们每页大约花不到1~2分钟就讲完, 单然如果有人问问题不算. 所以我们还是留很多时间去做讨论. 基本上, 我们认为双相沟通, 远比单向传递重要.

(6) 回顾之前问题: 看看之前的问题是否已经被解决了, 会请相关的人加以说明.

在讨论问题的解决方法时, 时间是一个很大的限制, 我们有几种作法:

(1) 在会议中讨论完: 对于一些不是很严重的项目, 或是想不出办法的, 可能在会议中时间到就会做个结论, 之后并不会再花时间去讨论.

(2) 会议后留下来讨论: 因为这时候大家都在一起, 并且动机上比较强烈, 若是很严重的问题, 大家便会在会议后留下来讨论.

(3) 事后个别召开会议: 有些项目比较严重, 但是需要一点时间准备, 或是相关的利害关系人不在, 因此需要之后再找时间开会讨论.

目前这样的处理方式, 个人认为优缺点如下:

优点:

(1) 让大家知道和面对目前的问题, 而不是藏在心理

(2) 或许没有很好的解法被提出, 但是因为大家知道, 在心理上便会去思考, 或是尽量去减低这些状况发生的机率

缺点

(1) 不容易有很 solid 的解法, 有些问题并容易解决, 而且可能也没有太多时间让大家去找答案

(2) 并没有很强烈的 follow up 处理, 因为有些并没有列出详细的 action items, 只是让大家提出 high level 解法.

老实说, 是真的还没有很理想. 但是值得肯定的地方我们能早点给 feedback, 不会等到整个项目结束后才来讨论之后要如何改进, 大家愿意处理的动机比较强. 可能每次改进10%, 5%, 但是还是有进步, 大家比较能及时被鼓励到.

至于会议的时间, 一开始是两个小时, 是有点长, 一方面我们不熟悉会议的流程和议题, 一方面我希望能给大家较多讨论的时间. 后来JM觉得这样时间太长了, 因此我们大约只浓缩到一个小时, 或许这样让大家有比较时间做自己的事吧.

因为我们并没有在 sprint 和 sprint 中间有个休息的时间(slack time), 所以我们再这时候都会去点一些饮料或是点心, 一边吃一边进行, 勉强弭补一下. 不过也因为经济不景气, 所以丰盛的程度也不高, 是美中不足的地方.

目前Teambition可以免费使用,对于有一定规模的团队,可以选择使用企业版本的Teambition,每月一杯咖啡的投入,换来成倍改善的沟通效率。

您可能也感兴趣:

所不了解的Android调色板
抛开浮华看内涵:再回首《金庸群侠传》
抽象工厂模式
拒绝重写
推荐那些功能强大的在线工具
摘自WWDC 2014
Web项目管理系统
操作系统 处理器调度
操作系统的故事(三)— Linux的崛起
整数王国传说