对一次复盘会议的复盘

  • 复盘,技术管理,技术复盘
  • 2020.08.19

最新项目里接连出现了好几个问题比较严重的 bug,我们称之为 p1 bug。在这么短的时间内连续出现这么多个问题,确实很难去解释,于是我们进行了一次复盘。

会议主题

其实在每个问题发送的时候,或者之后,我们已经对每个问题进行了复盘。分析这些问题发生的业务场景,产生问题的技术原因,以及如何规避的措施。而这一次,我们想要复盘的是,为何近期会如此集中的出问题,如何摆脱当前的状态。

原因还需要深挖

当复盘会议开完的时候,其实我并不满意,很多个问题,我们没有足够的分析清楚问题产生的根本原因,比如我们列举了没有写影响范围,没有自测,把这些当成了问题发生的重要原因,于是我们得出的结论是要写影响范围,要自测。但是要写影响范围和要自测,我们一直在强调,每周上线的时候,都在强调,但是为何还会没有写影响范围呢,而这个问题我们并没有去讨论。是大家不喜欢写,还是写的方式不让大家接受,亦或者是下发的行政命令不够强硬。

比如说要自测,自测是开发的一个基本职责,但是这个职责的边界有时候又很模糊,我们的开发在写完代码,或者修改完代码,基本上都会自己跑一遍的,自己没有跑,没有验证就直接提交甚至上线的,这样是绝对不允许的。但是每次出问题的时候,我们发现问题都出在了一些边界的地方,也就是我们没有验证的边边角角。这些边边角角,很多时候,开发会寄希望于测试人员来测试的,开发并不愿意像测试人员那样去测试自己的代码,从内心是抗拒的,一是觉得繁琐无聊没有技术含量,二是既然有测试,这些事情理应当交给测试人员来做。

所以,在分析问题上,我觉得我们没有追到底。

解决措施要客观

分析完问题,我们需要拿出解决措施,解决方案。

我认为的解决方案应该是客观的、量化的。但实际上,我们得到的一些方案,比如,我们要评估范围、我们要加强自测等等。这样的解决方案是不够的,会让我们同学们在具体实施的时候不知道该怎么操作。

比如说自测,经过强调,我们都会自测,只是自测的力度因人而异,因项目而异,因心情而异。所以我们需要的是一个自测的力度的要求,我们尽可能拿出一个可衡量的自测力度的标准,而不是简单强调要自测,或要加强自测。

比如说评估范围,我们经常会漏掉影响范围的评估,一个原因是我们在编码的时候,并没有意识到影响范围,因为每个人对代码的熟悉程度是不一样的,同一个人不同状态下也是不一样的。这个时候,可能我们需要一个手册,需要一个 checklist,当我们编码的时候,可以参照手册来评估范围。手册上可能会包含一些具体模块以及响应的影响范围,比如你修改了网络请求模块,那么影响范围就是全站网络请求。手册上也可能会包含一些之前评估范围的经验和案例,比如某项目在修改 A 类的时候,产生过某个之前未评估到的影响。我们的开发人员可以在编码前后,照着这个手册来评估影响范围,我们尽可能的去维护和完善这个手册,让每个人的评估不会偏差很多。

我们出现的问题是粗心,解决办法是下次细心点。这样根本等于没有复盘。

相关文章

- EOF -

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动。
转载请注明:文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题: 对一次复盘会议的复盘
本文地址: https://binkery.com/archives/2020.08.19-对一次复盘的思考.html

赞助商
网站统计
  • 网站运行:3321 天
  • 文章总数:738 篇
  • 网站统计