背景
团队采用敏捷开发已经一年时间了，刚开始半年随着团队成员之间的磨合以及技术的熟悉，开发的效率确实逐渐在提升，所以自认为团队上路了只会原来越好，谁想到后面团队没有进步，反而退步得厉害。
一、何时发现产品质量这个问题？
在指导对接监管平台的过程中突然发现产品质量已经下降得如此厉害，随便列出几项：
- 1）监管平台导入频次、用法、剂型、诊断等字典数据都没有验证一下程序，后面一跑流程很多功能都用不了。
- 2）上传到监管平台的科室、医生、病人、病历、处方、诊断都没有关联起来，没有人提出这个问题。
- 3）产品封版迭代中，尽然一下冒出140多个BUG。
总结：产品一定把关故事质量，SM把关技术质量，一起合作细化故事的验收条件。测试用例一定要覆盖全面。
二、分析造成这种现象的原因？
1、团队产品质量下降的过程
- 1）每个人都有偷懒的心态，能简单完成，肯定不会花太多时间去深入思考。这时候如果SM没有及时发现并纠正过来，这时候就出现一个破窗户，一段时间下来基本上整个街道的窗户都会出现破损。大家就这样养成了偷工减料的习惯。
- 2）本来测试是把控质量这道关，但是随着这种低级的BUG越来越多，大量占用了他的时间，那他肯定也就慢慢降低了对质量的要求。
- 3）然后就团队一起拿这个质量来应付产品经理，产品经理也没有办法了。
2、初步分析解决方案
- 1）靠外部力量来改变或者加强监督，不是好办法，最好的办法自己找到自己的问题，以及自己的解决方案。
- 2）收集数据，定义好质量的标准，形成制度。
- 3）《BUG分析总结会议》
- 4）《绩效扣分加分制度》
- 5）《每月一次的绩效面谈与签字》
三、解决过程
1）组织团队PO、SM会议，提出团队问题，讨论结果：
- 1、定期组织产品培训、产品规划、技术培训，产品培训由测试主讲，产品规划由PO主讲，技术培训由SM主持。
- 2、SM对于设计把关一定要当担起责任，一定要识别出那些负责设计，影响面广的设计，组织讨论要评审后才能做。另外调动起团队参与设计评审的积极性，这样才能识别出更多的设计问题。
2）参加团队早会，提出新的早会制度
规范每日站会的流程
- 1、大家讲
三句话，昨天做了什么，今天准备做什么，有什么难点；大家围成一圈顺时针轮流讲，讲的时候不需要看电脑；有难点先不讨论只是提出来；
- 2、SM提问
大家讲完后，SM针对看板上延期的故事和任务提问，一定要找到延期的原因和解决办法。
- 3、会后难点讨论
最后，有难点的成员留下来讨论一下，找出解决办法。
3）参加团队迭代总结会议，重点总结了产品质量产生的原因
- 1、需求反复
- 2、开发不熟悉不是自己编写的那块代码或业务，在不熟悉的代码上增加新功能导致产生很多bug
- 3、测试在迭代中覆盖不全面，加强自动化测试，分析bug产生原因，反过来要求开发提升
- 4、态度问题，不是自己的事情不做自己的任务不考虑细致深入，应付式的完成，包括开发测试都这样
- 5、开发分析问题要找到根本原因，而不是直接打个补丁。
4）组织BUG分析总结会议，重新定义BUG分类
- 1、开发不应该犯的BUG
- 粗心大意
- 逻辑不严谨
- 反复出现
- 2、值得总结的BUG
- 设计不合理
- 业务不熟悉
- 经验不足
5）绩效面谈与签字
- 1、扣分加分明细表
- 2、绩效表签字
- 3、意见反馈收集
##四、总结
根据这段时间的观察和改进，总结出3点来提升我们团队的产品质量；
1、收集数据，所有的问题都要进禅道管理，并对这些问题进行分类。
2、BUG分析总结会，每个迭代后，有测试组织对本次迭代中产生的BUG进行分析与总结，提出改进建议。
3、绩效面谈与签字，月底SM跟团队每个人进行绩效面谈，包括本月员工取得的成绩、优点与不足、改进措施。
附件：
1、绩效扣分加分制度：
1、迭代故事没有完成扣绩效
2、迭代后bug没有处理完成扣绩效
3、代码评审发现问题扣绩效
4、每次迭代之后进行一次产品演示，发现问题扣绩效，开发测试都扣
5、迭代之星加绩效
6、给团队培训加绩效
7、热心为团队做了技术服务加绩效
8、主动发现产品问题并登记进禅道加绩效
2、日常注意事项：
A、早会上不要讲一些很空洞的问题，不要等他们自己解决，要把问题具体化，并找到解决方案。
B、测试所有问题要登禅道，除了发群里，这样今天没有解决的bug在明天早会上过，并给出解决方案。
C、一个团队是否优秀主要看SM，所以SM不要承担太多的杂活，可以培养一个开发分担这些技术杂活。
3、文档：互联网医院迭代17产生BUG分析.note
4、互联网医院团队绩效分数统计
原文出处：https://www.cnblogs.com/kakake/p/11144488.html
来源：oschina
链接：https://my.oschina.net/u/4298822/blog/3259832