看板方法 与 Scrum 的比较：选择最佳敏捷项目管理框架[译]

Posted 2023-05-09

参考技术A

“我们在使用敏捷方法。”在与软件开发团队交谈时，您经常会听到这样的声明。确实如此，根据统计2018年全球大约90％ 开发人员在使用敏捷方法。

但是，敏捷并不统一的方法。作为组织开发流程的通用方法，敏捷软件开发设定了共同的价值观和原则，旨在使开发过程更加简化，更加高效，更能响应变化。这些价值观和原则可以在 敏捷宣言 中找到，其中还包含了建立开发流程的推荐方法。

在现实生活中，这些敏捷原则已经衍生出了相当多正在实际使用的软件开发框架。看板（Kanban）和Scrum是其中最受欢迎和最常使用的开发框架。虽然两种方法都有一个共同的目标，即创建一个高效的开发流程，但是两者还是存在着一些差异。这就是我们今天要讨论的内容。

了解Scrum方法和看板方法的工作原理，可以帮助客户和开发人员理解开发团队的工作节奏，并制定相应的开发计划。

在我们深入研究Scrum和看板的差异之前，让我们先看一下两个框架的主要概念。这样，更易于我们比较看板与Scrum。两者都在为建立一个自组织团队而设计流程; 但是，采用了不同的方法。

Scrum的名字来自橄榄球术语，意思是球员组成阵型共同占据球权。在软件开发中，Scrum是指组织团队的方法，该方法旨在更高效地开发复杂的软件产品。

Scrum方法哲学是基于这样一个假设 - 或者说事实？ - 开发团队在项目开始时并不知道项目的最终成果，而是随着开发过程中不断了解和试探调整，最终完成交付。Scrum通过在每次迭代开始时重置优先级来简化这种调整，迭代在Scrum术语中被称为“冲刺（sprint）”。

我们再来看一个Scrum的核心概念 - 冲刺，即一个2到4周的迭代周期，在此期间需要完成明确数量的开发任务。冲刺有助于将项目范围分解为更容易管理的任务包，能更频繁地交付可运行的软件组件。我们将简要地介绍冲刺计划，计划调整和计划完成的细节。

基于冲刺计划进行开发，并专注于每个冲刺中应该完成的任务项，这使得开发计划具有很大的灵活性。团队从一个“空白的任务列表”开始每个新的冲刺，根据当下的情况和项目需求的变更来制定新的冲刺的开发计划。

看板方法最初是丰田公司为了优化其工厂库存发明的。在日语中，“看板”是指公告板或卡片。在最初的实践中，工厂生产部门会为某种数量不足的零件向仓库发送“看板”，要求补足数量。然后，仓库将“看板”发送给供应商以订购更多相应的零件。

从这个例子中，我们可以看到看板方法专注于当前容量，这也是它引入软件开发领域的主要概念。与Scrum不同，看板方法没有时间限定; 相反，它限定了可以同时执行的工作量。

看板的主要指标之一是“正在进行的任务” ，即当前正在执行的任务。根据看板方法，为了实现最高效率，正在进行的工作任务应限定为与团队的能力相适应的任务数，从而降低任务瓶颈产生的风险。

看板也能很好地适应变化，这很重要，因为变更会在项目的任何阶段产生，并需要随时添加到要执行的任务池中。

如果我们想比较Scrum和看板，我们需要看看两个框架组织工作流的方式以及它们使用的主要形式和定义。

角色的分配是Scrum和看板之间的第一个重大区别。 在Scrum中，您总能在团队中找到三个主要角色：

反之，看板对团队角色没有严格的要求。 也许会有一个产品负责人管理项目backlog中的任务，但除此之外，团队是自组织的。

正如我们所说，Scrum开发是在迭代中进行的，Scrum定义每次迭代中要完成的工作任务。看板则限定了当前正在进行的工作任务数，而没有具体的时间限定。让我们来看看这两种方法的实际应用。

项目计划从定义backlog开始，即应该交付完成的产品的用户故事列表。在这种情况下，Scrum使用以下主要概念来帮助我们理解计划和发布过程：

每个冲刺都以 计划阶段 开始，选择接下来冲刺所要完成的任务。对于制定计划过程，通常整个团队都要参加，包括产品负责人和Scrum导师。团队决定在冲刺结束时提交的内容，并从产品backlog中选择相应的用户故事。通过这种方式，团队整合了冲刺backlog。

在冲刺期间，团队每天召开 “每日立会” ，讨论他们的进展以及可能遇到的问题。每日立会的目的是尽早发现问题并快速找到解决方案，以免破坏冲刺流程。

冲刺完成后，客户将审查完成的功能。在 冲刺回顾 期间，团队有机会收到有关其交付物的反馈和变更请求（如果有的话）。

与此同时，团队会召开 冲刺回顾 会议，分析他们刚刚完成的冲刺并找到可以改进的地方。回顾完成后开始新的迭代，新的冲刺又从计划阶段开始。

在看板方法中，没有必须完成一定数量工作任务的时间计划。相反，看板专注于匹配团队的开发能力与当前正在进行的工作任务数。

看板项目流程从一个包括需要完成的所有任务清单的backlog开始。每个团队成员从backlog中为自己选择一项任务，并专注于完成它。任务完成后，成员再从backlog中选择下一个任务，依此类推，直到backlog清空为止。backlog按照优先顺序，把最紧急的任务放在最顶层，便于团队成员优先选择。

在看板项目周期内， 正在进行的工作任务 数量都不超出团队的工作容量至关重要。为此目的，可以根据可分配工作量为各种类型的工作任务设定限制。

产品负责人可以根据需要随时设定或调整backlog中的任务优先级，因为backlog管理不会影响到开发团队的工作绩效。开发团队只关心正在进行的工作任务，且只有在当前任务完成后才会关注backlog。

每项任务都沿着“待办” - “进行中” - “已完成”的状态路线行进。当然，看板也支持“已完成”概念的定义，即每个任务被接受的标准。

最终，已完成的任务组成产品组件，以便度量交付产品所需的时间。在看板中，它被称为 “周期时间” ，对周期时间的度量为过程优化提供了许多机会。当然，所有团队成员都在努力尽量缩短周期时间，并寻找解决开发瓶颈的方法（如果有的话）。

在这种情况下，让团队成员具有多重技能至关重要。如果只有一个人拥有某种技能 - 例如，如果你只有一个测试人员 - 那测试就会成为瓶颈。所有测试任务都将排队等待，以致于产品交付延迟。

总而言之，我们可以说两种方法的主要区别在于，Scrum方法努力使团队在指定时间内完成预定工作任务，而看板方法则确保正在进行的工作任务永远不会超过设定的团队最大工作量。

说到Scrum和看板，我们不能忽略其任务板。两种方法都使用任务板作为可视化工具来规划和监控项目进程。任务板反映了Scrum和看板的主要概念，及相应的组织方式。

虽然有很多工具用于创建并管理Scrum和看板的任务板（例如，Jira和TargetProcess两者都支持，而Trello最初是一个看板工具，但也可以扩展用于Scrum），你也可以使用带有标记和即时贴的纯白板。关键是学习如何使用任务板，而与具体的工具无关。

Scrum任务板至少应包含三列，分别标记为“待办（To Do)”，“进行中(In Progress)”和“已完成(Done)”。如果需要，您还可以添加“用户故事”列，显示所有的用户故事，或在“已完成”之前插入“测试”列，但最终它们都会及时显示当下的任务进度。

在每个冲刺开始时，所有任务都在第一列中，而在冲刺结束时，它们都应该按照“已完成”的定义移动到最后一列“已完成”中。之后，就可以清空任务板为下一次冲刺做好准备了。

Scrum任务板总是由为同一产品开发的一个团队所拥有。通常，Scrum团队成员是跨职能的，包括所有技能，从开发人员和架构师到测试人员和技术文档撰写者。

看板任务板的外观和工作方式与Scrum相同，但有一个主要区别 - “进行中”列中显示了任务限定量。正在进行的任务数量不能超过该限定量。

看板存在于整个工作周期中。 因为它们不受任何特定时间段的约束，所以没有必要重置。

因为看板是用于整个工作周期的，所以它们不属于某一团队，可以在不同团队之间共享。在看板中，任务板可用于特定的工作，例如营销任务板等。

如果您一直在等待这个问题的确定答案，我们可能会让您失望。到目前为止，我们希望我们能够证明这两种方法都有其优点，并且两者都有助于建立敏捷开发流程。当然，我们提供了一些建议，可以帮助您选择最适合您团队的方法。

使用Scrum方法，如果：

使用看板方法，如果：

您还可以随时组合这两种方法！ 甚至还有一种称为 Scrumban 的方法，其中包含Scrum和看板的方法。在Scrumban方法中，您可以在短迭代周期内完成工作，并使您的工作量保持在一定限度内。超出限定量的任务会触发新的迭代。

如您所见，可以像您希望的那样灵活和自由地选择项目管理方法。没有任何规则是一成不变的，您可以根据自己的项目需要对项目管理方法进行裁剪，组合和使用。实际上，选择项目管理方法的主要标准始终是您的项目成功和团队对工作流程的满意度。

原文： Kanban vs Scrum: choosing the best Agile project management framework

项目管理Scrum vs 瀑布 vs 敏捷 vs 精益 vs看板

软件开发行业有很多不同的方法–一些是旧方法的新方法，另一些方法采用了相对较新的方法。该领域中最常用的两种方法是敏捷，如Scrum，看板和精益等，以及传统的瀑布模型，如结构化方法或更新的RUP。

大多数常规这两种模式的软件公司都认为他们选择的方法在方面是优越的，所以在我们回答这个问题之前，“哪一个更成功？我们应该看看它们的主要区别。

瀑布方法

瀑布是软件开发过程的线性方法。这些都代表了软件开发的一个独特阶段，每个阶段通常在下一个阶段开始之前完成。每个开发阶段之间通常也有一个逐步。

• 结构化为顺序过程中的一个大项目

• 适合变化不常见的情况

• 一个需要预先明确定义的需求的流程

因此，瀑布模型保持只有在检查并验证其前一阶段时才应移动到阶段，如下图所示：

瀑布方法

例如：

在Royce的原始瀑布模型中，按顺序进行以下阶段：

• 系统和软件要求：在产品需求文档中捕获

• 分析：产生模型，架构和业务规则

• 设计：产生软件架构

• 编码：软件的开发，证明和集成

• 测试：缺陷的系统发现和调试

• 操作：完整系统的安装，迁移，支持和维护

敏捷方法

敏捷使用精益思想衍生出来，在信息技术环境中应用“精益”概念。精益方法的关键重点是：

• 消除流程中的浪费

• 开拓地减少业务非增值活动

• 从消费者的角度最大化附加值

敏捷方法

敏捷方法是经过验证的项目管理方法，它鼓励以下关键概念：

• 经常检查和调整

• 鼓励团队合作，自我组织和问责制的领导哲学

• 一套工程最佳实践，可以快速交付纳入的项目

• 一种将开发与客户需求和公司目标相结合的业务方法

敏捷开发–回归生命周期

敏捷开发阶段包括传统规划，分析需求，设计，编码，测试和部署，但它们形成一个循环而不是一条线。这意味着流程灵活，可重复，可以按任何顺序和并行发生。这允许收集用户反馈，针对不同环境的连续测试以及在运行时更改项目的范围。

敏捷方法的基础

• 经验主义–能够在逐步提高发展的过程中执行，停止，反思，改进和继续

• 确定优先级–根据业务价值提供工作

• 自组织–团队最了解如何根据资源和约束提供工作

• 时间拳击 –团队需要在规定的时间内完成指定的任务。

• 协作–团队承诺在给定的交付最终产品，这将鼓励跨团队协作和完成任务的独创性。

敏捷与瀑布–范围，时间和成本三角

瀑布方法的最大优势是固定成本和可预测性。你知道价格，什么时候交付。其最重要的弱点是其缺乏抵抗。敏捷方法非常灵活，可以演变成与最初尝试的产品截然不同的产品。

敏捷与瀑布

传统的瀑布方法建立在时间，成本和范围三重约束的基础上。调整这些变量中的任何一个都会强制改变至少其中一个变量。交付成功的项目改变平衡这三个竞争变量。，实际上，如果在软件项目的后期添加资源，它实际上会产生不利影响。

敏捷方法不是将范围视为一开始就是固定的，而是将时间（转化）和成本（团队成员）设置为固定；敏捷方法采用不同的方法，将三重约束颠倒过来。然后调整范围以关注最高优先级。建立敏捷是因为期望范围会随着时间的推移而发展。目标是在预算成本和及时满足客户最重要的要求。通过项目的进展，敏捷允许新的需求或重新确定优先级。

敏捷与瀑布质量

敏捷还是瀑布？

Standish Group的最新报告涵盖了他们在2013年至2017年间研究的项目。在这段时间内，敏捷和瀑布的成功，挑战和失败的整体突破如下所示，敏捷项目成功的大概是大约的2倍，失败的可能性降低1/3。

（来源：vitalitychicago.com  – 比较瀑布和敏捷项目成功率）

敏捷与瀑布–项目成功率

敏捷方法伞

实际上，敏捷方法只是一种思维方式，可以使团队和组织进行创新，快速响应不断变化的需求，同时降低风险。组织可以灵活地使用多个可用的框架，如Scrum，看板，精益，XP等。

Scrum敏捷伞

精益方法

精益组织了解客户价值，并关注其关键流程以不断提高客户价值。最终目标是通过一个零浪费的完美价值创造过程为客户提供完美的价值。

5步精益方法

指导精益方法实施的五步思考过程很容易记住，但并不总是很容易实现：

1. 从最终客户的角度按产品系列指定值。

2. 确定每个产品系列的价值流中的所有步骤，消除那些无法创造价值的步骤。

3. 使价值创造步骤按顺序进行，使产品顺利流向客户。

4. 随着流量的约会，让客户从下一个上游活动中获取价值。

5. 在指定值时，识别值流，删除浪费的步骤，约会流和拉，再次开始流程并继续，直到达到完美状态，其中创建完美值而没有浪费。

5步精益方法

Scrum方法

使用Scrum进行敏捷软件开发通常被视为一种方法论；但不是将Scrum考虑方法论，还是将其视为管理流程的框架。

Scrum过程画布

看板方法

看板是日本的“视觉信号”或“卡片”。丰田线路工人使用看板来表示制造过程中的步骤。作为精益的一部分，该系统的高度视觉性操纵团队可以更轻松地沟通需要完成的工作和何与scrum sprint board类似地，看板跟踪“做–做–完成”活动，但它限制了“必须的”活动的数量（该数量由团队经理定义，不能超过）。

看板方法

有四个基本的看板原则：

• 可视化工作以增加沟通和协作。

• 限制限制的工作，骨折无限的非优先打开任务链。

• 预期和优化流量，收集指标，预测未来问题。

• 初步通过分析获得持续改进。