精准排查故障响应慢的项目
从收到缺陷报告或线上事故警报开始,到问题解决,需要多长时间?迟迟无法解决的故障会损害用户使用体验,公司的业务也可能因此蒙受损失。
DevInsight 提供事故/缺陷密度和响应时间的跨项目对比,帮助研发团队筛选出问题多、修复难度大的项目,进一步结合项目属性和历史趋势分析原因。
![](https://cdn.prod.website-files.com/6111eecb5937a432dabc3df4/64588188aae4644d97fc9234_asynccode.png)
下钻定位难以修复的故障
研发团队需要在故障修复上投入多少工作量?这一指标说明了代码的可维护性。
DevInsight 用箱线图直观展示修复工作量的分布。图中的异常点代表缺陷/事故的需要需要大量编码工作,可能反映该缺陷波及面较广,建议补充注释和测试,拆分复杂函数;图中的箱体则代表该项目中故障修复的普遍工作量,如果箱体偏高,可能反映该项目未能达到高内聚低耦合,常常导致联动修改。
![](https://cdn.prod.website-files.com/6111eecb5937a432dabc3df4/64588189645ec63cf7fdd53c_asynccode.png)
度量“救火”负荷,为新特性开发争取宝贵时间
研发团队在故障修复上投入的工作量,在总工作量中占比多少?这一指标说明了研发人力成本在不同类型事务上的分布情况。
如果占比偏高,则团队可能正在“焦油坑”中挣扎——大量时间被紧急的事故/缺陷挤占,团队成员忙着救火,新特性新功能的交付只能一再拖延。
研发团队可以针对修复工作量占比异常偏高的项目进行复盘,并采取“质量改进月”等实践,帮助研发团队减轻技术债包袱,轻装上阵。
![](https://cdn.prod.website-files.com/6111eecb5937a432dabc3df4/645881892bbaac462c943d4a_asynccode.png)