“敏捷”和“scrum”在职位发布、供应商演示和站立会议中可以互换使用。它们不是同一件事，这种混乱会产生实际后果：团队采用 Scrum 思维，他们已经采用了敏捷，然后当 Scrum 的特定仪式不适合他们时得出敏捷“不起作用”的结论。这篇文章是对每一个的实际含义、边界所在以及如何选择的诚实读物。
一行的区别
敏捷是一组价值观。 Scrum 是一个试图体现这些价值观的特定框架。
敏捷说 什么 良好的软件开发看起来像（响应变化、工作软件、客户协作、个人与流程）。 Scrum 说 如何 一种特定的团队形状可以实现这一目标；有角色、仪式、文物和固定的节奏。
你可以保持敏捷而不需要混乱。你可以做 Scrum，但不做敏捷。很多球队都是两者兼而有之。有些人既不是又不知道。
敏捷实际上说了什么
2001 年编写的敏捷宣言有四项价值观和十二项原则。这四个值是著名的部分：
- 流程和工具上的个体和交互
- 工作软件胜过全面的文档
- 客户协作胜过合同谈判
- 响应变化而不是遵循计划
关键词是 结束：不是“代替”。右边有价值；左侧具有更大的价值。当团队宣称 Word 文档“不敏捷”或因为“我们很敏捷”而拒绝编写路线图时，这种细微差别就会消失。
这十二条原则更加具体：经常交付工作软件、即使在很晚的时候也欢迎变化的需求、可持续的步伐、卓越的技术、简单性、自组织团队、定期反思。
就是这样。没有提及 站立会议, 冲刺, 故事点, 回顾展, 敏捷大师, 或 规划扑克。这些都是后来才出现的。
Scrum 到底是什么
Scrum是由Scrum指南（最新版本：2020）定义的框架。它对少数事情有规定，而对大多数其他事情保持沉默。
角色 （三）：
- 产品负责人：拥有待办列表订单和已构建的内容
- Scrum 大师：拥有正在运行的进程
- 开发商: 拥有作品
事件 （五）：
- 冲刺：固定长度迭代（1-4 周），通常为 2
- 冲刺计划：选择本次冲刺的工作
- 每日站会：15 分钟团队同步（通常称为站立）
- 冲刺回顾：最后向利益相关者演示
- 冲刺回顾：团队反思流程
文物 （三）：
- 产品待办列表：潜在工作的完整列表
- 冲刺待办事项：致力于本次冲刺的工作
- 增量：制作的工作软件
这就是整个 scrum 框架。故事点、规划扑克、 速率, 燃尽图，整个“scrum-but”辩论；这些都不是 在 争吵。它们是广泛使用的附加组件。
为什么存在混乱
这些词被混在一起的三个原因：
1. Scrum是迄今为止采用最多的“敏捷”框架。 敏捷现状报告一致认为，Scrum 或 Scrum 衍生品占敏捷团队的 60-80%。如果大多数敏捷团队都是 Scrum 团队，那么“敏捷”和“Scrum”在休闲对话中几乎成为同义词。
2. Scrum认证主导培训市场。 认证 ScrumMaster (CSM) 和专业 Scrum Master (PSM) 课程是管理者学习敏捷的默认路径。课程教授 Scrum，经理回去运行 Scrum，团队认为这是“做敏捷”。
3. 供应商营销打破了这种区别。 工具供应商销售“敏捷项目管理软件”，这实际上是 Scrum 工具；冲刺、故事点、燃尽。标签粘住了。
结果是：进行站立会议、进行为期两周的冲刺和跟踪故事点的团队相信他们是“敏捷的”。他们正在做 Scrum。他们是否敏捷是一个单独的问题；答案往往是否定的。
团队如何进行 Scrum 而不是敏捷
这就是这种区别产生真正后果的地方。
一个负责举办每次 Scrum 仪式的团队，但是：
- 即使客户的需求发生变化，也拒绝在冲刺中期更改范围（违反“响应变化”）
- 产品负责人是否在没有团队参与的情况下决定每张工单（违反“自组织团队”）
- 将速率作为生产力指标进行跟踪，并迫使团队一次又一次地提高速率（违反了“可持续步伐”）
- 每个冲刺花费 4 小时参加为期 2 周的 5 人冲刺仪式（违反了“个人和互动高于流程”）
……正在做 scrum。它不敏捷。
这就是著名的“scrum-but”或“zombie scrum”模式。形状就在那里；精神不是。
团队如何在没有 Scrum 的情况下保持敏捷
同样常见且通常是经过精心选择的：
- Kanban 团队：连续流动，无冲刺， 在制品限制，拉动为主。在支持、运营和平台团队中大量使用。通常比 Scrum 团队更敏捷，因为团队不断重新规划。参见 Kanban 与 scrum 为了实际的差异。
- Shape Up 团队：6 周为一个周期，没有每日站立会议，自治团队，用山图代替燃尽图。 Basecamp 的方法。精神高度敏捷。
- XP（极限编程）：结对编程、TDD、持续集成、现场客户。比scrum更古老，更注重工程实践。许多“敏捷”工程实践来自 XP，而不是 Scrum。
- 务实/无名敏捷：小团队使用看板进行为期 1 周的迭代、每周演示和周五回顾。没有 Scrum Master，没有故事点，没有计划扑克。高度敏捷。
许多快速发展的初创公司都是这样运作的。他们无法通过 Scrum 认证审核。他们不断交付，并在几天内响应客户反馈，而不是冲刺。
那么我们应该使用哪个呢？
答案取决于三件事。
1. 团队现有架构有多少？ 来自混乱的团队受益于 Scrum 的规范结构；它给出了五个已知事件和三个已知角色的起点。一个已经拥有良好工程节奏的团队会发现 Scrum 的结构很沉重。
2. 工作的可预测性如何？ Scrum 假设您可以在一次计划会议中计划两周的工作。如果您的工作是被动的（支持、运营、紧急客户升级），那么看板更适合。如果它是离散的且易于理解（功能交付），那么 Scrum 冲刺就会发挥作用。
3、团队有多大？ Scrum 专为 5-9 人设计。 3 人时，头顶上的仪式占主导地位。 20 岁以上时，scrum 需要扩展框架（SAFe、LeSS、Nexus），大多数团队认为这些框架很重。
诚实的推荐
如果您从零开始并想要一个框架：scrum，并进行这些调整。
- 保持四个仪式（计划、每日例会、回顾、回顾）。
- 除非你有专门的教练，否则放弃 Scrum Master 的角色。团队可以运行自己的流程。
- 使用故事点或时间，以您的团队同意的为准。两者都不要有宗教信仰。
- 跟踪预测速率，而不是作为生产力指标。
- 经过 8-10 次冲刺后，看看哪些有效，哪些无效。放弃那些不值得花时间的仪式。
6 个月后，您将拥有适合您团队的自定义变体。这就是重点。敏捷宣言重视自组织团队 应对变化;包括对自己流程的更改。
这对于工具选择意味着什么
如果您决定使用 Scrum，您的工具应该使冲刺、回顾和速率跟踪变得微不足道；不是 30 步设置向导。大多数“敏捷项目管理”工具都是专门为 Scrum 构建的，而对敏捷的其余部分（仅看板、混合、异步回顾）支持不足。
SprintFlint 围绕 Scrum 冲刺周期构建：固定迭代、自动速率、原生回顾、故事点、燃尽。它假设您已决定进行 Scrum 式敏捷，并希望仪式持续五分钟，而不是星期二。
如果您不进行冲刺（看板、Shape Up、连续流），请选择适合您形状的工具。 Scrum 工具不太适合看板团队。
长话短说
- 敏捷 是 2001 年的一份价值观文件。四个价值观，十二项原则。没有规定仪式。
- Scrum 是一个特定的框架：三个角色、五个事件、三个工件。这是最被采用的 实施 敏捷的。
- 您可以在不敏捷的情况下进行 Scrum（僵尸 Scrum）。您无需进行 Scrum（看板、XP、务实）即可实现敏捷。
- 如果您想要结构并且您的工作可以在两周内进行规划，请选择 Scrum。如果没有，请选择较轻的东西。
- 无论你选择什么，几个月后，定制它。这是你能做的最敏捷的事情。