25 | 开发中的问题一再出现，应该怎么办？

Mar 1, 2019

25 | 开发中的问题一再出现，应该怎么办？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

25 | 开发中的问题一再出现，应该怎么办？

2019-03-01 郑晔来自北京

《10x程序员工作法》

课程介绍



讲述：郑晔

时长10:42大小9.82M



你好，我是郑晔。
看过《圣斗士星矢》的同学大多会对其中的一个说法印象颇深：圣斗士不会被同样的招数击败两次。
我们多希望自己的研发水平也和圣斗士一样强大，可现实却总不遂人愿：同样的线上故障反复出现，类似的 Bug 在不同的地方一再地惹祸，能力强的同学每天就在“灭火”中消耗人生。我们难道就不能稍微有所改善吗？
如果在开发过程中，同样的问题反复出现，说明你的团队没有做好复盘。
什么是复盘？复盘，原本是一个围棋术语，就是对弈者下完一盘棋之后，重新把对弈过程摆一遍，看看哪些地方下得好，哪些下得不好，哪些地方可以有不同甚至是更好的下法等等。
这种把过程还原，进行研讨与分析的方式，就是复盘。
现如今，复盘的概念已经被人用到了很多方面，比如，股市的复盘、企业管理的复盘，它也成为了许多人最重要的工具，帮助个体和企业不断地提升。这其中最有名的当属联想的创始人柳传志老爷子，他甚至把“复盘”写到了联想的核心价值观里。
为什么复盘这么好用呢？在我看来有一个重要的原因，在于客体化。
俗话说，当局者迷，旁观者清。以我们的软件开发作为例子，在解决问题的时候，我们的注意力更多是在解决问题本身上，而很少会想这个问题是怎么引起的。
当你复盘时，你会站在另外一个视角，去思考引起这个问题的原因。这个时候，你不再是当事者，而变成了旁观者。你观察原来那件事的发生过程，就好像是别人在做的一样。你由一个主观的视角，变成了一个客观的视角。
用别人的视角看问题，这就是客体化。
在软件开发领域，复盘也是一个重要的做法，用来解决开头提到那些反复出现的问题，只不过，它会以不同的方式呈现出来。
回顾会议回顾会议是一个常见的复盘实践，定期回顾是一个团队自我改善的前提。回顾会议怎么开呢？我给你分享我通常的做法。
作为组织者，我会先在白板上给出一个主题分类。我常用的是分成三类：“做得好的、做得欠佳的、问题或建议”。
还有不同的主题分类方式，比如海星图，分成了五大类：“继续保持、开始做、停止做、多做一些、少做一些”五类。
分类方式可以根据自己团队的喜好进行选择。我之所以选用了三类的分类方式，因为它简单直观，几乎不需要对各个分类进行更多的解释。
然后，我会给与会者五分钟时间，针对这个开发周期内团队的表现，按照分类在便签上写下一些事实。比如，你认为做得好的是按时交付了，做得不好的是 Bug 太多。
这里面有两个重点。一个是写事实，不要写感受。因为事实就是明摆在那里的东西，而感受无法衡量，你感觉好的东西，也许别人感觉很糟糕。
另外，每张便签只写一条，因为后面我要对便签归类。因为大家是分头写的，有可能很多内容是重复的，所以，要进行归类。
五分钟之后，我会号召大家把自己写的便签贴到白板上。等大家把便签都贴好了，我会一张一张地念过去。
这样做是为了让大家了解一下其他人都写了些什么，知道不同人的关注点是什么。一旦有哪一项不清楚，我会请这张便签的作者出来解释一下，保证大家对这个问题的理解是一致的。在念便签的同时，我就顺便完成了便签归类的工作。
等到所有的便签都归好类，这就会成为后续讨论的主题，与会者也对于大家的关注点和看到的问题有了整体的了解。
做得好的部分，是大家值得自我鼓励的部分，需要继续保持。而我们开回顾会议的主要目的是改善和提升，所以，我们的重点在于解决做得不好的部分和有问题出现的地方。
在开始更有针对性的讨论之前，我会先让大家投个票，从这些分类中选出自己认为最重要的几项。我通常是给每人三票，投给自己认为重要的主题。每个人需要在诸多内容中做出取舍，你如果认为哪一项极其重要，可以把所有的票都投给这个主题。
根据大家的投票结果，我就会对所有的主题排出一个顺序来，而这就是我们要讨论的顺序。我们不会无限制的开会，所以，通常来说，只有最重要的几个主题才会得到讨论。
无论是个人选择希望讨论的主题，还是团队选择最终讨论的主题，所有人都要有“优先级”的概念在心里。然后，我们就会根据主题的顺序，一个一个地进行讨论。
讨论一个具体的主题时，我们会先关注现状。我会先让写下反馈意见的人稍微详细地介绍他看到的现象。比如，测试人员会说，最近的 Bug 比较多，相比于上一个开发周期，Bug 增加了 50%。
然后，我会让大家分析造成这个现象的原因。比如，有人会说，最近的任务量很重，没有时间写测试。
再下来，我们会尝试着找到一个解决方案，给出行动项。比如，任务重，我们可以让项目经理更有效地控制一下需求的输入，再把非必要的需求减少一下；测试被忽略了，我们考虑把测试覆盖率加入构建脚本，当测试覆盖率不足时，就不允许提交代码。
请注意，所有给出的行动项应该都是可检查的，而不是一些无法验证的内容。比如，如果行动项是让每个程序员都“更仔细一些”，这是做不到的。因为“仔细”这件事很主观，你说程序员不仔细，程序员说我仔细了，这就是扯皮的开始。
而我们上面给出的行动项就是可检查的，项目经理控制输入的需求，我们可以用工作量衡量，还记得我们在讨论用户故事中提到的工作量评估的方式吗？
控制工作量怎么衡量？就是看每个阶段开发的总点数是不是比上一个阶段少了。而测试覆盖率更直接，直接写到构建脚本中，跑不过，不允许提交代码。
好，列好了一个个的行动项，接下来就是找责任人了，责任人要对行动项负责。
比如，项目经理负责需求控制，技术负责人负责将覆盖率加入构建脚本。有了责任人，我们就可以保障这个任务不是一个无头公案。下一次做回顾的时候，我们就可以拿着一个个的检查项询问负责人任务的完成情况了。
5 个为什么无论你是否采取回顾会议的方式进行复盘，分析问题，找到根因都是重要的一环。
你的团队如果能一下洞见到根因固然好，如果不能，那么最好多问一些为什么。具体怎么问，有一个常见的做法是：5 个为什么（5 Whys）。这种做法是丰田集团的创始人丰田佐吉提出的，后来随着丰田生产方式而广为人知。
为什么要多问几个为什么？因为初始的提问，你能得到的只是表面原因，只有多问几个为什么，你才有可能找到根本原因。
我给你举个例子。服务器经常返回 504，那我们可以采用“5 个为什么”的方式来问一下。
为什么会出现 504 呢？因为服务器处理时间比较长，超时了。
为什么会超时呢？因为服务器查询后面的 Redis 卡住了。
为什么访问 Redis 会卡住呢？因为另外一个更新 Redis 的服务删除了大批量的数据，然后，重新插入，服务器阻塞了。
为什么它要大批量的删除数据重新插入呢？因为更新算法设计得不合理。
为什么一个设计得不合理的算法就能上线呢？因为这个设计没有按照流程进行评审。
问到这里，你就发现问题的根本原因了：设计没有经过评审。找到了问题的原因，解决之道自然就浮出水面了：一个核心算法一定要经过相关人员的评审。
当然，这只是一个例子。有时候，这个答案还不足以解决问题，我们还可以继续追问下去，比如，为什么没有按流程评审等等。
所以，“5 个为什么”中的“5”只是一个参考数字，不是目标。
“5 个为什么”是一个简单易上手的工具，你可能听了名字就知道该怎么用它。有一点需要注意的是，问题是顺着一条主线追问，不能问 5 个无关的问题。
无论是“回顾会议”也好，“5 个为什么”也罢，其中最需要注意的点在于，不要用这些方法责备某个人。我们的目标是想要解决问题，不断地改进，而不是针对某个人发起情感批判。
总结时刻在软件研发中，许多问题是反复出现的，很多开发团队会因此陷入无限“救火”中，解决这种问题一个好的办法就是复盘。
复盘，就是过程还原，进行研讨与分析，找到自我改进方法的一个方式。这种方式使我们拥有了客体化的视角，能够更客观地看待曾经发生过的一切。这种方法在很多领域中都得到了广泛的应用，比如股市和企业管理。
在软件开发中，也有一些复盘的实践。我给你详细介绍了“回顾会议”这种形式。
无论哪种做法，分析问题，找到根因是一个重要的环节。“5 个为什么”就是一个常用的找到根因的方式。
如果今天的内容你只能记住一件事，那请记住：定期复盘，找准问题根因，不断改善。
最后我想请你分享一下，你的团队是怎么解决这些反复出现的问题呢？欢迎在留言区写下你的做法。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 22

提建议

24 | 快速反馈：为什么你们公司总是做不好持续集成？

26 | 作为程序员，你也应该聆听用户声音

 写留言

精选留言(21)

陈斯佳
2019-05-31
分享一个我现在每天在对自身进行复盘的方法。我每天会通过5个方面来分析过去的一天自己的学习成长。第1个方面是身体，也就是我的身体健康，其中包括运动，饮食，睡眠，还有冥想。因为好的身体，才是一切的动力来源。第2个的方面是关于认知和学习，其中包括比如像通过极客时间专栏的学习，对认知的提升，还有英语的学习和技术的学习。第3个方面是工作生活，工作主要是对前一天工作的总结，并且提炼出成就事件和需要改进的方面，生活主要吗，因为还单身，所以也没啥生活……这一块留给以后的家庭生活使用。第4个方面关系心理，也就是如何和自我相处，如何和他人相处，如何维持好的人际关系。最后一个是理财，也就是自己在理财知识方面的学习和一些理财实践。每天早上几乎都会在这5个方面进行一些复盘，我自己会把它形象化，想象出是5个部门的经理，自己就像是一个CEO一样，每天听取5个部门经理的汇报，其实感觉也挺有意思的。
展开
作者回复: 很赞的分享！
共 5 条评论
116
西西弗与卡夫卡
2019-03-01
关于复盘，孙陶然曾经说过，如果他有所成就，一半要归功于复盘。他提出了几个步骤供大家参考。首先，先对比实际结果和期初所定目标之间有什么差距。其次，情景再现，回顾项目的几个阶段。然后，对每个阶段进行得失分析，找出问题原因。最后，总结规律，化作自己的技能沉淀，再次遇到时可以规避。我再补充一点，复盘资料应该记录到知识库，无论新来的或是接手的人，都能从中获益，从而提升组织的能力。另外，好的复盘需要有坦诚的文化氛围，不然有可能变成互相指责甩锅，就失去了意义
展开
作者回复: 补充得非常好，一些能够形成体系的知识要积累下来。
共 3 条评论
47
helloworld
2019-04-25
复盘是为了找出问题的所在，而不是为了责备别人
作者回复: 找到重点了。
16
wuhulala
2020-03-19
尤其是做产品，一味的勇往直前有可能就是闭门造车，需要时不时的停下来回顾复盘，最近感觉这样确实会让思路更清晰，目标更明确。
作者回复: 内部问题靠回顾，外部问题靠反馈。
9
薄荷点点
2019-03-01
复盘是不是最好是团队内部进行，每次老板参加复盘，好像就没人说出真话了。
作者回复: 篇幅原因，我省略这个部分，其实，最好先做一轮安全性投票，如果大家觉得不安全，可以把老板请出去。
共 2 条评论
7
happysun
2020-03-21
团队开发成员较少，没有技术大拿，有些根源上、方向上的问题没有找到最佳的解决方案，限于条件所限，只能是折中性的临时解决方案，因为这个原因所导致的同类问题一再重复出现，这个现象如何破解？企业内部自身使用的管理系统，技术架构规划的，不够理想，但目前的产品还需要持续用下去。
作者回复: 没有明白人，就只能大家一起糊涂。学了这个课，你多做点事，你就是明白人。
5
陈斯佳
2019-08-15
复盘一下今天出现的问题。今天大部分时间都花在了shell脚本的修改上。用五个Why来提问。为什么要花那么多时间？因为不是我写的脚本，需要熟悉时间，还有大部分时间是跑Jenkins测试这个脚本的时间。为什么要用Jenkins跑这个简单的脚本，而不是直接运行脚本？好问题，明天可以尝试一下这样做，就可以缩短反馈排bug的时间了
作者回复: 一步一步前进。
3
布衣骇客
2019-03-01
有类似复盘的思想，把每次出现问题记录，然后再讨论，只不过，讨论的是一个有点类似于问题库那种。把有过相似或者有联系的问题会再提出来，问题会分类，分类之后归档，问题与问题之间的有联系的了，就会有更多警觉
作者回复: 积累是很重要的，但一定要有行动项，保证问题不只是归档，也被解决了。
4
阿智
2019-03-01
其实，就是复盘如何落地。水土不服是很常见的
作者回复: 重点是你的团队想不想复盘。如果想，你会想办法复盘，如果不想，你会找各种借口不做。
4
rocedu
2021-02-05
http://gk.link/a/10oAq 极客时间出了一门复盘的课
作者回复: 很好的补充
2
pyhhou
2019-03-11
感谢老师的分享，复盘很有必要，不仅可以记录过去的失误点，还可以对当下的问题提供一个比较好的借鉴方案；还有就是 5 Whys 确实是一个找问题根因的方法，当然个人觉得这里找问题根因还是需要整个团队的参与，因为做的东西不一样，能力、经验不一样，看问题的角度也不一样，可能会出现，对于同样出现的问题，一个人用 5 Whys 找出来的根因和另外一个人用 5 Whys 找出来的根因不太一样，这就需要整个团队复盘讨论总结归纳问题的原因和解决方案
展开
作者回复: 沟通反馈，一个重点就是不能自己玩。
2
Bumblebee
2022-05-28
分享一下，不知道我的观点对不对，希望老师指点一下如果复盘涉及多方岗位的人，分析问题问为什么时，涉及岗位领域知识的时候最后是由相关岗位的负责人来问，比较合适；因为目前我们团队我就发现一个问题，在复盘的时候一些技术问题，产品那边不懂然后抓着一顿为什么问开发人员，弄的开发人员很反感，认为他们是在钻牛角尖，不屑于回答；
展开
1
ifelse
2022-04-21
定期复盘，最佳实践:回顾会议;找到根因，最佳实践:5个为什么。
1
Mister.张
2022-10-15 来自海南
我们做项目开发的时候，复盘分类为“整体情况、优点、缺点、继续做、停止做、开始做(行动项)”
wanghao
2022-08-20 来自湖南
柳传志的复盘故事，还是不要讲了
易轻尘
2022-06-18
这个可以加入每个星期的个人review中
邓嘉文
2022-06-08
要做复盘记录: 问题, 问题出现的本质原因, 问题等级
Rorchachl
2021-03-04
回顾回忆模板做的好的做的欠佳的问题和建议继续保持开始做停止做多做一些少做一些分析问题造成的原因给出行动项 (解决方案) 所有解决方案都是可以检测的比如控制工作量怎么检查呢看看每一阶段的工作量是否比上一阶段少找负责人我们的目标是不断的改进而不是责怪某个人
展开
作者回复: 很好的总结
汪玉斌
2020-06-12
感谢老师, 复盘真的是很好的方式. 但有个前提, 就是工作中要有必要的日志记录, 否则复盘时发现很多问题已经记不得或者记不准确了.
作者回复: 所以，复盘要在一个周期内，比如，两周，时间短才能对发生的事情有记忆。
Matthew Chen
2020-05-30
关于回顾会的执行，我学到了大概的步骤：问卷、统计、溯源、整改、负责。

