缺陷报告及缺陷生命周期_报告缺陷时突出显示风险

缺陷报告及缺陷生命周期

读者问我这个问题：

“如何报告我们系统中的1000个左右的缺陷？ 我有10分钟的状态通话时间。”

如果您正在使用一个遗留应用程序，而该团队由于多种原因无法保持卓越的技术，则可能会遇到这样的问题。 如此多的缺陷，很少的时间来讨论。

让我们来看一下状态报告问题。 您可以报告缺陷趋势：上周打开数量，关闭数量和剩余数量。 请参阅《我们还在那里吗？》中的图8 。 该图表（以及页面上的大多数图表）用于项目团队，而非管理层。

当经理想要了解缺陷状态时，他们实际上想要这些问题的答案，即缺陷的影响：

• 这个问题会影响客户对产品的看法，是否足以使他们不购买或推荐该产品？
• 这个问题会影响我们的收入能力吗？
• 这个问题会影响我们留住或吸引客户的能力吗？

如果您可以将问题作为这些问题的答案，则可以在10分钟（或更短的时间内）内提供合理的状态。

以下是这在四种情况下的工作方式：

方案1：您有数百种错别字，屏幕不一致和普遍松懈。 您认为团队应该修复所有这些问题，甚至可能要花几个星期才能解决。 您说的是这样的：

“我们有x个问题，这些问题本身都不是真正的问题。 但是，当我们将它们放在一起时，客户似乎会对我们不一致的外观感到担忧。 我们可以忍受吗？ 也许。 我担心客户愿意成为参考客户，甚至让他们寻找其他选择。”

方案2：您有两个可怕的问题，而且很少发生。 发生的结果是客户数据完全丢失。 您认为您不应该将产品置于这些问题附近，即使它们很少发生。 这就是你说的：

除了许多小问题，我们还有两个大问题。 我将重点讨论问题1和2。如果客户遇到这些问题之一，他们将丢失其数据。 我们无法恢复数据。 他们会很生气。 可能的结果是这些客户的收入损失，更糟糕的是，可能的评论使其他人知道了我们的问题。”

场景3：您和您的同伴正在向敏捷过渡。 您有构建和测试自动化债务，因为构建需要几个小时，并且没有足够的自动化测试。 您担心测试不够，即使团队将一切标记为已完成。 您可以尝试如下操作：

“在这些领域（您的测试自动化不足的地方），我们面临未知的风险。 是的，我们将这些区域中的功能标记为已完成，并且我们不知道自己所不知道的。 未知的风险有造成问题的习惯。 （提醒他们最近一次发生的情况。）我建议我们将其作为Beta版本发布，并在接下来的两周中花费大量时间进行测试自动化的积压工作，并缩短构建时间，以便我们更快地了解实际情况。 这样，我们在获取或保留客户方面就没有问题。 而且，我们不会因数据丢失而导致潜在的客户问题，因此不会丢失该客户。”

方案4：您的团队无法完成功能。 可能是因为您有交错的迭代 ，或者您的团队依赖其他人或团队来完成功能。 在这种情况下，您可以这样说：

“尽管我们正在完成工作，但是我们无法完成功能，因为我们没有将必要的人员集成到我们的团队中。 （说这些人是谁。）我不是在责怪他们-我确信他们也想完成这项工作。 但是，我担心未经测试就可能发布的风险（或您看到的任何风险）。 我担心我们会失去客户，从而失去收入。 我担心我们不会获得参考帐户。 我担心我们会错过发布日期，并失去潜在的收入。”

在每种情况下，您都已完成工作。 您解释了问题的影响。 由您的经理决定做什么。

当您想影响人们时（这就是您使用项目状态报告所做的事情），您可以解释问题如何影响他们。 您提供了可以讨论的可能性。

如果您想学习如何做到这一点，尤其是在敏捷转型的情况下，请加入我们的有影响力的敏捷领导者 。

翻译自: https://www.javacodegeeks.com/2017/02/highlight-risks-reporting-defects.html

缺陷报告及缺陷生命周期