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

news2024/11/26 18:20:43

什么是看板和 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 板的待办事项列表没有什么不同。