看板方法高级应用之以价值为中心管理流动

常见误区：很多企业里，看板上流动的工作项是技术任务，比如JavaScript页面开发、后台数据、测试用例设计等任务。

在看板上流动的应该是直接承载用户或客户价值的内容，比如：需求、线上缺陷等。如果看板上流动的是技术任务，就失去了管理和优化价值流的意义。当然，并不是说技术任务类型工作不应该上看板，而是说，这种类型的工作项可以作为从需求拆分的子工作项，它们在看板上流动一些环节后结束生命，最终交付给用户或客户的是承载价值的工作项。

那么具体来说，如何在看板上既管理需求，又管理从需求分解的技术任务呢？

从图1至图8的看板介绍了典型的处理步骤，每个需求占用一条泳道，每个需求拆分出若干个技术任务。在第一步的图1中，以需求“D”为例，当把它从Backlog拉动到“准备好”队列后，表示团队对“D”的风险、技术实现方式、工作量已经分析透彻。如果团队认为需要，可以将需求拆分成技术任务，然后将需求和拆分后的技术任务都拉动到“准备好”队列。

图1管理流动第一步：需求进入“准备好”

假定需求“D”拆分了两个开发任务和两个测试任务，分别是:

1) Task1:前台页面开发

2) Task2:提供后台接口

3) Task3:设计功能测试用例

4) Task4:执行测试  

如果后台开发工程师想启动开发需求“D”，他将“D”和“Task1”一起移动到“开发进行中”列。而“D”的其他技术任务“Task2”、“Task3”、“Task4”仍留在“准备好”列，如图2。

图2管理流动第二步：需求流入“开发进行中”

当测试工程师想启动“Task3”设计测试用例，他将“Task3”移动到“测试进行中”列，由于需求“D”仍旧处于开发阶段，所以留在“开发进行中”列，如图3。

图3管理流动第三步：启动测试任务

当“Task1”完成开发后，开发工程师将“Task1”移动到“开发完成”列。此时，后台工程师想启动任务“Task2”，于是，他将“Task2”移动到“开发进行中”列。由于需求“D”有两个子任务，“Task1”虽然完成开发，但是“Task2”没有完成开发，因此“D”仍旧留在“开发进行中”列，如图4。

图4管理流动第四步：开发任务完成

当后台工程师完成“Task2”后，将“Task2”拉动到“开发完成列”。此时，由于需求“D”的两个开发子任务都已经完成开发，需求“D”可以拉动到“开发完成列”，如图5。

图5管理流动第五步：需求流入“开发完成”

此时，测试工程师完成了“Task3”，他将“Task3”移动到“测试完成列”，开始启动“D”的测试执行任务“Task4”，于是他将“Task4”和需求“D”一起拉动到“测试进行中”。那么这时候两个开发任务“Task1”和“Task2”该怎么办呢？

由于测试工程师以需求为单位工作，开发任务“Task1”和“Task2”停留在“开发完成”列，不继续向下流动，它们的生命周期就此终止，如图6。

图6管理流动第六步：需求流入“测试进行中”

测试工程师完成“D”的测试任务“Task4”后，“D”的两个测试任务都已经完成，于是“D”和“Task4”一起拉动到“测试完成列”。

图7管理流动第七步：需求流入“测试完成”

当团队决定产品上线的时候，需求“D”流动到“上线”列，而两个测试任务“Task3”和“Task4”由于不对用户承载价值，不是上线的单位，因此留在“测试完成列”，它们的生命周期终止，如图8。当需求“D”上线后，它的所有子任务“Task1”、“Task2”、“Task3”、“Task4”都没有必要继续在看板上跟踪，可以从看板上拿下收起来。

图8管理流动第八步：需求流入“上线”

从以上流动过程总结以下两点：

1) 在看板上价值流动的单位是承载价值的工作项。不承载价值的工作项，比如开发任务、测试任务等，它们只在某一、两个或几个环节内流动，生命周期短暂。

2) 对于价值交付效率相关的度量，比如流动效率、平均周期时间、在制品等，是以价值为中心只度量承载价值的工作项，不承载价值的工作项不具有度量意义。