在软件开发中如何将看板方法与 Scrum 集合使用？

什么是看板和 Scrum 的混合模式？适合在哪些场景使用？有哪些成功的案例可参考？本文将围绕以上问题展开。

敏捷实践是一个团队过程，选择适合团队的敏捷框架时并没有什么技巧，无论您是使用看板方法、Scrum 还是两者的组合，如Scrumban 和 Kanplan，团队都需要弄清楚哪个框架最适合作为规划、跟踪和发布优秀软件的基础。

一、看板和 Scrum 分别适合什么样的项目

1、看板方法适合的项目团队

看板旨在为团队成员提供恰如其分的工作内容，从而使团队始终处于满负荷的工作状态。实施看板的团队能够收获灵活的工作计划、清晰的工作重点和可视化的工作方式。所以说看板方法非常适合专注于持续交付且优先级不断变化的团队。

2、Scrum 框架适合的项目团队

相比之下，Scrum会将工作划分为一系列固定周期的迭代，也称为 Sprint（迭代）。Scrum 团队的核心任务就是完成本次迭代待办事项清单中工作。通常，具有清晰的产品路线图和任务优先级产品团队更适合使用 Scrum 框架进行开发。

二、什么是看板和Scrum的混合模式

1、混合模式一：Scrumban

如果你的团队想组合使用 Scrum 和看板，或者是想从 Scrum 管理过渡到看板管理，那么最佳解决方案就是 Scrumban。这种混合方法不同其他方式，采用 Scrumban 的团队中最常见的方式是既使用 Scrum 中带有待办事项清单的迭代计划，又使用看板的WIP限制和周期时间。（注意：周期时间是指从任务启动到任务完成，任务在团队工作流程中流转所需的时间。）

如果团队不想按迭代进行工作，但仍希望有待办事项清单，那么最佳解决方案可能是 Kanplan。

2、混合模式二：什么是Kanplan

Kanplan 是另一种用于实践敏捷软件开发的混合方法，与 Scrumban一样，它结合了 Scrum 和看板的能力。Kanplan 非常适合那些想拥有待办事项清单但又不想按迭代工作的团队。

下面我们将结合案例进行说明：

比如，A公司的开发团队负责一个用于构建、测试和交付软件的平台，四年前，开发人员主要依赖于可靠的基础架构和快速的持续集成(CI)，每个月需要进行21,000次构建，而今天，每个月需要进行超过150,000次构建。

这种明显的扩展是由于团队成长，从Subversion迁移到Git、启用自动化测试以及另一个显著的改变：从 Scrum 迁移到看板造成的。由于开发团队的工作性质（过多临时请求、创造性工作等）都使他们并不能很好地适应 Scrum 框架，所以团队决定引入Scrumban。但由于团队不习惯使用迭代，Scrumban 很快演变成了看板。

但事实证明看板也并没有达到他们的预期，他们从一个板发展到多个板，如一个工程师支持板，一个项目工作板等等，所有这些看板都具有不同的工作流程。那么这些看板最大的问题是什么？是那些未处理问题的分类管理以及完善。如何解决？

公司的开发团队试图通过每日站会和每周计划会议来梳理他们杂乱无序的待办事项内容，但他们真正需要的是待办事项列表而不是更多的会议。

由于传统上看板没有待办事项列表，因此产品经理、技术经理和团队负责人使用看板的第一栏进行计划。但随着这个列表的增长，很难看出问题并确定问题的优先级。该开发团队根据不同的工作领域拆分了他们的看板，但仍包含了大量杂乱无序的内容。

然而，该开发团队并没有去重组团队、看板或重新造轮子，而是决定将待办事项列表带入看板，这将看板分成两个部分：待办事项列表和在工作流程中移动任务的看板。这里的待办事项列表与 Scrum 板的待办事项列表没有什么不同。

编辑切换为居中

添加图片注释，不超过 140 字（可选）

这就是 Scrum 的待办事项列表和看板组合成的敏捷板。当你点击待办事项列表中的某个问题时，将显示问题的详细信息，并允许团队中的每个成员按需要调整待办事项列表的视图，以便于更快地执行任务。

最后，对于那些使用史诗和预分配版本来组织发布的非Scrum团队，他们也可以从这种混合模式下的Scrum板中获益，如查看问题详情或快速编辑。这种简单快速的编辑能力使产品经理、开发经理或在任何计划模式下工作的人有效地管理史诗和版本。

下面我们将以国内工具 PingCode 为例，展示如何在您的看板中添加待办事项列表：

自定义配置看板的“待办事项列表”1）看板栏设置：点击看板栏的右上角「更多」→「栏设置」，可以进行看板栏自定义配置操作2）在看板栏设置中可以在「名称」输入框修改看板栏名称，如“待办事项”

编辑切换为居中

添加图片注释，不超过 140 字（可选）

正如一位客户所说，Kanplan 的价值是能够帮助你获得两种模式的优点，让团队可以在不进行sprint的情况下任意移动卡片，并在backlog 中输入工作项以帮助更好地进行规划。

在这个案例中，Kanplan 为公司开发团队梳理解决了未分类处理的需求管理问题，为他们提供了一种过往在看板世界中不存在的计划模式，让那些认为看板、Scrum 或 Scrumban 不足以满足自身工作场景的团队提供了启示。

这也启发了现在的很多看板团队去找到使用敏捷框架的最佳方法，而不是尝试遵循可能不适用于他们的团队的敏捷实践。请牢记：敏捷开发是对最佳敏捷实践的持续改进。