Scrum 和看板都是 敏捷 实践/框架。多年来，它们不断发展，以应对围绕组织工作的特定挑战。
许多团队和组织经常结合使用 的实践 Scrum 和看板 ，有时会发挥他们的优势，有时则不然。所以，经常会出现这样的问题：我们什么时候应该使用 Scrum，什么时候应该使用看板？Scrum 和看板可以在任何项目中互换使用吗？或者两者中是否有可以结合使用的互补实践？
首先，如果我们结合了 Scrum 和看板的实践，但不应用整个框架，我们既不做 Scrum 也不做看板。我们正在做一些事情，但这两者都不是。我们也可能会从实践中获得一些好处，但不会从完全实施 Scrum 或看板中获得什么。
话虽如此，让我们将 Scrum 与看板与各种属性进行比较，以了解可以使用每种属性的项目类型。下面的表格总结了 Scrum 和看板的属性，并根据该属性突出显示了可以使用它们的项目类型。
| 序号 | 属性 | Scrum | 看板 |
|---|---|---|---|
| 1 | 工作周期 | 迭代。 Scrum 有冲刺， 冲刺 在 中团队遵循计划-执行-检查-行动 (PCDA) 循环。 复杂的、迭代的工作，比如新产品或功能开发，使用 Scrum 可能会更好地完成。 | 连续流动。 在看板工作周期中，一旦一件事完成，团队就会开始做另一件事。 看板更适用于支持和服务等连续流工作。 |
| 2 | WIP - 进行中的工作 | 设置 WIP 限制 Scrum 团队 为每个 sprint ，只有在所有工作完成后才开始接受新工作。 如果团队需要成就感/完成感/结束感，请使用 Scrum。 | WIP 限制正在进行中。 一些工作完成后，立即拿起新的工作。 如果团队继续做一件又一件的事情，请使用看板。 |
| 3 | 检查-适应（经验主义） | 每个冲刺都是一个检查和适应的机会。 如果需要，可以在多个冲刺中循环工作以进行即兴创作。 如果工作不断发展并需要即兴发挥，请使用 Scrum。 | 没有具体的检查和适应机制。 工作流向一个方向。 如果工作是一次性的，并且不需要检查和调整，请使用看板。 |
| 4 | 透明度（经验主义） | 工件 Scrum 中的 包括产品待办列表、冲刺待办列表、增量。 分别提供需求、实施和可交付成果的透明度。 如果需要与跟踪正在进行的工作分开跟踪需求，请使用 Scrum。 | 没有透明度的特定工件。 看板提供了一些透明度。 许多团队将产品待办列表（来自 Scrum）与看板结合使用。 如果只需要跟踪实施，请使用看板。 |
| 5 | 规划 | 特定事件 计划冲刺和当天的 ——冲刺计划和每日站会。 如果需要定期进行严格的计划，请使用 Scrum。 | 没有计划工作的规定。 团队采用自己的节奏和方法进行规划。 用户看板计划可以是间歇性的，也可以是根据需要进行的。 |
| 6 | 责任 | Scrum 中的问责制发展了责任重点，例如 负责 产品 人 业务的 、 开发人员 领域的 和 Scrum 主管 障碍的 。 如果团队需要个人专注于这些职责，请使用 Scrum。 | 看板中没有产品负责人、开发人员等责任。 它假设有一群人在执行任务。 如果团队只是一群具有一定专业知识的个人，请使用看板。 |
| 7 | 利益相关者/客户 | Scrum 有积极的利益相关者和客户参与——在冲刺审查活动期间至少有一次冲刺。 如果工作具有创新性、创造性或新颖性，并且需要利益相关者和客户的反馈/参与，请使用 Scrum。 | 看板没有提供一种方式来吸引利益相关者或客户。 许多团队采用每月一次的“冲刺审查”方法。 如果工作主要是日常工作并且不需要频繁的利益相关者参与，请使用看板。 |
如何选择
两种框架有着这么多区别，那么最后的问题是“我们要选择哪一个方法来用呢”？其实两种方法并没有好坏高下之分，也没有简单复杂的区别，具体使用哪一种方法，需要结合组织自身的实际情况来判断。个人认为，Kanban对于需求变化非常快的项目更有优势，比如连一周的迭代都没办法保证的特性开发，或者属于支持/维护类的项目团队。而相对来说，对于那些有着清晰特性开发团队，以便于按照固定的节奏提交价值增量，Scrum更加有完整的套路。此外，看板对于不喜欢对现状改变太大的企业，更加容易被接受。
