4

我是一名高级软件工程师，几个月前我被要求帮助协调错误更正。项目经理（非技术人员）给了我一个目标，将生产力提高到每人/天 1 个错误修正。这是一个真正的挑战，我想知道其他开发人员/经理可能会采取哪些措施来提高错误纠正率。

在这种情况下起作用的一些因素：

  • 团队地理分布（欧洲、亚洲、澳大利亚），每个区域有 10-20 名开发人员
  • 大型代码库，我不太熟悉，因为我在公司只工作了 9 个月
  • 只有最缺乏经验的开发人员被分配到错误更正，最有能力的开发人员正在致力于改进
  • 我们遵循敏捷，所以我们使用源代码控制、持续集成、错误数据库，项目有新工作的时间表和规范，我们有测试人员并进行可用性测试
  • 我们的代码依赖于许多内部和第三方组件/库
  • 项目经理有一些旧的错误纠正指标，显示每人/天纠正 0.7 个错误。我担心的是，这是基于一组经验丰富的开发人员开发原型，纠正他们自己编写的代码中的错误。现在我正在协调一个不熟悉代码的开发人员团队，并且错误来自验证团队。

阅读前几个答案后的更多信息：

  • 我试图反对使用错误纠正的生产力指标，但这种方法并没有走得太远
  • 所有错误都按优先级排序 (1-5)，包括严重性 (1-5) 并标记有其他信息（例如，被另一个错误阻止、崩溃、不可重现等）
  • 大多数错误在纠正时都会编写单元测试用例
  • 如果可能，将特定代码区域中的错误分配给熟悉该区域的人员
  • 按团队跟踪错误纠正率，并保留纠正历史记录
  • 在日常站立会议中，我试图通过要求阻止问题并解决它们来让人们感动
  • 所有新代码都是用单元测试编写的
  • 是的，我一直在尽我最大的努力通过各种方式提高生产力指标——关闭旧的不相关的错误，创建和纠正错误，否则这些问题将在没有错误报告的情况下解决

  • 我已经开发了直接访问 bug 数据库的 python 脚本，以自动化 bug 管理和报告创建的一些平凡方面

    • -
4

4 回答 4

3

虽然错误纠正率在某些情况下是一个有效的指标，但在其他情况下它们可能会产生误导。有些错误显然比其他错误更难修复。

您可能想尝试的想法包括将错误分类到不同的类别。基于诸如修复难度、对客户的重要性或复杂性等指标进行排序。

在敏捷环境中，您主要专注于编写测试代码。想想他的一个bug的生命周期。您尝试做的第一件事就是复制它。如果您可以针对它编写一个测试用例，您就可以衡量您在修复错误方面的进展情况。这样做将提高错误纠正率。

于 2009-03-31T04:51:35.257 回答
3

我认为一个好的起点是将错误修复过程系统化。如果您每天的 bug 少于 1，我假设您的代码库很大，并且这些 bug 很难找到/重现。我将从一些分析开始

1) 多长时间了解 bug

2) 找到/复制多长时间

3) 修复了哪些代码（这里有模式吗）

4）修复时，是否添加另一个单元测试

5) 你是否审查发生错误的个人和团队

几个星期这样做将为您提供未来方向的非常好的基础。这也是你的经理应该接受的一种专业方法。

于 2009-03-31T04:55:21.830 回答
0

在修复错误的经验丰富的开发人员和创建增强功能的初级开发人员之间切换会很有帮助，但这在您的情况下听起来是不可能的。

尽量不要让人们陷入困境。如果有人遇到问题并且无处可去，请鼓励他们寻求帮助并走上正确的道路。

根据上面的海报，让经验丰富的开发人员编写测试用例以进行增强。（当然，这使得修复错误变得更加困难）

您总是可以故意添加错误并修复它们。

于 2009-03-31T04:59:48.950 回答
0

您可以询问开发人员他们认为错误修复周期中最耗时的部分是什么，并思考如何使用这些信息。

他们正在做实际的工作，他们拥有关于瓶颈是什么的最多信息是合理的。

于 2009-03-31T05:03:28.817 回答