由于看板方法是以价值流为中心的工作方式，所以看板方法里没有团队的概念，而是以价值流为单位建立看板。使用看板的单位可以是一个团队，也可以是多个团队，看板的范围取决于价值流的范围。依据价值流的范围，看板可以分为两级：团队级看板和产品级看板。

对于很多大型项目来说，一款产品由多个团队协作交付，每个团队各有分工。在这种情况下，企业不仅需要团队级看板，还需要在产品层建立看板，如图7-3所示。

图7-3产品、团队两层看板

在产品级看板上流动的是特性级大颗粒需求，即那些产品经理、版本经理以及利益干系人所关注的需求。产品级看板由负责产品端到端价值流的人来管理，在很多企业里是产品经理或版本经理这样的角色负责产品价值流。

在图7-3中，产品级看板的负责人组织各团队将大颗粒需求拆分成用户故事级的小颗粒需求，由不同的团队认领，因此，在团队级看板里流动的是由产品级看板拆分出的小需求。一般情况下，一个完整的特性级需求不需要拆分到多个团队中去，而是由一个相应的特性团队完成即可；相反，如果其中有的团队是组件团队，就需要将需求拆分到多个团队协作交付。

一个产品级看板所管理的项目规模并没有上限。我所参与过的产品级看板项目，从3个团队的20人规模，到40个团队500人规模都有。那么团队级看板的需求状态如何被反映到产品级看板中呢？这可以通过父子需求的级联关系实现。如图7-4所示，父需求A在产品级看板上流动，A拆分出了B、C、D三个子需求，分别由三个团队负责交付。如果企业用电子看板工具管理，那么父需求可以根据其所有子需求的状态自动跳转，不需要人手动更新父需求的状态；如果企业用物理看板管理，那么就需要产品级看板的负责人从各团队收集子需求的状态，再判断父需求应该处于什么状态，并手动更新父需求的状态。如果一个项目拥有大到几十人至几百人的规模，最好使用电子工具以提升管理效率。

图7-4父子需求的级联关系

团队级看板属于团队级敏捷，产品级看板属于产品级敏捷。本章以下各节介绍的看板实践对团队级看板和产品级看板都是通用的。

由于看板方法是以价值流为中心的工作方式，所以看板方法里没有团队的概念，而是以价值流为单位建立看板。使用看板的单位可以是一个团队，也可以是多个团队，看板的范围取决于价值流的范围。依据价值流的范围，看板可以分为两级：团队级看板和产品级看板。

对于很多大型项目来说，一款产品由多个团队协作交付，每个团队各有分工。在这种情况下，企业不仅需要团队级看板，还需要在产品层建立看板，如图7-3所示。

图7-3产品、团队两层看板

在产品级看板上流动的是特性级大颗粒需求，即那些产品经理、版本经理以及利益干系人所关注的需求。产品级看板由负责产品端到端价值流的人来管理，在很多企业里是产品经理或版本经理这样的角色负责产品价值流。

在图7-3中，产品级看板的负责人组织各团队将大颗粒需求拆分成用户故事级的小颗粒需求，由不同的团队认领，因此，在团队级看板里流动的是由产品级看板拆分出的小需求。一般情况下，一个完整的特性级需求不需要拆分到多个团队中去，而是由一个相应的特性团队完成即可；相反，如果其中有的团队是组件团队，就需要将需求拆分到多个团队协作交付。

一个产品级看板所管理的项目规模并没有上限。我所参与过的产品级看板项目，从3个团队的20人规模，到40个团队500人规模都有。那么团队级看板的需求状态如何被反映到产品级看板中呢？这可以通过父子需求的级联关系实现。如图7-4所示，父需求A在产品级看板上流动，A拆分出了B、C、D三个子需求，分别由三个团队负责交付。如果企业用电子看板工具管理，那么父需求可以根据其所有子需求的状态自动跳转，不需要人手动更新父需求的状态；如果企业用物理看板管理，那么就需要产品级看板的负责人从各团队收集子需求的状态，再判断父需求应该处于什么状态，并手动更新父需求的状态。如果一个项目拥有大到几十人至几百人的规模，最好使用电子工具以提升管理效率。

图7-4父子需求的级联关系

团队级看板属于团队级敏捷，产品级看板属于产品级敏捷。本章以下各节介绍的看板实践对团队级看板和产品级看板都是通用的。