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

团队级看板是由一个小团队所拥有的看板。这个小团队可能是跨职能团队，也可能是纯粹的职能型团队。对于跨职能团队来说，他们的看板管理的是端到端的价值流。如图7-2所示的一个团队，他们交付的每个特性都不依赖其他团队提供的任何组件，而且他们的价值流范围涵盖了从需求分析、设计、编码，到部署、上线的全过程。

图7-2全功能团队看板

相比之下，职能型团队的管理范围只是价值流中的一段。比如，很多组件团队开发的单个组件并不能为客户提供价值，而是需要与其他团队的组件集成在一起才具备价值。在很多企业里，典型的组件团队有：前端页面团队、后端数据库开发团队、中间件团队、系统测试团队。

企业在开展敏捷转型时最好将这些职能型团队重组为特性团队。但是，很多企业没有准备好重组，于是在保持现有的组织结构的情况下开始应用看板方法，依托看板方法牵引组织进行渐进式敏捷转型，这样的看板为职能型团队看板。

在一家金融企业R的系统测试团队的看板上，流动的工作项是测试用例设计、测试用例执行等测试任务，这些工作对客户没有价值，只是特性流动过程中的一个流程环节。我曾经在这家企业里看到宏伟壮观的看板工程：每栋楼、每个走廊、每个团队的工位上都竖立着看板；早上9点钟，所有团队都自觉地围在看板前开站会。当我仔细观察每个看板时，发现了关键的问题：这些看板貌似很好，但都是一块块孤立的看板，它们是开发组看板、测试组看板、运维组看板、规划组看板，每个看板互相之间没有连接。

一个系统中各个环节连接的部分，往往是上下游的交接之处，也是等待时间最长、浪费最大的地方。如果只在一个职能团队或职能部门应用看板方法，虽然能够提升自己团队或部门的效率，但是对整个价值流的影响是未知的，甚至是微弱的。只有对整个系统建立全价值流并应用看板方法，才能够实现系统级优化的效果。很多企业都只在价值流的一部分应用看板方法，常见的应用起始点是开发环节，而整个价值流的瓶颈未必是开发环节。

对于职能型团队，因受自己的权力所限，所以从自己可控制的范围开始建立团队级看板也无可厚非。但是团队需要扩展价值流的范围，逐步达到全价值流。

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

团队级看板是由一个小团队所拥有的看板。这个小团队可能是跨职能团队，也可能是纯粹的职能型团队。对于跨职能团队来说，他们的看板管理的是端到端的价值流。如图7-2所示的一个团队，他们交付的每个特性都不依赖其他团队提供的任何组件，而且他们的价值流范围涵盖了从需求分析、设计、编码，到部署、上线的全过程。

图7-2全功能团队看板

相比之下，职能型团队的管理范围只是价值流中的一段。比如，很多组件团队开发的单个组件并不能为客户提供价值，而是需要与其他团队的组件集成在一起才具备价值。在很多企业里，典型的组件团队有：前端页面团队、后端数据库开发团队、中间件团队、系统测试团队。

企业在开展敏捷转型时最好将这些职能型团队重组为特性团队。但是，很多企业没有准备好重组，于是在保持现有的组织结构的情况下开始应用看板方法，依托看板方法牵引组织进行渐进式敏捷转型，这样的看板为职能型团队看板。

在一家金融企业R的系统测试团队的看板上，流动的工作项是测试用例设计、测试用例执行等测试任务，这些工作对客户没有价值，只是特性流动过程中的一个流程环节。我曾经在这家企业里看到宏伟壮观的看板工程：每栋楼、每个走廊、每个团队的工位上都竖立着看板；早上9点钟，所有团队都自觉地围在看板前开站会。当我仔细观察每个看板时，发现了关键的问题：这些看板貌似很好，但都是一块块孤立的看板，它们是开发组看板、测试组看板、运维组看板、规划组看板，每个看板互相之间没有连接。

一个系统中各个环节连接的部分，往往是上下游的交接之处，也是等待时间最长、浪费最大的地方。如果只在一个职能团队或职能部门应用看板方法，虽然能够提升自己团队或部门的效率，但是对整个价值流的影响是未知的，甚至是微弱的。只有对整个系统建立全价值流并应用看板方法，才能够实现系统级优化的效果。很多企业都只在价值流的一部分应用看板方法，常见的应用起始点是开发环节，而整个价值流的瓶颈未必是开发环节。

对于职能型团队，因受自己的权力所限，所以从自己可控制的范围开始建立团队级看板也无可厚非。但是团队需要扩展价值流的范围，逐步达到全价值流。