“回顾会议用ORID” 拍了拍你 | IDCF

DevOps

共 2372字,需浏览 5分钟

 ·

2022-04-27 18:11

来源:拔菜集

作者:小凉

回顾会议是SCRUM中的重要仪式之一,承上启下,三省吾身。 ORID是用来做焦点讨论的有效方式。(Objective - Reflective - Interpretive - Decisional)


背景



两周一个sprint后,作为“敏捷大师”的小凉照例要安排一场回顾会议,这一次小凉打算用ORID焦点讨论大法。

记得第一次在前辈那里看到这种回顾会议的方法时,小凉就眼睛一亮,ORID回顾过程循序渐进,仪式感十足,在不知不觉中引导团队寻求更好的改进方案。

ORID即四个英文字母的简称(Objective - Reflevtive - Interpretive - Decisional), 是一种通过催化师(主持人、引导讲师)引导来开展的结构化汇谈(会议、交谈)形式。


会前准备



物料准备都是实物的,没有任何电子文档:

  • 若干只笔(保证每个参会人员都有一支笔)
  • 四种颜色的便签
  • 一张A1大白板纸,画四环闭圈,如图所示
小凉喝口水,清清嗓子:“人都到齐了,我们开始回顾会议吧。今天回顾会议会进行四轮的讨论,每一轮我会先抛出议题,然后你们把自己的想法写到便签纸上,一个想法写一条,每个人“展示”自己的想法后,进入下一轮。现在我们开始第一轮的讨论”。

第一轮:“我看到/听到”



“第一轮的讨论是objective,请大家回顾一下我们过去的这一个sprint。以“我看到”,“我听到”开头列出自己观察到的事实”。
“注意,只列出客观事实,不做主观评判,目的是想让大家从各自的角度出发信息共享”。
QA 西西有问题,“写多少条有限制吗?”
“不愧是QA”, 小凉想,“没有限制,越多越好,但是只给大家3分钟时间回忆,然后写下你所观察到的客观事实。”
大家开始若有所思......
半分钟后,南南奋笔疾书,一张小便签越写越多。小凉及时问他,“最好每张纸条只写一项。这样有利于之后我们问题追踪。”
大概三分钟后,小凉说:“我们开始陈述下每个人自己的观察吧,为了信息更为均匀,我们每个人每次只说一条,等所有人说完一圈后,再说第二条。如果别人的某条观察和你还未说出的一样,那么你也可以及时的和他的贴在一起,所有的纸条都贴到圆圈的最外圈。
西西最先开始 :“我看到我们这周有个功能上线,bug只有一个,我觉得这次发布的质量很好。。。”,小凉连忙叫停:“注意注意,只说出你看到的客观事实即可,不要进行主观评论”, 西西连忙止住,示意下一个。
南南继续:“我听到上周页面设计师在问我们的开发计划,想和我们同步一下整个流程。”
......
慢慢的,大白纸的最外圈被贴满便利贴。

第二轮:“我感动”



小凉看着满满当当的便签条感到很欣慰,因为大家的表达的积极性已经被调动起来。乘热打铁开始了第二轮的讨论。
“第二轮,以一下描述喜怒哀乐的句子开头,描述自己的心情”。 
  • “我高兴,因为xxx”
  • “我难过,因为xxx”
  • “我喜欢xxx”;“我不喜欢xxx”
“还是先不要互相打扰,自己回忆,写到便签纸上。”
西西示意有问题:“是针对我们上一轮的结果写感受吗?”
小凉回答:“可以基于你自己或者别人上一轮的结果写感受,其实是经过上一轮信息共享以后的感觉。”
三分钟后,南南率先分享自己的思考,“我觉得很高兴,因为我们上周发布的过程很顺利,没有发现大问题,甚至小问题也没有几个。”
西西也忍不住,“我也觉得这次的发布质量非常好,我要点个赞。”
轮到北北发言了,“我有点担心,我们的开发计划比较模糊,对于外部团队来说很难理解,尤其是设计团队,他们设计的先后顺序是要依赖于我们的发布计划。”
第二圈也慢慢的被填满了。

第三轮:“我觉得”



小凉继续引导,“接下来这一圈,需要大家基于你自己或者别人前两轮的分享讨论进行反思,用‘我觉得’开头说出你的提议。
“还是老规矩,三分钟思考时间,写下你的提议,然后依次分享。”
三分钟后,北北最先开始, “我觉得我们应该和设计团队针对开发计划进行沟通,让大家对于优先级达成共识。”
东东提议,“我们这次发布大家合作很好,上线也很顺利,是不是应该一起庆祝一下!”,东东的提议立刻得到了几乎所有人的支持。
小凉在这个轻松的时刻,调皮的说:“我觉得应该没有什么问题,回头我跟周老板商量下,然后且等安排吧。”
提议还在继续,小凉边听大家的讨论,边把一些有可能形成这次回顾会议改进项的纸条贴到白板醒目位置,总共6项,包括:
  • “我觉得我们的发布版本管理需要标准化”

  • “我觉得我们把一些讨论会议尽量放在上午,这样下午会留出大段的时间写代码”

  • 等等...


第四轮:“我决定”



面对多达六项的提议,小凉说:“为了保证我们的执行力,我们的改进项最多有3项,所以我们现在需要投票,每个人三票,投出你觉得最想改进的点。”
大家陆陆续续的把手里的投票小蓝点放在自己觉得很重要的改进项后面。
最后三个改进项脱颖而出
  • “重新梳理发布版本管理”
  • “会议时间尽量放在上午”
  • “和页面设计团队沟通优先级”
小凉知道,现在离成功还差一小步,可是这一小步决定了回顾会议的质量最后两个问题不得不问:
“对每一个改进项,怎样我们认为是完成了?”
“谁愿意做这一项的负责人,负责保证它是在下个sprint期间完成?”
“每一个改进项是不是SMART?” 

会议结束后



一个半小时的会议后,大家走出会议室,感觉很累,但是又意犹未尽。
小凉把最后生成的改进项,以及更详细的验收标准记录到团队的共享站点中,还不忘把会议过程中激烈讨论的图片一并上传。
小凉知道,这些都是团队成长道路上的反思,回顾还将在下一个sprint继续。

玩乐高,学敏捷,【规模化敏捷联合作战沙盘之「乌托邦计划」】,2022年5月28-29日登陆成都,将“多团队敏捷协同”基因内化在研发流程中,为规模化提升研发效能保驾护航!!🏰⛴

企业组队和个人均可报名参加,一起挑战极客乌托邦


浏览 8
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报