如何影响开发人员的错误优先级并相应地加以对待？

我们正在执行一个错误流程。

我们有3个错误级别：

P1错误：阻止用户工作的错误。他们必须当场解决。
P2错误：有影响但用户可以使用的错误
P3错误：不会影响用户并可以在其中工作的错误。

P1是强制性的，必须当场处理。但是对于P2和P3，我们将根据具体情况进行判断。

我们拥有3个级别，因此团队倾向于根据客户的要求进行更紧迫的新开发，而不必处理P2和P3，这几乎很紧急。

问题如下：

我是否应该添加另一个优先级，例如拥有P4？

我是否还应该像本周一样为他们指定处理非紧急票证的目标，当不分配编码任务时，您应至少处理1个P2？

当前，我们没有像我上面提出的目标，但是我担心的是给他们这样的目标可能是残酷的。可以确定的是，我需要与他们讨论目标，团队喜欢参与讨论，尤其是在设定目标时。

更新：

我从相似性的角度提出了这个问题。但是，它根本不相似。

我的问题是如何让人们处理错误，而又不施加严格的议程却仍要解决它。因此，不，所隐含的问题对我没有帮助。不过还是谢谢你

agile debugging issue-tracking

— 安迪·K
source

我

— gnat

通常优先级级别不如优先级排序有用。“错误X”比“错误Y”更重要。如果最终添加了p4，则将需要p5和p3.5

— sudo rm -rf斜杠

如果您有太多的P1错误，以至于所有开发人员都在忙于修复它们，而不是在P2 / P3上工作，那么您所做的事情是非常错误的。暂时不要添加任何其他功能。专注于深入研究和修复几乎可以肯定会导致许多错误的体系结构（或人员）问题。例如，如果您使用C ++进行编码，请确保在任何可能的地方都使用RAII，这样您就不会忘记手动进行操作.release()。

— 基金莫妮卡的诉讼

你的目标是什么？您是否希望开发人员在错误修复方面投入更多精力，而在新功能方面投入更少的精力？请编辑您的问题以澄清。另外，请描述开发人员目前如何接收或从事工作？用什么来决定要做什么？

— sleske '18

功能，错误，更改您所谓的名称，该软件无法执行所需的操作。错误和功能之间的唯一区别是谁付费。

— mattnz '18

Answers:

通常，您有两个bug轴：重力和频率。

因此，显而易见的是，最重要的事情是频繁而严肃的事情。但是，严重但很少发生的事情应该与不严重但经常发生的事情大致权衡。因此，假设您将重力从1到3以及频率从1到3进行评级，那么您可能应该修复的错误类型是与由重力1，频率3和重力3，频率1定义的对角线交叉的错误。

阻塞错误或可能对客户信息造成潜在损害的错误始终是重力3。类似地，重力1的错误不太可能会被用户注意到或具有较低的优先级。如果您不确定此处是否为2，可能是一个安全的数字。

用户每次启动程序时看到的错误的发生频率均为3。如果发生频率为1的错误，则几乎不会发生。同样，如果您不确定，则2可能是一个安全的数字。

对于重力3或频率3的错误，它的构成主要是主观的，但请使用常识。重力1，频率2的错误可能是拼写错误的标签。当数据库连接断开时，重力为2（频率为1）的错误可能是正确的错误处理。

再说一次，这只是一个粗略的想法，但是这个想法是要强调将漏洞修复作为一种分类进行研究的重点。显然，不可能消除所有的，以其他方式阻止的错误，尽管至少使用这种方法，您可以放心地说，错误不是太紧迫也不是太频繁。如果您只修复了阻止错误的错误，那么高频错误将被忽略，用户会注意到您没有修复这些错误。

另外，为方便起见，您可能会发现您更愿意提供重力或频率的字母等级，因此您可以说错误是B3错误，并且重力和频率都很清楚。

祝好运！

— 尼尔
source

实际上，漏洞的衡量标准只有一个-投资回报率（ROI）-与不修复漏洞造成的损失相比，修复费用是多少。将其与功能进行比较。当然，如何计算该指标涉及重力，频率等

— 。– corsiKa

@corsiKa，是的，ROI是一个综合指标：“回报”和“投资”。对于错误，返回可以建模为“重力”和“频率”的组合。

— 保罗·德雷珀

@corsiKa，那种对质量决策的冷血自私的分析实际上是极不负责任的。正是这种逻辑导致制药公司绕开功效测试法，如果它们可以“逃脱”，或尽管不利影响的严重性和频发性将获利的药物保留在市场上。正是这种不负责任的态度导致了由不安全的消费路由器和“智能”设备组成的庞大僵尸网络，因为制造商看不到任何具有良好安全性的价值。重力和频率比“底线影响”要好得多。

— 通配符'18

@Wildcard我实际上是共产党员，所以我100％同意您的观点，那就更好。但这并不能改变这样一个事实，那就是软件公司的运营方式，如果不经营该公司，那么与之相反的潮流将淹死您。尽管值得注意，但这不是自私的。它是单人服务，但那不是个人，而是公司。把它丢去外面。

— corsiKa '18

@Wildcard和corsiKa这家公司不是一个大公司，我们不能说“哦，我们要赔钱了，那我们就做些事吧，否则就让它保持现状”。但是，从总体上看，我认为您提到的方法从长远来看是不可持续的。人员-客户远非愚蠢。一直在宣扬这种福音的公司Sun不在这里。我从事帐户管理工作已经足够长的时间了，以至于钱不是那样赚来的。对于任何人，如果您碰巧在该公司缺乏忠诚度的公司工作1 / n

— Andy K

这实际上归结为您认为更重要的内容。是P2错误还是新功能？

通常，敏捷项目管理系统将包括某种优先级会议，任务按优先级排序并按该顺序进行。

不允许开发人员选择他们从事的工作。那是项目经理的工作。在预算用尽之前，谁必须确保项目具有尽可能多的重要功能。

这确实是最重要的。简单的规则（例如“每周至少修复1个P2”）并不能真正帮助实现此目标。

— 伊万
source

分配优先级的麻烦在于，无论您选择哪种存储桶粒度，最终每个存储桶都会有多个。您需要将事情整理好，而不仅仅是说“所有这些都是最重要的！”

— 伊万

@Ewan还有优先级膨胀的可能性，其中最高级别的存储桶比您希望解决的问题更多，并且在错误跟踪系统之外发明了新的优先级。我听说有人说P减2问题。

— kasperd

说不允许开发人员选择他们从事的工作会损害您的生产力。如果开发人员在他们正在处理的最高优先级问题上受阻，最好是他们可以同时处理另一个问题，而不是在他们的第一个问题受阻时不做任何事情。而且，那些不会损害用户但损害开发人员生产力的问题通常没有得到应有的重视。最后，告诉开发人员不允许他们自己做决定是一种消除动力的可靠方法。

— kasperd

@kasperd我认为大多数开发人员都接受他们既是雇员又是技术天才，并接受其雇主决定应该先完成哪些任务。显然，如果某个任务被阻止，您将移至下一个最重要的任务，但是您不会跳过10个重要任务来处理很酷的任务。

— 伊万

我发现，如果工作完成或受阻，则应该优先处理bug，而不是将其他开发任务拖入sprint（做scrum）。众所周知，MS 在Windows 2000上将所有程序的错误置于所有开发任务的最高优先位置–他们发现这是生产非Buggy软件的最佳方法（这是2000年实际上受到人们欢迎的原因之一），就像他们没有这样做一样。，错误通常会遗留下来，因为通常需要进行一些新的开发。

— Baldrickk '18年

对于一个软件来说，堆积非关键的错误直到某个东西出现，这是一个非常普遍的循环，然后发生一个大事件，并且许多错误一次被修复。可能是通过在一个大的新版本发布之前将一两个Sprint专门用于错误修复，或者是因为软件为EOL并幸免于堆错误。

因此，如果您的开发人员只是让他们滑下来，那么您就在公司中。当然，您可以像您提到的那样“玩弄”规则（“如果您不使用新功能，则必须每周至少使用一个P2”），但这可能只会使您不受欢迎。

我的问题是如何让人们处理错误，而又不施加严格的议程却仍要解决它。

相反，我建议稍微改变整体思维方式，使错误更像功能，因为它们是您积压的第一等公民。是的，新功能很棒。是的，管理和销售对新功能的要求很高。但是拥有一个稳定，运行良好的应用程序而不是一大堆混乱的bug也很重要。

不要告诉您的开发人员他们必须做他们不喜欢的工作；但是请尝试改变气氛，以便他们喜欢研究错误。尝试在无错误的应用程序中树立自豪感。通过专门允许他们来实际解决使该错误得以体现的根本原因（即，不仅仅是快速的解决方法/ hack）（如果有的话），使他们更有趣（原文如此）。剔除一些坏掉的类结构，并用更合适的类替换它对于开发人员来说可能非常有趣。如果您的中央部分坏了，经常使错误在其他地方显示，请修复中央部分。

如何达到目标很大程度上取决于您自己和团队的性格-不要试图愚弄他们要实现的目标，而要进行公开讨论，尝试使同伴效应发挥作用，让他们提出来自己的工作过程，等等。

— no
source