看板中的价值是如何流动的？

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

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

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

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

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

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

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

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

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