先说我们的
不管多严重 如果原因是因为什么校验什么枚举判断错误之类 先数落你 怎么能犯这么低级的错误
如果是你手下人写的 就数落你 为什么不给手下 review 代码
如果 是外部业务因素导致的 比如 用户的等级千奇百怪 开发根本完全不了解没有兼容到 就说落你为什么没有想到或者单测覆盖到?
好奇别的别的团队出现小 bug 和大 bug 团队都是怎么对待的 ?
是不管问题大小 先数落一遍开发
还是按不同问题严重性,不同对待的
还是 谁没写过 bug 宽容对待的
1
wangkun025 2020-11-28 14:46:32 +08:00 5
我们对待错误比较宽容,可能因为老板很懂,或者老板完全不懂(有敬畏之心)。
其实这个问题挺简单的。 首先是需求问题。 其次是测试问题。 最后才是开发。 如果 BUG 是没考虑到的,就是需求的问题。 如果 BUG 涉及的需求在文档里,测试没测出来,就是测试的问题。 如果需求提出了功能,但开发实现不了,但别人家的开发能实现,才是开发的问题。 换个角度看,BUG 其实跟开发一毛线关系都没有。 |
2
HariopaNic 2020-11-28 14:47:30 +08:00 via iPhone
遇到 bug 首先解决问题,解决完说一下原因,比较低级的就说下次注意一下。
|
3
hoyixi 2020-11-28 15:03:08 +08:00
1 楼兄弟,很粗暴啊,是不是从来没写过单元测试
|
4
wangkun025 2020-11-28 15:15:05 +08:00
@hoyixi 写过。分担责任嘛。只折磨开发,有意思吗?
|
5
yuhuan66666 OP @hoyixi #3 说起单元测试 ,我们基本出了 bug 就 数落开发 单元测试没写或者单元测试覆盖度不够
|
6
hoyixi 2020-11-28 15:25:47 +08:00 1
@wangkun025 #4
同意,不过,不管谁的问题,最后 bug 都还是开发改啊,哈哈 bug 一出,先定位打击人群,类似楼主提的”数落一遍开发”,甚至还有扣钱的, 感觉这是中国软件作坊特征之一。 出 bug 多正常的事,按照流程该干嘛干嘛,迭代就是了。可能很多公司连像样的“流程”都没有,只能让各部门内斗了。 这现象不光 IT 业有,类似现象本质,感觉就是领导无能,于是为了显得自己永远对,就让下面部门或者人员互斗~ |
7
yuhuan66666 OP @wangkun025 #1 我上面 和 上面的上面都是开发干过来,但是我不知道他们是什么心理 都喜欢从自己下属找毛病,出了问题先怪自己下属,外部问题也能怪到自己下属身上,什么 为什么提前没沟通,为什么单元测试没覆盖到,为什么开发阶段没了解过这个问题
|
8
yuhuan66666 OP @wangkun025 #4 因为 是团队合作关系 开发团队 测试团队 产品团队 出了 bug 开发领导只能数落手底下开发,QA 和产品团队人家数落不到
|
9
bojackhorseman 2020-11-28 15:38:51 +08:00 via iPhone 1
反正发生什么不都是开发背锅🐴
|
10
XDy0 2020-11-28 15:43:56 +08:00
先解决问题,然后再找问题发生的原因。主要是我好像没出过什么大的 bug,所以也没被骂过,很多问题都是我自己发现自己解决的= =
|
11
yuhuan66666 OP @XDy0 #10 上线后 自己发现的吗? 那你观察总结的时间挺多的 我们开发完一个需求 立即下个需求开始 把敏捷开发中的 双周迭代 概念单独拿出来用
|
12
binux 2020-11-28 15:56:44 +08:00
|
13
wangkun025 2020-11-28 15:57:07 +08:00
|
14
007yxc 2020-11-28 15:57:45 +08:00 via iPhone
@wangkun025 ....你这逻辑 我很佩服
|
15
yuhuan66666 OP @wangkun025 #13 管理的手段就是 当出现一个问题数落完之后 问如何避免下次再出类似的问题, 然后又把问题推到了充分单元测试 提高单元测试覆盖程度 和 review 代码上
|
16
whypool 2020-11-28 16:32:13 +08:00
整个组背锅,然后影响年终奖
|
17
zerofancy 2020-11-28 16:39:06 +08:00 2
拿起手机,发现 iOS 那边也挂了,松了一口气。看来不是客户端的锅。
|
18
yuhuan66666 OP @whypool #16 小问题也这样么。。。。
|
19
boris93 2020-11-28 16:57:48 +08:00 via Android 1
首先受影响的人会来找我,告诉我出现什么问题了
确认后,后 JIRA 上开 bug 单 我按照紧急程度以及当前 sprint 的时间安排,决定是这个 sprint 修好,还是下个 sprint 再做 修完了,测试,上线 因为 bug 数落下属,只是发泄情绪而已,没啥实际用途。不如花心思在制定改进方案和落地上面。 |
20
leavic 2020-11-28 17:02:34 +08:00
谁写的 bug 拉出去祭天。
|
21
seki 2020-11-28 17:06:29 +08:00 1
对事不对人,是人都能写出 bug 来
对于今后的整改措施,是要从手段和方法上去避免和控制,因为人都会犯错,需要通过加静态检查,加测试来避免犯同样的错误 |
22
SjwNo1 2020-11-28 17:47:51 +08:00 via iPhone 1
好好反思,耗子尾汁
|
23
musi 2020-11-28 17:57:43 +08:00
是个开发多多少少都会写 bug 吧。。。真要说没 bug 那就是 no write, no bug
|
24
cheng6563 2020-11-28 20:08:58 +08:00
反正出事故都是开发的
赚大钱都是运营的 |
25
beidounanxizi 2020-11-28 20:15:51 +08:00
一楼说的很对啊 不会真的以为单元测试 就能做好吧
|
26
qiaobeier 2020-11-28 20:17:05 +08:00
1. 立即解决问题
2. 会议回顾问题 3. 扣责任人的奖金 |
27
frankkai 2020-11-28 20:43:39 +08:00
如果是走了一个完整的“开发->测试->验收->发布”的流程 因为是团队,所以理所应当大家一起背锅
|
28
akira 2020-11-28 21:01:24 +08:00
提交缺陷跟踪
根据紧急程度安排优先级 该谁改谁改 测试 上线 |
29
cabing 2020-11-28 22:37:11 +08:00
先修复 bug,非紧急情况下,再找写出 bug 的人,修复 bug 上线。
|
30
railgun 2020-11-28 23:00:40 +08:00
1 、补偿客户损失
2 、定位问题 3 、确定修复方案 4 、临时修复 5 、正式修复 6 、事故复盘 7 、修改发布流程,避免再犯 8 、确定责任、惩罚措施 |
31
dreamapple 2020-11-28 23:53:38 +08:00 via Android
运维报故障
写故障分析报告 定级 邮件通报 还没遇到被领导请喝茶的情况 |
32
nuk 2020-11-28 23:59:00 +08:00
1. 写 report
2. 能修就修 3. 修不好就甩锅 |
33
raaaaaar 2020-11-29 09:51:27 +08:00 via Android
楼上说得很好,我认为第一步应该是定位问题,解决问题,而不是一来就开始追责,那种领导最坑爹了,还有就是领导不会反思,不会开会大家一起思考,总结暴露出来的问题,虽然可能是开发的锅,但是通常都会暴露出开发流程的问题,但是有些领导根本不搞这些,就让你背锅,先把责任让你背着再说
|
34
yjxjn 2020-11-29 11:16:56 +08:00
1.提 ticket,报告问题
2.定位错误,调查 3.修改 BUG,做测试,测试没问题,MR |
35
wanguorui123 2020-11-29 21:24:55 +08:00 via iPhone
上线出现 bug,1 、定位问题和日志; 2 、看能否在线修复; 3 、无法修复立即回滚历史版本; 4 、无法回滚就立刻限制有问题的部分功能与发布公告; 5 、加班修复问题并发版
|
36
ydpro 2020-11-30 08:58:00 +08:00
出问题,改 bug,结束。
|
37
luozejian 2020-11-30 09:00:31 +08:00
忙着甩锅大部分人都是第一时间想到这个
|
38
yuhuan66666 OP @raaaaaar #33 更坑爹的是 会反思 但是反思出来都是开发的问题,都是因为开发没做某某控制,导致了 bug 。那解决办法呢,自然也是开发应该想到可能出现的问题,应该更全面的写单元测试。然后如果 开发需要 10 分钟写单测 10 小时,他就会觉得 你不够努力,为什么单测要那么久,既不想让开发占用工时写单测,又要求单测必须要全面。
|