【无标题】

2022年7月13日下午3点到5点，我作为外部咨询顾问旁观了一个项目的迭代总结会议，在项目组总结结束以后，发表了自己的感想如下：

1 在项目组中通过Confluence进行了经验教训分享，值得提倡！应该坚持住，继续推广。

学习型的组织就是要从历史中吸取经验教训，将经验教训的价值最大化，持续提升，快速提升。

2 在优秀个人评选中，优秀个人都是积极和其他人进行协同的人，很好，在团队内就是要建立起协同的文化。每个人每天回顾时可以反思：我今天给别人提供了什么帮助？

3 在优秀个人评选中，有个指标：加班时长，很有意思。对于初创的公司、初创的团队，评价一个团队是否有战斗力的朴素指标就是：能不能打攻坚战！遇到问题了，可能就是需要加班，就是需要快速响应，我们有团队在晚上10点到公司来解决软件问题，急用户所急，很好，很有责任心。我们也要思考，我们有无办法减少加班频率与时长，保持平稳的开发速度。

4 在我们最近的迭代中，我们完成了29个需求，解决了744个缺陷，我们是需求驱动的开发，还是缺陷驱动的开发呢？这是我们要思考的。需求驱动、缺陷驱动、技术债务驱动、沟通驱动、文档驱动都是一种开发模式，适用于产品的不同成熟阶段，但是我们需要思考，我们如何更健康地开发，进入一个良性循环。

5  在我们的开发模式中，在上一个迭代澄清了下一个迭代的需求，进行了下一个迭代的技术预研，这很好，我们可以称为侦察兵模式，由侦察兵先完成了探路，扫清了地雷，这样下一个迭代就尽在掌握之中，没有技术障碍了。

6 在修改缺陷的时候，要避免注入新的缺陷，我们的措施是什么？曾经有客户采用结对修改的模式做缺陷的修改，可以尝试一下。这样可以把注入新缺陷的概率减低到10%以下。

7 出了问题以后，要找技术方法、管理方法规避问题的再次发生，而不是追究个人的责任。 本迭代中我们有个案例，当发现问题后，产品经理召集大家定位问题，分析原因，很好！我们要积极地解决问题，而不是追究责任，在团队中传递正能量。

8 我们有个优秀成员，是测试人员，1个人月发现了105个缺陷，这是一个了不起的数字。我们可以度量本次迭代我们累计发现了多少个缺陷，我们一共投入了多少人月发现这些缺陷，每个缺陷的发现成本有多少元？把这个数字统计出来、公布出来，对我们的开发人员会有所触动，我们开发人员就知道内建质量有多重要了，我们一天犯一个错误，可能就需要测试人员花一天的时间去发现它，成本太高了。

9 我们已经用Sonar在扫描代码了，这很好，要养成习惯，要坚持。Sonar扫描发现缺陷的成本远远低于通过代码评审和测试发现缺陷，我们有什么理由不去做静态扫描、不去修改缺陷呢？Sonar的分析报告中有很多数据，从这些数据中我们还以找到其他管理结论。每个开发人员如果每个月记录了自己静态扫描的数据，也可以通过这些数据分析自己开发的代码质量是否有所提升，每个月是否在进步。

10 对于我们发现的缺陷，我们可以做原因分布分析、类型分布分析，利用80-20原则找到关键的少数，实施改进。

11 对于我们实施的代码走查措施，为了固化下来成为习惯，建议每周或每天固定时间进行，比如每周五下午定义为质量日，到了周五下午就联调、做代码走查，或者每天下午下班之前最后一个小时进行代码走查。

以上意见仅供参考，大家可以斟酌吸取之。
————————————————
版权声明：本文为CSDN博主「麦哲思科技任甲林」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dylanren/article/details/125769092