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

2020-11-30 10:00:00
王明兰
转贴:
公众号
755


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

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

图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楼