在为敏捷团队选择敏捷框架时，没有灵丹妙药。无论您使用Kanban、Scrum还是两者的组合，如Scrumban 和Kanplan，敏捷都是一个团队过程。每个团队都需要弄清楚哪个框架最适合作为如何规划、跟踪和发布优秀软件的基础。

Scrumban vs. Kanban vs. Scrum

Kanban旨在为团队成员提供足够的工作，以便团队始终如一地满负荷工作。实施Kanban的团队受益于灵活的计划、更清晰的重点和完全透明，因为板上的任何内容都是重中之重。这就是开发人员正在做的事情。Kanban非常适合专注于持续交付且优先级不断变化的团队。

相比之下，Scrum将工作划分为一系列固定长度的迭代；为Sprint安排的任何内容都是团队的首要任务（例如，特定功能或一组功能）。具有清晰路线图和优先工作集的产品团队通常从Scrum中受益最多。

但是，也许团队想从Scrum和Kanban的组合中受益更多？或者想从Scrum过渡到Kanban？那么解决方案就是Scrumban。这种混合方法以不同的方式表现出来，但Scrumban团队中最常见的趋势是使用带有Scrum backlog的Sprint，以及Kanban的WIP限制和周期时间。（注意：任务的周期时间是团队完成工作流程所需的时间。）

如果团队不想按迭代节奏工作，但仍希望能够通过backlog工作，该怎么办？Jira Software中的Kanplan（在Kanban中激活backlog功能）可能是答案。

什么是Kanplan？

Kanplan是一种用于实践敏捷软件开发的混合方法。与Scrumban类似，它结合了Scrum和Kanban的功能。Kanplan非常适合希望能够进行backlog管理但又不想按Sprint节奏工作的团队。 

为什么Kanban是基础而不是严格的框架

Atlassian的构建工程团队负责一个用于构建、测试和交付Atlassian软件的平台。开发人员依赖于可靠的基础架构和快速的持续集成（CI）。几年前，差不多每月21,000次构建。今天，这个数字每月超过 150,000次构建。

这种能力提升可以归因于团队成长、从SVN迁移到 Git、自动化测试以及从Scrum迁移到Kanban的决定。构建工程工作的性质（想想临时请求、故障事件、创新工作）并不能很好地匹配Scrum框架。所以团队决定引入Scrumban，它很快变成了Kanban，因为团队不喜欢使用Sprint。但是，事实证明，Kanban也不是他们所希望的解决办法。像许多团队一样，他们试图让它发挥作用。他们从一个板到多个板，一个支持工程师板，一个项目工作板等等，所有这些都具有不同的工作流程。但他们最大的痛点是什么？未经分类的问题是一块无人看管的“荒地”。一旦进入“处理中”列，团队就可以运转了，但是他们的“待办”列，或者说是“未分类”列，没有人管。

将To Do列变成Backlog

构建工程团队试图通过每日站立会议和每周计划会议来对抗他们冗长且杂乱无章的To Do列表。但他们真正需要的是Backlog而不是更多的会议。

由于Kanban传统上没有Backlog功能，因此产品经理、开发经理和团队负责人通过第一列中的问题进行计划。随着此列表的增长，很难看到问题并确定问题的优先级。构建工程团队根据不同的工作领域拆分了他们的Board，但合并后的团队Board仍然是崩溃（涉及大量滚动查找）。

因此，Jira Software团队没有试图找出重组团队、Board或重新发明轮子的不同方法，而是决定将backlog带入Kanban。Kanplan功能（现在在Jira Software中已经实现）在Column配置中可以引入Backlog页面。这将Kanban分成两个不同的页面；Backlog用于梳理的待办事项，Kanban board用于工程团队在工作流程中查看和移动任务。

此功能与Jira Software中的Scrum板的Backlog没有什么不同。例如，当您单击侧边栏中的Backlog菜单时，它将展示大量待梳理的任务。整理之后，您可以将任务拖放到工作流程的下一步中。

来自Scrum的backlog页面融入到Kanban board中，和Scrum中的backlog功能一样。单击某个Issue时，将显示Issue详细信息视图。诸如问题详细信息视图之类的重点视图允许团队中的每个成员更快地执行任务，而不会分心。

最后，对于那些使用Epic和版本来组织他们的发布的非Scrum团队，他们可以从Scrum板中的工具（如查看问题或快速编辑）中受益。这种简单快速的编辑使产品经理、开发经理和其他任何在计划模式下工作的人能够有效地管理Epic和版本。

想要在Kanban board中添加Backlog？

Kanplan可以做到“两全其美”。您可以在不进行Sprint的情况下任意移动卡片，并在Backlog中输入任务以帮助更好地计划。它消除了Atlassian的构建工程团队所经历的荒地，并为Kanban团队提供了一种以前在Kanban世界中不存在的计划模式。当团队不觉得Kanban、Scrum或Scrumban能解决问题时，它提供了一种新的方式帮助团队完成工作。通过在Kanban board上打开backlog模式，Kanban的新老团队都可以找到使这个敏捷框架发挥作用的方法，而不是尝试遵循可能不适用于他们的团队的最佳实践。最后请记住：敏捷开发是关于对最佳实践的持续改进。