最新项目里接连出现了好几个问题比较严重的 bug，我们称之为 p1 bug。在这么短的时间内连续出现这么多个问题，确实很难去解释，于是我们进行了一次复盘。
其实在每个问题发送的时候，或者之后，我们已经对每个问题进行了复盘。分析这些问题发生的业务场景，产生问题的技术原因，以及如何规避的措施。而这一次，我们想要复盘的是，为何近期会如此集中的出问题，如何摆脱当前的状态。
当复盘会议开完的时候，其实我并不满意，很多个问题，我们没有足够的分析清楚问题产生的根本原因，比如我们列举了没有写影响范围，没有自测，把这些当成了问题发生的重要原因，于是我们得出的结论是要写影响范围，要自测。但是要写影响范围和要自测，我们一直在强调，每周上线的时候，都在强调，但是为何还会没有写影响范围呢，而这个问题我们并没有去讨论。是大家不喜欢写，还是写的方式不让大家接受，亦或者是下发的行政命令不够强硬。
比如说要自测，自测是开发的一个基本职责，但是这个职责的边界有时候又很模糊，我们的开发在写完代码，或者修改完代码，基本上都会自己跑一遍的，自己没有跑，没有验证就直接提交甚至上线的，这样是绝对不允许的。但是每次出问题的时候，我们发现问题都出在了一些边界的地方，也就是我们没有验证的边边角角。这些边边角角，很多时候，开发会寄希望于测试人员来测试的，开发并不愿意像测试人员那样去测试自己的代码，从内心是抗拒的，一是觉得繁琐无聊没有技术含量，二是既然有测试，这些事情理应当交给测试人员来做。
所以，在分析问题上，我觉得我们没有追到底。
分析完问题，我们需要拿出解决措施，解决方案。
我认为的解决方案应该是客观的、量化的。但实际上，我们得到的一些方案，比如，我们要评估范围、我们要加强自测等等。这样的解决方案是不够的，会让我们同学们在具体实施的时候不知道该怎么操作。
比如说自测，经过强调，我们都会自测，只是自测的力度因人而异，因项目而异，因心情而异。所以我们需要的是一个自测的力度的要求，我们尽可能拿出一个可衡量的自测力度的标准，而不是简单强调要自测，或要加强自测。
比如说评估范围，我们经常会漏掉影响范围的评估，一个原因是我们在编码的时候，并没有意识到影响范围，因为每个人对代码的熟悉程度是不一样的，同一个人不同状态下也是不一样的。这个时候，可能我们需要一个手册，需要一个 checklist，当我们编码的时候，可以参照手册来评估范围。手册上可能会包含一些具体模块以及响应的影响范围，比如你修改了网络请求模块，那么影响范围就是全站网络请求。手册上也可能会包含一些之前评估范围的经验和案例，比如某项目在修改 A 类的时候，产生过某个之前未评估到的影响。我们的开发人员可以在编码前后，照着这个手册来评估影响范围，我们尽可能的去维护和完善这个手册，让每个人的评估不会偏差很多。
我们出现的问题是粗心，解决办法是下次细心点。这样根本等于没有复盘。
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 对一次复盘会议的复盘
本文地址： https://binkery.com/archives/2020.08.19-对一次复盘的思考.html