在 DevOps 直播课和认证备考课程中，我们发现总有一个问题一定会被问到。所以今天，我决定写一篇短文来回答它。这个问题就是：“DevOps 和 Scrum 有哪些区别？”也就是“DevOps 与 Scrum 对比”。
来自 International DevOps Certification Academy™ 的见解
DevOps 和 Scrum 的 6 大区别是什么？（DevOps 与 Scrum 对比）
今天我会介绍其中最重要的 6 个区别。开始吧！
区别 1： 采用 DevOps 时，你会在每次迭代（Sprint）结束时将代码部署到生产环境。采用 Scrum 时，每次迭代结束的目标只是准备好可交付的代码。
这是 Scrum 框架的一项主要缺点，也是 Scrum 在许多组织中失败的最重要原因之一，甚至可能是首要原因。如果不在每次迭代结束时部署代码，你通常就会把代码存放在预发布服务器上，或者更糟，让代码躺在代码版本控制（CVS）系统里，等项目主管（通常对软件工程一窍不通）决定何时上线。我知道有大型银行和电信公司每隔 6 个月才进行一次生产部署。听起来像个玩笑，但确有其事。 这些一次性大规模部署在生产系统中引发了大量最高优先级、最高严重程度的事件，降低了员工士气，也让更多员工开始更新简历。还没算上完全不懂技术的人为了给自己的失败找借口而相互指责、进行政治争斗。
区别 2： 在 DevOps 中，测试自动化和持续软件集成是持续软件交付的先决条件，早已融入软件开发实践。在 Scrum 中，软件交付是事后才考虑的事项，必须由完全不参与软件开发实践的人来规划和执行。
这也是 Scrum 框架最关键的弱点之一。Scrum 流程本身对软件交付实践贡献甚微，甚至毫无贡献。DevOps 则必须具备软件交付流水线、测试自动化和生产架构，使团队能够一键完成生产部署。 Scrum 软件交付流程始于 1986 年，由 Hirotaka Takeuchi 和 Ikujiro Nonaka 在《Harvard Business Review》发表的“New Product Development Game”一文首次提出。自 Scrum 问世以来已过去 30 多年，团队处理软件交付实践的方法已有显著改进。 如今，我们有了 DevOps，可以回答 Scrum 此前始终没有解答的问题。
区别 3： 在 DevOps 中，项目围绕为组织创造业务价值的产品和服务展开，而 Scrum 在促进业务成果方面尚不成熟。
DevOps 将工程团队视为能够自主思考并完成任务的单元，由它们交付可运行的软件产品与服务，为客户服务并为组织创造收入。 遗憾的是，Scrum 没有教给团队成员任何有关业务成熟度的知识。如果你觉得 Scrum 这些“不容置疑”的仪式（例如每日站会不得坐着开）看起来不错，但又觉得 这些训练有素、薪酬不低的工程师仿佛身在幼儿园，Scrum Master 像个幼儿园老师，那是因为 Scrum 并未教工程师如何成为专业人士。 有了 DevOps，工程组织中的每个人，无论当前经验和知识水平如何，都会以专业态度创造业务价值，因此不必再围绕每日站会上能不能坐下这类荒唐问题进行多余、无意义的讨论。 通过 DevOps，你可以把集思广益的精力用来确定并改进最合适的软件方案，为业务赚取更多收入！
区别 4： 在 DevOps 中，团队的所有工程师都关注服务质量（软件质量）和卓越运维，而在 Scrum 中，软件质量保证和运维是其他人的工作。
在大多数 Scrum 团队中，软件质量保证由外部测试人员独揽，软件部署与运维则由系统管理员负责。 Scrum 团队与交付质量脱节，也脱离了软件在生产系统中的实际运行过程。这是许多采用 Scrum 的组织陷入困境的另一个关键原因。 在 DevOps 中，质量保证是软件工程组织中每个人的共同责任。才华出众的 DevOps 全栈软件工程师从软件构思阶段到生命周期结束，始终关注交付、安全性、稳定性、性能、可维护性、可运维性及其他所有非功能方面。 这些 DevOps 团队汇集了开发软件、保障质量和运维软件所需的全部技能，因此具备成功所需的条件，也能为组织创造出色的业务成果。
区别 5： DevOps 为软件架构提供指导，以实现质量和持续可交付性，而 Scrum 并不支持你采用合适的架构构建软件。
Scrum 既不给工程团队提供支持，也不指导他们确定正确的架构方向和愿景。请再次记住，Scrum 自 Hirotaka Takeuchi 和 Ikujiro Nonaka 提出以来，已经有 30 多年历史。 在 DevOps 中，架构内的产品、服务和微服务 API 必须保持松耦合。每个 DevOps 团队只对松耦合架构的一部分负责，可以独立设计、开发和部署自己的软件。 内置于部署流水线的早期预警机制应自动、迅速地通知 DevOps 团队，告知每次代码提交可能造成的不良影响。
区别 6： DevOps 着眼于端到端的软件工程组织，以实现出色的业务成果，而 Scrum 只关注软件开发人员。
Scrum 将关注范围缩小到由 5 至 9 人组成的小型开发团队。如果你问能不能有 10 人，Scrum 理论会说不能。原因呢？不知道！ 无论如何，这种对软件工程的狭窄理解，往往会让 Scrum 难以适应组织，因为 Scrum 没有回答 Scrum 团队该怎样融入专业组织并创造价值的问题。 DevOps 建议组建面向产品和服务的团队。这些团队相互独立、具备跨职能能力、能够自主开展工作，通常规模较小。它们负责某项产品或服务（并非临时项目）整个软件工程生命周期的各个阶段，包括架构设计、详细设计、编码、测试、实验、部署、运维和维护。没错，你没有看错。还有谁能比软件的创作者更好地运维和维护软件呢？当然没有。因此， Amazon 和 Netflix 最成功的 DevOps 团队发布产品和服务后不会撒手不管，这并不令人意外。他们也负责在自己的生产系统中运维和维护软件。
读完这些差异，你现在应该清楚为什么 DevOps 正在成为新一代敏捷实践！
再过几年，人们就会普遍认同 DevOps 涵盖了 Scrum， 因为 Google、Amazon、Facebook、Etsy、Netflix 等众多大型组织已经采用了 DevOps。
这意味着 DevOps 很快就会普及！
International DevOps Certification Academy™ 提供你需要的一切，让你轻松学习 DevOps，顺利通过 DevOps 认证考试！如有任何疑问，我和我的团队将一如既往地为你服务！
访问 International DevOps Certification Academy™ >>
附言：让我们坦诚一下！ 我们知道，现在很少有人阅读博客文章。但我们还是坚持花时间为你整理这些文字内容。哪怕只有少数人读完并学到一两样东西，我们也认为自己履行了服务全球 DevOps 社区的使命！
我们用心撰写并为你带来这篇文章，欢迎给我们一点支持！ 如果你读到了这里，也觉得这篇文章对你有帮助， 请在本页下方留下评价，并与身边的人分享！
先谢谢你！:)
