当不灵活和浪费的软件开发流程使您的组织效率低下时，是时候引入敏捷方法了。 看板与 Scrum 然后成为一个基本问题：哪种敏捷软件开发方法更适合我自己的情况？ 看板是否敏捷 ？ Scrum 与敏捷 相比如何？混乱正在蔓延……让我们看看如何解决所有这些问题。
Scrum——一个根本性的转变
Scrum 是一个定义明确的流程框架，用于构建您的组织。对于不习惯敏捷软件开发的团队来说，引入 Scrum 是一个很大的变化：他们必须开始迭代工作，建立跨职能团队，任命产品负责人和 Scrum 主管，以及引入定期会议进行迭代计划，每天状态更新和冲刺回顾。 Scrum 方法的好处是众所周知的：跨职能团队减少多余的规范和交接，短冲刺导致路线图规划更灵活等。将您的组织转换为使用 Scrum 是一个根本性的转变，它将动摇-养成旧习惯并将其转变为更有效的习惯。
Scrum 利用承诺作为变革推动者
Scrum 的最初引入本身并不是目的。使用 Scrum，您想改变团队的习惯：承担更多责任、提高代码质量、提高速度。当您的团队致力于实现冲刺目标时，他们会出于内在动力变得更好更快，以实现他们的承诺。 Scrum 利用团队承诺作为变革推动者。看到团队对自己的要求如此之高真是令人惊讶——通常比你作为经理敢于要求的要多得多。
看板——增量改进
看板方法的结构不如 Scrum。它根本不是过程框架，而是通过渐进式改进引入变化的模型。您可以将看板原则应用于您已经在运行的任何流程（甚至是 Scrum ��）。在看板中，您在看板上组织您的工作。那里有每个工作项从左到右经过的状态。根据每个列的分配容量，您可以从左侧开始将您的工作项拉过 in progress 、 testing 、 ready for release 和 released 列。你可能有不同的 泳道 ——用于不同类型工作的水平“管道”。看板引入的唯一管理标准是所谓的“进行中的工作 (WIP)”。无需更改任何其他内容即可开始使用看板。
看板利用在制品 (WIP) 限制作为变革推动者
对于看板上的每一列（状态），您应该定义一个“进行中的工作”限制（WIP 限制）。 WIP 限制告诉您允许多少工作项保持在特定状态。如果状态为“已满”，则没有新工作可以进入该状态。整个团队必须首先帮助清除已满状态。这样，您的团队只需查看看板就可以发现进度中的瓶颈，并面临改变工作方式以避免将来出现此类瓶颈的挑战。这样，WIP 限制就充当了看板中的变更代理。
看板与 Scrum
查看这两种敏捷软件开发方法，应该更清楚何时引入什么：如果您的组织真的陷入困境并且需要从根本上转变为更高效的流程，Scrum 似乎更合适。如果您已经有了工作流程，并且希望在不改变整个系统的情况下随着时间的推移对其进行改进，那么看板应该是您的首选工具。
Scrum 与敏捷？
询问 Scrum 与敏捷或敏捷与 Scrum 之间的区别就像询问“水”和“冰”之间的区别。冰是处于特定物理状态的水。关于 Scrum vs 敏捷也可以这样说。 Scrum 在特定的塑造中是敏捷的。它是一个敏捷过程框架。敏捷方法基于精益原则。软件开发中的 Scrum 和看板都是敏捷软件方法论的具体塑造。当 Scrum 与看板或看板与 Scrum 比较两种敏捷方法时，Scrum 与敏捷比较的是一个具体的例子及其基本原则。
