看板具有以下优点：
- 规划的灵活性。团队只专注于当前的工作，任务优先级由经理设定。
- 团队高度参与开发过程。定期的会议、透明的流程和自我组织的机会有助于员工变得更加团结和真正感兴趣。
- 周期时间更短。如果有几个人拥有类似的技能，那么持续时间就会减少，但如果只有一个人，就会出现瓶颈。因此，员工必须共享知识，从而优化周期时间。然后整个团队可以承担停滞的工作并恢复顺畅的流程。
- 更少的瓶颈。 RVP 限制使您能够快速找到由于缺乏关注、人员或技能而出现的瓶颈和问题区域。
- 明晰。当所有工作人员都可以访问数据时，瓶颈就更容易被发现。除了卡片本身之外，看板团队通常使用两种常见报告：管理图表和累积流程图。
实践中，该系统在非核心生产领域表现出优异的效果：
- 软件支持小组或帮助台。
- 当管理没有明确计划但开发正在 瑞典 whatsapp 号码数据 积极推进的初创企业时，看板非常有效。
看板也有缺点：
- 该系统不适用于 5 人以上的团队
- 它不适用于长期规划。
与 Scrum 的区别
Scrum与敏捷看板一样，是一种灵活的方法论，在IT领域也经常使用。乍一看，它们之间的差异并不明显。有许多相似之处，例如两种方法都存在积压。
| Scrum | 看板 | |
| 步伐 | 可重复的固定持续时间冲刺 | 连续工艺 |
| 发布发布 | 每个冲刺结束时，经项目经理（产品负责人）批准 | 流程继续进行，不会中断，或由团队自行决定 |
| 角色 | 产品负责人、Scrum Master、开发团队 | 团队由项目经理领导，有时也会有敏捷看板培训师参与 |
| 关键指标 | 团队速度 | 领先时间 |
| 变更的可接受性 | 在冲刺期间，改变是不可取的，因为它们可能导致错误的任务估计。 | 变化随时都有可能发生。 |
IT应用示例
微软直言：看板在软件开发中的首次亮相
看板原则在信息技术领域的 我们从基础开始 应用始于10多年前。戴维·安德森 (David Anderson) 是向软件开发人员推广看板的主要推动者之一，他于 2005 年担任微软的顾问。他们对其部门 XIT 持续工程部门的工作感到不满，因为该部门正在修复内部应用程序中的错误。报告年初时，该部门是其部门中业绩最差的。积压量是允许数量的5倍，处理一个请求的时间（前置时间 ）通常需要5个月。
新任产品经理在安德森的咨询帮助下，在9个月内将问题部门的生产效率提高了155％。现在交货周期为 5 周，积压订单恢复正常规模，准时交货率保持在 90%。所有这些结果都是在新员工的最低限度参与下实现的，员工继续使用相同的方法纠正软件错误 –只是组织工作的方法发生了变化。
有趣的是：肩负起扭转 XIT 局势重任的项目经理实际上对安德森的书很着迷
令他惊讶的是，当时他刚刚入职微软，却遇到 白俄罗斯商业名录 了软件看板的思想家。杜米特留请安德森帮助他完成任务，后者同意将书中的原则付诸实践。
Dumitriu 发现，由三名开发人员和三名测试人员组成的团队积压了 80 个请求。 PM 本人是临时任命的，因为该职位的要求包括能够使用 ASP 技术、使用 SQL Server 进行管理以及了解 MS Project Server。管理层将这个职位视为能够编程、准备报告和预测积压工作量的“技术人员”。人们当时认为，如果收集了大量的数据，就会发现该部门的问题。杜米特鲁并不是一个这样的“技术人员”。