七张彩图全场景解析：缺陷在看板上如何管理

摘要：致命和严重缺陷, 不能只是简单地修复以及回归验证，需要在回顾会议上分析缺陷产生的根本原因，从根本上采取措施避免同类缺陷再次发生。

看板上如何管理缺陷呢？首先要给缺陷按照严重度分级。严重度一般分为以下几个等级：

Fatal(致命)：造成重大经济损失、网络安全、具有灾难性影响、功能无法使用、测试工作无法继续、开发工作无法继续等缺陷。比如：电商网站上用户无法下单、无法支付、无法填写送达地址、无法添加到购物车等基本使用问题，这种问题会造成重大经济损失，因此解决时间零等待。
Major(重大)：严重影响用户使用，但还不至于造成阻塞的问题。一般包括产品的某个功能性障碍, 产品性能非常缓慢等。比如：手机浏览器页面加载速度缓慢，这个问题会影响用户的上网体验，但勉强还是可以用的。
Minor(轻微)：对用户影响不大的体验问题。比如：界面的按钮颜色或布局不合适等。

每个企业会有自己的缺陷等级定义，与上面的定义也许不完全一致，但大致类似。对于不同严重度的缺陷，相应的处理策略不同。

缺陷是否上看板？是否遵循WIP限制

对于很多Minor(轻微)类的缺陷，实际上是对产品细节的改进意见，应该分析是否转成需求。如果经判断后决定不转成需求，这些轻微缺陷不需要与致命缺陷、严重缺陷以及需求一起抢占我们的注意力，争用我们的资源和人力，可以将它们放到一个轻微缺陷池子里即可，没有必要占用看板上的一个位置。因此，本文主要介绍致命和严重类型的缺陷在看板上如何管理。

对于致命缺陷，在看板上一般会走加急泳道,并确保这类缺陷被置于最高的优先级。

常见疑惑：加急泳道里的工作项是否要参与在制品限制的计算？

答：一般来说，加急泳道的工作项可以打破在制品的限制。但是在实际工作中，一旦放开这个约束后，很多工作项如洪水般涌入加急泳道。因此，需要给加急泳道本身设置一个上限，用来约束加急泳道的在制品。

如图所示，“Bug Fatal”是一个致命类型的缺陷，团队发现后马上将其放到看板的加急泳道中的“开发进行中”列。此时开发列的在制品有五个，由于“开发列”的在制品限制为5，所以已经达到上限。加急泳道的工作项可以不遵守在制品限制，并将其他泳道的工作暂停，调配人力来处理“Bug Fatal”。

图致命类缺陷走加急泳道

不论是致命类型还是严重类型的缺陷，要区分是需求上线前还是上线后发现的，因为上线前需求还在看板上流动，需要决定产生缺陷的需求如何处理。

处理测试中发现的缺陷

对于需求在上线前的测试阶段发现的缺陷，有两种处理方式：回流需求，和不回流需求。

回流需求。具体操作方法如下:

在需求上标识缺陷，然后将需求和缺陷一起打回开发。如图所示，需求“D”在测试阶段发现严重缺陷后，将需求“D”和缺陷一起回流到“开发进行中”列。由于“开发列”有在制品，所以回流可能会造成在制品超过限制，因此要尽快解决缺陷,让需求流出开发环节，从而让在制品控制在限制以内。

图上线前缺陷的回流处理方式（步骤1）

当缺陷修复后，需求“D”带着缺陷卡片继续向下流动到“开发完成列”。测试人员在不超过测试列在制品限制的前提下，从“开发完成列”拉动带着需求“D”和缺陷卡片一起到“测试进行中”列，如图：

图上线前缺陷的回流处理方式（步骤2）

测试人员对需求“D”进行完整的回归测试，并且重点验证缺陷不再复现后，需求“D”带着缺陷卡片移动至“测试完成列”等待上线。

2）不回流需求。

另一种方式是不将需求打回开发阶段，而是将需求留在测试阶段遵守在制品限制, 直到缺陷解完后，需求才继续流动。与此同时，新建一个缺陷工作项，放到开发环节解决。如图所示：

图上线前缺陷的不回流处理方式（步骤1）

在测试阶段发现需求“D”有缺陷，将需求“D”留在“测试进行中”列，而将缺陷打回“开发进行中”。同时，由于需求“D”在缺陷解决前不能从测试列继续向下流动，需要给“D”打上阻塞标签，标识该需求有缺陷在解。在缺陷解完后，流动到“开发完成列”，等待测试人员启动测试，如图所示：

图上线前缺陷的不回流处理方式（步骤2）

当测试人员从“开发完成列”拉动缺陷到“测试进行中”后，需求“D”的阻塞标签去掉，换成缺陷卡片，如图18。测试人员将需求“D”重新做回归验证，并且重点测试没有复现缺陷。

图上线前缺陷的不回流处理方式（步骤3）

处理线上缺陷

如果需求在上线后发现有严重缺陷，处理方法则不同。由于需求已经上线，在看板上不用再考虑需求与缺陷的联动关系，只需要新建一个缺陷类型的工作项, 放到Backlog里与其他需求一起做优先级排序，如图中看板的最下一行“线上Bug”泳道：

图线上缺陷的处理方式

线上Bug如果有严重缺陷，也需要升级到加急泳道里获取最高优先级。

像上图这样将严重和致命的缺陷与需求一起放在看板上进行排序和管理，才能够对Backlog（待办事项列表）和在制品做全景管理。很多时候缺陷其实不只是缺陷,本质上应该转化为进入Backlog的需求。因此，需求和缺陷具有密切的关系。

对于再次出现的致命和严重缺陷, 不能只是简单地修复以及回归验证，需要在回顾会议上分析缺陷产生的根本原因，从根本上采取措施避免同类缺陷再次发生。