看板中的价值是如何流动的？ - 看板管理知识

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

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

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

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

Task1：前台页面开发
Task2：提供后台接口
Task3：设计功能测试用例
Task4：执行测试

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

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

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

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

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

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

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

当团队决定产品上线的时候，需求“D”流动到“上线”列，而两个测试任务“Task3”和“Task4”由于不对用户承载价值，不是上线的单位，因此留在“测试完成列”，它们的生命周期终止，如图8。

当需求“D”上线后，它的所有子任务“Task1”、“Task2”、“Task3”、“Task4”都没有必要继续在看板上跟踪，可以从看板上拿下收起来。

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

在看板上价值流动的单位是承载价值的工作项。不承载价值的工作项，比如开发任务、测试任务等，它们只在某一、两个或几个环节内流动，生命周期短暂。
对于价值交付效率相关的度量，比如流动效率、平均周期时间、在制品等，是以价值为中心只度量承载价值的工作项，不承载价值的工作项不具有度量意义。

联系人：	阿道
电话：	17762006160
地址：	青岛市黄岛区长江西路118号青铁广场18楼