看板方法高级应用之 "积极处理缺陷"

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

1) Fatal(致命)：造成重大经济损失、网络安全、具有灾难性影响、功能无法使用、测试工作无法继续、开发工作无法继续等缺陷。比如：电商网站上用户无法下单、无法支付、无法填写送达地址、无法添加到购物车等基本使用问题，这种问题会造成重大经济损失，因此解决时间零等待。

2) Major(重大)：严重影响用户使用，但还不至于造成阻塞的问题。一般包括产品的某个功能性障碍, 产品性能非常缓慢等。比如：手机浏览器页面加载速度缓慢，这个问题会影响用户的上网体验，但勉强还是可以用的。

3) Minor(轻微)：对用户影响不大的体验问题。比如：界面的按钮颜色或布局不合适等。

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

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

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

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

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

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

图1 致命类缺陷走加急泳道

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

处理测试中发现的缺陷

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

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

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

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

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

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

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

2） 不回流需求。

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

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

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

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

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

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

处理线上缺陷

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

图7 线上缺陷的处理方式

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

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

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