DevOps vs Agile：有什么区别？

早期，软件开发并没有真正归属于特定的管理范畴。后来出现了 瀑布模型，它表明软件开发可以根据应用程序创建或构建所需的时间长度来定义。

那时，创建、测试和部署软件通常需要很长时间，因为在开发过程中没有检查和平衡。结果是软件质量差，存在缺陷和漏洞，并且无法按时完成。重点是软件项目的长期、拖延的计划。

瀑布模型项目与 三重约束 模型相关联，该模型也称为项目管理三角形。三角形的每一边代表项目管理三重约束的一个组成部分：范围、时间和成本。正如 Angelo Baretta 写道，三重约束模型“表示成本是时间和范围的函数，这三个因素以已定义且可预测的方式相关……[如果]我们想要缩短计划（时间），我们必须增加成本。它表示，如果我们想要增加范围，我们必须增加成本或计划。”

从瀑布模型过渡到敏捷

瀑布模型源于制造业和工程，在这些领域，线性流程是有意义的；你在建造屋顶之前先建造墙壁。同样，软件开发问题被视为可以通过计划解决的问题。从开始到结束，开发过程由路线图清楚地定义，该路线图将导致最终产品的交付。

最终，瀑布模型被认为是软件开发的有害和反直觉的，因为通常，价值直到项目周期的最后才能确定，并且在许多情况下，项目都失败了。此外，客户直到项目结束才看到任何可工作的软件。

敏捷采用了一种不同的方法，它摆脱了计划整个项目、承诺估计日期以及对计划负责。相反，敏捷假设并拥抱不确定性。它围绕着响应变化而不是冲过变化或忽略变化的需求的思想而构建。相反，变化被认为是满足客户需求的一种方式。

敏捷价值观

敏捷受敏捷宣言的管辖，该宣言定义了 12 条原则

1. 让客户满意是首要任务
2. 欢迎变更需求，即使在开发后期也是如此
3. 频繁交付可工作的软件
4. 开发人员和业务人员必须协同工作
5. 围绕积极主动的人员构建项目
6. 面对面沟通是传递信息最有效和最有效的方法
7. 成功的主要衡量标准是可工作的软件
8. 敏捷流程促进可持续发展
9. 保持对技术卓越和良好设计的持续关注
10. 简单至关重要
11. 最佳架构、需求和设计来自自组织团队
12. 定期反思工作，然后调整和调整行为

敏捷的四个 核心价值观 是

• 个体和互动 胜过 流程和工具
• 可工作的软件 胜过 详尽的文档
• 客户协作 胜过 合同谈判
• 响应变化 胜过 遵循计划

这与瀑布模型僵化的计划风格形成对比。在敏捷中，客户是开发团队的成员，而不仅仅是在开始时（在设置业务需求时）和结束时（在审查最终产品时）（如在瀑布模型中）参与。客户帮助团队编写 验收标准，并在整个过程中保持参与。此外，敏捷要求在整个组织中进行变更和持续改进。开发团队与其他团队（包括项目管理办公室和测试人员）合作。完成什么以及何时完成由指定的角色领导，并由整个团队商定。

敏捷软件开发

敏捷软件开发需要适应性计划、演进式开发和交付。许多软件开发方法、框架和实践都属于敏捷的范畴，包括

• Scrum
• 看板（可视化工作流程）
• XP（极限编程）
• 精益
• DevOps
• 特性驱动开发 (FDD)
• 测试驱动开发 (TDD)
• 水晶
• 动态系统开发方法 (DSDM)
• 自适应软件开发 (ASD)

所有这些都已单独或组合用于开发和部署软件。最常见的是 scrum、看板（或称为 Scrumban 的组合）和 DevOps。

Scrum 是一个框架，团队通常由 Scrum Master、产品负责人和开发人员组成，以跨职能和自主导向的方式运作，以提高软件交付速度和

为客户带来更大的业务价值。重点是以更小的 增量 进行更快的迭代。

看板 是一种敏捷框架，有时称为工作流程管理系统，可帮助团队可视化他们的工作并最大限度地提高效率（从而实现敏捷）。看板通常由数字或物理看板表示。团队的工作在看板上移动，例如，从“未开始”到“进行中”、“测试”和“完成”，随着工作的进展。看板允许每个团队成员随时查看所有工作的状态。

DevOps 价值观

DevOps 是一种文化、一种心态、一种软件开发或基础设施的方式，以及一种构建和部署软件和应用程序的方式。开发和运营之间没有墙；它们同时且无孤岛地工作。

DevOps 基于另外两个实践领域：精益和敏捷。DevOps 不是公司内的职称或角色；它实际上是组织或团队对持续交付、部署和集成所做的承诺。根据 Gene Kim，《凤凰项目》和《独角兽项目》的作者，有三种“方式”定义了 DevOps 的原则

• 第一种方式：流动原则
• 第二种方式：反馈原则
• 第三种方式：持续学习原则

DevOps 软件开发

DevOps 不是在真空中发生的；它是一种灵活的实践，在其最真实的形式中，是一种围绕软件开发和 IT 或基础设施实施的共享文化和心态。

当您想到自动化、云、微服务时，您会想到 DevOps。在 采访 中，《加速：构建和扩展高性能技术组织》的作者 Nicole Forsgren、Jez Humble 和 Gene Kim 解释说

• 软件交付性能至关重要，并且对组织成果（例如盈利能力、市场份额、质量、客户满意度和实现组织和使命目标）具有重大影响。
• 高性能者实现了吞吐量、稳定性和质量水平；他们不会为了实现这些属性而做出权衡。
• 您可以通过实施精益、敏捷和 DevOps 手册中的实践来提高您的绩效。
• 实施这些实践和能力也会对您的组织文化产生影响，而组织文化反过来又会对您的软件交付绩效和组织绩效产生影响。
• 为了了解如何提高绩效，还有很多工作要做。

DevOps vs. 敏捷

尽管 DevOps 和敏捷有相似之处，但它们并不相同，有些人认为 DevOps 比敏捷更好。为了消除混淆，重要的是要深入了解本质。

相似之处

• 两者都是软件开发方法；这是无可争议的。
• 敏捷已经存在超过 20 年了，而 DevOps 是最近才出现的。
• 两者都相信快速软件开发，并且它们的原则都基于如何在不损害客户或运营的情况下快速开发软件。

不同之处

• 两者之间的区别 在于开发之后会发生什么。
  • 软件开发、测试和部署在 DevOps 和敏捷中都会发生。但是，纯粹的敏捷往往在完成这三个阶段后停止。相比之下，DevOps 包括持续发生的运营。因此，监控和软件开发也是持续的。
• 在敏捷中，不同的人员负责开发、测试和部署软件。在 DevOps 中，DevOps 工程角色负责所有事情；开发就是运营，运营就是开发。
• DevOps 更与削减成本相关联，而敏捷更与精益和减少浪费同义，并且诸如敏捷项目会计和最小可行产品 (MVP) 等概念是相关的。
• 敏捷侧重于并体现经验主义（适应、透明 和 检查）而不是预测性措施。

总结

敏捷和 DevOps 是不同的，尽管它们的相似之处导致人们认为它们是相同的。这对敏捷和 DevOps 都是一种损害。

作为一名敏捷主义者，我的经验表明，对于组织和团队来说，从高层次理解敏捷和 DevOps 是什么，以及它们如何帮助团队更快、更高效地工作，更快地交付高质量产品以及提高客户满意度，非常有价值。

敏捷和 DevOps 在任何方面都不是对抗性的（或者至少意图不是这样）。在敏捷革命中，它们更像是盟友而不是敌人。敏捷和 DevOps 可以排他性和包容性地运作，这使得两者都可以在同一空间中存在。