我当前正在从事的项目存在一个问题：错误和任务通常分配给新手或经验不足的人，而他们的工作最终会产生更多错误。问题在于，由于代码质量问题，我们的软件某些部分比其他部分更“危险”地工作。我一直在通过估计与任务相关的风险并密切关注哪些开发人员被分配了哪些任务来解决此问题。
我们使用JIRA，因此我开始标记问题以跟踪此估计。我注意到我最终使用了多个指标来对错误/任务进行分类：
我的标签有点乱，因为当我开始时可能的类别是什么，但现在仍然不知道，我并不清楚。我正在考虑请求添加一个新字段（例如“风险”），以便我们可以在将工作分配给某人之前进行估算。
以前有人处理过这种事情吗？
Answers:
大多数错误跟踪方法的缺点之一是它们仅处理方程式的一部分-最终用户对系统的看法。这是要解决的一个关键错误，可以等待一个星期（优先级），而这个错误让它很痛苦，因为它是s一个多元化故障（严重性）。
描述多维错误跟踪的博客文章着眼于解决这个问题，包括开发人员视图：PEF和REV。
PEF值是用户视图：
REV方面从开发人员的角度来看：
这些指标均以1..9标尺进行测量，其中1为低/难，9为高/难。这些数字相加得出PEF和REV的分数。
解决所描述的位的部分：
- 它有多清晰/简单。例如，这是否需要大量的设计工作，还是仅需要简单的UI错误修复。
- 代码受影响区域的可维护性。是设计合理的区域还是大泥球。
- 我认为有多少程序会受到所需更改的影响。
这些因素影响REV中描述的工作量和风险。
是的，这是以前一直在努力的事情。（过去）我曾在Redmine中将此模型用于自定义字段，并且相当成功。
当您比较PEF和REV分数时，这将带来最大的好处。如果您的PEF为21，REV为7，那将是一个巨大的胜利。PEF为7，REV为21时，应该避免一会儿，因为风险和努力方面可能会超过解决它的好处。
然后，人们可以查看REV得分，并将低风险的东西分配给经验不足的开发人员（低风险，高努力通常是这种情况的理想选择）。
我想说的是，您所说的最好称为“复杂性”。当然，更改越复杂，“经验不足”的程序员可能会引入一些新的错误，因此“风险”就越高。如果这是一个实际问题，引入这样一个领域并不是一个坏主意。
但是，从您写的内容来看，您似乎有两个问题：
除了引入诸如“复杂性”字段之类的东西（这将有助于管理工作并确定工作的优先级）之外，我建议您将重点放在降低上述两个问题的风险上。
为了解决第一个问题，我将创建一个过程，在该过程中，新程序员将首先与经验丰富的程序员讨论所有新的bug，然后再处理该bug。另外，我肯定会引入代码审查，以降低引入新错误的风险，并作为新程序员更快入门的指导机会。
关于代码质量，我将做两件事。首先，停止腐烂过程：就编码标准和实践达成共识，以防止引入任何新的劣等代码。建议的代码审查也将在这里提供帮助。其次，我将确定代码中最糟糕的部分，并开始进行重构和清理。