将生产力提高到每人每天1次修正

时间:2009-03-31 04:42:40

标签: project-management bug-tracking maintenance

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

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

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

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

  • 我试图反对使用错误修正后的生产力指标,这种方法并没有太过分
  • 所有错误都被优先处理(1-5),包括严重性(1-5)并标记有其他信息(例如,被另一个错误阻止,崩溃,不可再生等)
  • 大多数错误都会在纠正时编写单元测试用例
  • 代码区域中的错误会分配给熟悉该区域的人员(如果可能)
  • 根据每个团队跟踪错误更正率,并保留更正历史记录
  • 在日常站立中我试图通过询问阻塞问题和解决问题来让人们感动
  • 所有新代码都是用单元测试编写的
  • 是的,我一直在尽最大努力通过各种方式提高生产力指标 - 关闭旧的不相关错误,创建和纠正错误,否则将在没有错误报告的情况下解决问题
  • 我开发了python脚本,可以直接访问bug数据库,自动化bug管理和报告创建的一些普通方面

  • -

4 个答案:

答案 0 :(得分:3)

虽然在某些情况下,错误更正率是一个有效的指标,但在其他情况下,它们可能会误入歧途。有些错误显然比其他错误要难得多。

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

在敏捷环境中,您主要专注于编写测试代码。想想他生命周期中的一个bug。你尝试做的第一件事就是重现它。如果您可以针对它编写测试用例,则可以测量修复错误的程度。这样做可以提高错误修正率。

答案 1 :(得分:3)

我认为一个好的起点是将bug修复过程系统化。如果你在<1个错误/天,我假设你的代码库很大,这些错误很难找到/重现。我先从一些分析开始

1)了解错误需要多长时间

2)找到/复制多长时间

3)修复了哪些代码(这里有模式)

4)修复时,是否添加了另一个单元测试

5)你是否评估了发生错误的个人和团队

这样做几周会给你一个很好的未来方向基础。这也是您的经理应该购买的专业方法。

答案 2 :(得分:0)

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

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

根据上述海报,让有经验的开发人员编写测试用例以进行增强。 (当然,这会使错误修复更加困难)

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

答案 3 :(得分:0)

您可以询问开发人员他们的意见是错误修复周期中最耗时的部分,并考虑如何使用此信息。

他们正在做实际的工作,他们掌握瓶颈的最多信息是合理的。