早在世界发现敏捷之前,优先解决漏洞是软件开发的一个挑战。 但是敏捷的短期迭代使得许多团队更难决定要修复哪些 bug 和推迟哪些 bug。 好消息是,一个敏捷团队通常比使用更传统的软件开发框架的团队选择更少的漏洞修复。 但是大多数敏捷团队在开发过程中仍然会发现一些 bug,特别是如果一些开发是在团队采用敏捷方法之前完成的。 他们需要一个有效的方法来优先考虑这些缺陷。



优先解决 Bug相关的问题 : 什么不该做

每在我作为程序员的早期,我的老板让我们整个团队花了一个星期的时间来检查每一个已知的缺陷。 我们讨论了可能的原因,每个 bug 的严重程度,它发生的频率,bug 是否被复制,代码中的 bug 很可能是,而我们中的哪些人应该解决这个问题。

我们甚至估计每次修复可能需要多长时间。 这些估计不仅毫无价值,而且在很多情况下,估计一个解决方案需要更长的时间,但事实上又不会按照解决方案做。

当我开始领导团队的时候,我早就意识到以往方法存在弊端,我开始尝试其他一些更轻松的方法。

今天我想和大家分享我的缺陷管理方法。

...

根据政策优先考虑缺陷: 更好的方法

与其花时间单独反思每一个新 bug,不如制定缺陷策略来确定修复 bug 的速度。

一个缺陷策略可能是,任何严重影响所有用户的缺陷都会立即被修复,这意味着它会在当前的 进度中中断工作。 另一个缺陷策略可能是,只在极其罕见的情况下发生的错误,并且不会阻止用户完成关键任务,只要在最后期限内修复即可。

通过这种方式创建和使用策略被称为政策的优先级。

举一个具体的例子,一个团队或产品所有者可能都会同意,任何阻止在他们的电子商务网站上提交订单的bug,应该立即修复。

其他的bug可能只需要在一天结束前修复,也可能是周末,或者根本不需要。


定义缺陷策略

制定错误修复策略的一个有用方法是考虑:

  • 缺陷可能性: 这个问题发生的频率是多少?
  • 缺陷严重性: 如果问题真的发生了,情况会有多糟?

请注意,我把这些称为可能性(或频率)和严重性。

试想一下,亚马逊网站上出现一个错误,订单超过100万美元的订单没有被提交,因为一个开发者假设订单永远不会超过999,999.99美元。

如果这种情况发生,结果很糟糕(后果很严重) ,但我不得不想象亚马逊没有得到超过100万美元的订单(很低的可能性)。

...

创建一个缺陷策略矩阵来优先处理 bug

这两个维度——严重性和优先权——可以结合起来,以确定缺陷的优先政策。 要做到这一点,创建一个简单的矩阵交叉引用这两个因素,就像我在这里所做的:

严重性
严重程度 <1%的交易 1%的交易 <10%的交易 >10%的交易
简单,明显的解决方案可用 轻微 轻微 严重 严重
不明显的变通方法或只对某些用户可用的变通方法 轻微 一般 严重 致命
重要的功能不可用 一般 严重 致命 致命

有很多方法可以对可能性和严重性进行分类。 坚持一个电子商务网站的例子,我使用了交易受影响的百分比的可能性。 任何估计会影响10% 或更多交易的事情都是非常重要的,所以我把整个列设置为 严重或者致命。

对于严重性,我使用了是否有工作围绕,显而易见还是难以找到。 在电子商务网站上,可能有两个"现在就买"按钮,只有一个正在工作。

矩阵中的单元格表示,对于指定的可能性和严重性的缺陷,应采取何种政策。 在这个例子中,我使用了从非常低到非常高的五个优先级。

下面是我将介绍这五个等级:

非常高: 即使冒着延迟工作的风险,立即添加到当前的迭代中。 可能非常需要不止一个团队成员的努力,可能包括整个团队。

高: 即使有延迟工作的风险,也要立即添加到当前的迭代中。 团队决定谁能最好地解决这个问题。

一般: 添加到当前迭代中,由产品所有者自行决定。

低: 文件记录。 在下一次迭代规划会议中,由产品所有者自行决定。

非常低: 记录在已知问题的列表中。 只有在严重性或可能性增加或产品所有者自行决定的情况下才重新考虑。


根据策略优先处理漏洞的优点

这种方法的关键优势在于,它大大减少了用于讨论如何处理每一个缺陷的时间。 按照策略对错误进行优先排序确实需要一些初步的努力来创建正确的策略。 但是一旦创建了这些,每个新的缺陷报告的优先级就变得微不足道了。

采用这种方法的目标是,优先考虑缺陷主要是客观的,而不是主观的。 是的,有人将不得不决定一个问题可能发生的频率,但除此之外,优先处理缺陷不会比咨询团队的政策矩阵更耗时间。


你怎么看?

你认为根据政策优先处理缺陷怎么样? 你的团队采取了哪些步骤来使优先级缺陷更容易?