敏捷、Scrum 和看板：这些词到底是什么意思？

当软件开发人员听到有关“新 JavaScript 框架”或“新 IDE”的消息时，他不需要问更多问题来澄清它的含义。 但是如果他听说了一个“新的敏捷框架”，他可能会像荷马辛普森式的点头，假装他知道它是关于什么的，但他会有一个，而且只有一个问题： “敏捷框架”到底是做什么的意思是？

在现代软件开发环境中，我们越来越多地听到诸如“敏捷”、“Scrum”和“看板”之类的词，而且它们经常被不当使用。 在本文中，我将尝试解释和澄清其中一些术语。

敏捷

如果你想成为人群中的聪明人，当你谈论工作过程时，你应该在每隔一个句子中使用“敏捷”这个词。 它的范围很广，并不要求你对你所谈论的主题了解很多，而且它是一个非常好的形容词或副词：“思考敏捷”、“敏捷方法”、“根据敏捷原则”。 但“敏捷”的真正含义是什么？

“敏捷”是指“敏捷软件开发”，即遵循敏捷原则的开发方法。 但到底什么是“敏捷原则”？ 看看敏捷宣言和敏捷的 12 条原则，它们为敏捷开发奠定了基础。 从宣言：

敏捷原则鼓励功能软件的持续交付、团队之间的密切沟通以及对不断变化的需求的高度适应性。 如果您在工作中遵循这些价值观和原则，则可以说您是在敏捷环境中工作。 因此，敏捷软件开发不是一种方法论，它只是一组遵循相同原则的不同方法论、框架和技术。 可以说，“敏捷”是一个思考和决策的框架。

但为什么在我们的工作中遵循这些原则如此重要？

宣言和原则是寻找数十年来为应对软件开发挑战而发展的最佳解决方案的结果。 在整个 70 年代、80 年代和 90 年代，世界各地的不同开发人员和团队一直在试验工作方法和解决问题的方法，发明不同的框架和技术（例如 Scrum 和极限编程），甚至达到相同的目标并行的想法。 最后，在 2001 年 2 月，17 位开发人员聚在一起，为所有这些不同的想法和经验找到了共同点。 这就是宣言的创建方式。

Scrum

如果你在不知道“敏捷”方法的含义的情况下谈论“敏捷”方法，那么你可能会在知道该主题的对话者面前说出一些会让你发现的话：“Scrum 和其他敏捷方法论”。

Scrum 不是一种方法论，尽管我们都听说过它比《权力的游戏》中的杀戮次数还要多。 Scrum 不会对每一个问题都给出答案，也不会为你提供准确的程序来应对你面临的每一种情况。 并且可能由于这种不正确的解释，大多数 Scrum 实现也是错误的：团队没有获得价值。 这可能导致关于 scrum 的最愚蠢的陈述：“Scrum 不起作用。”

什么是 Scrum？ Scrum 指南将 Scrum 定义为：

所以它是一个框架，就像任何其他框架一样，它可以并且经常被错误地使用。 有效地使用 scrum 不仅需要采用 scrum 设定的结构，还需要对整个团队的敏捷原则有深刻的理解和欣赏。

Scrum 由以下角色组成：产品负责人、Scrum Master、开发团队。

还有四种 Scrum 仪式：Planning Meeting、Daily Scrum、Sprint Review、Sprint Retrospective

以及三个工件：Product Backlog、Sprint Backlog、Product Increment。

Scrum 项目被组织成固定的时间框架，我们称之为冲刺。 它们通常持续两周。

产品负责人负责指导项目的方向。 随着新任务和功能的确定，产品所有者将它们添加到产品待办列表中。 冲刺从计划会议开始，开发团队在会议上从待办事项中选择要处理的任务并计划如何实施。 接下来是开发，在此期间，开发团队使用积压工作来跟踪进度并召开每日会议，以便在需要时同步活动并调整计划。 开发的结果应该是产品增量，可以应用到产品上并立即发布的东西。 在 sprint 结束时，产品增量会在 sprint 评审时提交给产品负责人，如果需要进一步的更改，产品积压工作会增加。 之后，整个团队参加 sprint 回顾会，他们讨论工作流程以及如何改进它。

Scrum 很容易学习和理解，但很难采用。 这个框架可能适合也可能不适合项目的原因有很多。 它通常需要很多变化，不仅在日常发展方面，而且在文化方面。 Scrum 最适合复杂产品的开发，这些产品可以持续很长时间并且包括不同类型的专家。

为什么 Scrum 如此受欢迎，为什么它比传统的瀑布模型有优势？ 简而言之，因为它为产品和客户提供了更多价值。 使用瀑布等“重量级”方法，恐怖故事比比皆是，几个月来没有人看到该项目的任何内容。 使用 scrum，这是不可能的。

Scrum 是关于交付给最终用户的价值。 如果你真的使用 scrum，你需要在每个 sprint 中交付一些有价值的东西。 价值可以衡量，团队也被迫检查障碍并适应，目标是在下一次迭代中交付更多价值。

在大多数软件开发中，我们并不是在建造摩天大楼；而是在建造摩天大楼。 我们不需要在开始之前就准备好整个计划，并坚持到最后。 我们在开发软件，我们有能力适应不同的情况，在开发过程中改变产品需求。 一直以来，很多开发者都将其视为第八大罪，但从产品的角度来看，这对于优化可预测性和控制风险来说是一个巨大的好处。 Scrum 是围绕这种能力开发的，它的实现提供了一种可靠且有效的方式来处理必要的更改。

许多技术与 scrum 结合使用：规划扑克、结对编程、测试驱动开发 (TDD)、行为驱动开发 (BDD) 等。 它们实际上并不是 scrum 的一部分，而是兼容的技术。 与 Scrum 同时经常提到的一种方法是看板，关于这两个东西在相互关系中的含义存在很多混淆。

看板

当您谈论 Scrum 和看板时，人群中的一个常见问题是：“Scrum 和看板哪个更好？” 你不知道该回答什么，因为这就像比较苹果和橙子，或者问：“煎饼和啤酒哪个更好？” 两者都更好。

看板是一种简单的方法，旨在及时交付，同时不会让团队成员超负荷。 它与 scrum 类似，目标是最终交付最大价值，但它比 scrum 灵活得多。

看板不是由软件开发社区发明的。 事实上，它起源于丰田的制造工艺，在其他领域也有广泛的用途。 没有您应该遵循的严格程序，也没有您应该实施和使用看板的严格方式； 相反，它是一组原则和实践，您可以从这些实践中进行选择以满足您的需求。 但是在软件开发中有一种最常用的看板实现，包括使用看板，由代表工作阶段和任务的列组成。

列代表开发过程中任务的状态。 最简单的示例由三列组成：“To Do”、“In Progress”和“Done”。 因此，任务被添加到“待办事项”中，在开发开始时移动到“进行中”，并在移动到最后一列时被视为“完成”。 但当然，它可能更复杂：

待办事项→定义规范→准备开发→开发→代码审查→测试→部署（→没有人真正使用它→完全删除）。

每列都可以有子列； 例如，“开发”可以分为“规划”和“编码”； “测试”可以分为“单元测试”和“集成测试”等。 如果合适，专栏可能会专门针对专家。 团队根据需要定义列和阶段。 根据“拉动”理念，任务只应在立即有需求时才进入工作流程。

该板的目的是可视化工作流，这是看板中的第一个关键实践。 事实上，看板可以在没有板的情况下完成！ 它可以是 Google 工作表中的简单任务列表，用不同的背景颜色指示任务的状态，也可以是甘特图、图表、表格……甚至可以是办公室中的一组桶，每个桶代表任务的状态，以及将球用作任务的位置。 只需可视化工作流程并为整个过程提供透明度。

另一个重要原则是减少您的工作量。 简而言之，这意味着避免多任务处理。 这可能意味着减少您同时处理的任务量。 如果团队中有 3 名设计师，则团队可能会将“设计”列中的最大任务数设置为 3。

与 scrum 一样，看板也将团队视为流程中最重要的人物。 但它并不像 scrum 那样建议角色，您可以保留现有角色以避免对现有流程进行更改。 这同样代表持续改进：看板通常鼓励您不断学习和改进，但不会像 scrum 的 Sprint Retrospective 那样仅针对该过程规定特定事件。

我应该使用哪个？

Scrum 和看板并不相互排斥，也没有真正的可比性。 在 scrum 中，有明确的角色，而看板说，“什么鬼，保持你当前的角色和职责。” Scrum 会迫使你改变工作方式； 看板让您从现有流程开始。 在 scrum 中，框架规定了明确的事件时间表； 在看板中，您没有事件。 然而，它们有很多相似之处：两者都以价值为中心，团队成员被尊为系统的“老板”，本质上，他们有着相同的使命：不断消除浪费和消除障碍。

但问题是，“我应该在我的特定项目和我的特定团队中使用什么？” 更有意义。 看板不需要太多的流程和文化改变，而且在大多数情况下，它比 scrum 更容易采用。 另一方面，Scrum 提供了更多的结构来指导流程，只要每个人都在同一页面上，就可以消除大量开销。

但两者的美妙之处在于，两者都不是一套严格的规则。 没有什么能阻止您为自己挑选最好的 Scrum 元素，例如每日会议或回顾。 没有理由不能将看板合并到 Scrum 中。

当整个团队都很好地理解 Scrum 时，它已被证明是一个非常有效的框架。 但是，根据我的经验，我发现很难与一些客户一起在 scrum 中工作。 正确实施 Scrum 所需的流程和文化变化可能太多（尤其是在与认为自己正在创建新 Google 的人打交道时！）。 另一方面，看板更灵活，不会强迫人们改变。 一些作者还说看板是实现敏捷性的好途径，并且更容易实现 scrum。 其他人说，使用 scrum 应该最终导致看板。

事实是，每个项目都是不同的，没有一刀切的解决方案。 作为项目经理，由您决定什么最适合您的团队。