两者之间的差异在于开发后会发生什么。

早期，软件开发并不真正使用特定的管理框架。然后是瀑布开发方式，它提出了一个想法，即可以通过应用程序创建或构建所花费的时间来定义软件开发。

那时，创建，测试和部署软件通常要花费很长时间，因为在开发过程中没有制衡手段。结果是软件质量差，存在缺陷，错误和未满足的时间表。重点在于软件项目是长期计划。

瀑布开发项目已与三重约束模型关联，该模型也称为项目管理三角形。三角形的每一边代表项目管理三重约束的一部分：范围，时间和成本。正如安吉洛·巴雷塔（Angelo Baretta）所写，三重约束模型“说成本是时间和范围的函数，这三个因素以定义和可预测的方式相关... [如果要缩短时间表（时间），我们必须增加成本。它说，如果我们想扩大范围，就必须增加成本或进度。”

从瀑布过渡到敏捷

瀑布来自制造和工程，其中线性过程才有意义。在建造屋顶之前先建造墙壁。同样，软件开发问题被视为可以通过计划解决的问题。从头到尾，开发流程均由路线图明确定义，该路线图将导致最终交付产品。

最终，瀑布被认为对软件开发有害且违反直觉，因为通常，直到项目周期的最后才确定价值，而且在许多情况下，项目失败了。此外，直到项目结束，客户才可以看到任何有效的软件。

敏捷采取了一种不同的方法，该方法从计划整个项目，承诺估计日期以及对计划负责开始。而且，敏捷假定并包含不确定性。它建立在响应变化的想法之上，而不是超越变化或忽略变化的需求，更改被视为满足客户需求的一种方式。

敏捷价值观

敏捷受《敏捷宣言》的约束，该宣言定义了12条原则：

1.让用户满意是重中之重

2.即使在开发后期，也欢迎不断变化的需求

3.高频度交付软件

4.开发与业务必须携手合作

5.让有上进心的人建立项目

6.面对面交流是传达信息的最有效方法

7.成功的主要衡量标准是运行软件

8.敏捷过程促进可持续发展

9.持续关注卓越的技术和良好的设计

10.简洁至关重要

11.最好的架构，需求和设计来自自组织团队

12.定期反思工作，然后调整和改变行为

敏捷的四个核心价值是：

   个人与流程和工具之间的互动

   运行软件胜于完整的文档

   客户合作而非合同谈判

   响应计划变更

这与瀑布开发的刚性规划风格形成鲜明对比。在敏捷中，客户是开发团队的成员，而不是仅在开始时设置业务需求时才参与，而在结束时检查最终产品时才参与（例如瀑布开发）。客户帮助团队编写验收标准，并在整个过程中保持投入。此外，敏捷还需要整个组织范围内的变革和持续改进。开发团队与其他团队合作，包括项目管理办公室和测试人员。完成的工作和何时完成的工作由指定的角色领导，并由团队整体同意。

敏捷软件开发

敏捷软件开发需要自适应计划，渐进式开发和交付。许多软件开发方法，框架和实践都属于敏捷框架，包括：

Scrum

看板（可视工作流程）

XP（极限编程）

Lean

开发运维

功能驱动开发（FDD）

测试驱动开发（TDD）

Crystal

动态系统开发方法（DSDM）

自适应软件开发（ASD）

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

Scrum是一个框架，在这个框架下，通常由Scrum负责人，产品所有者和开发人员组成的团队可以跨职能并以自我指导的方式进行运作，以提高软件交付和交付的速度。

为客户带来更大的商业价值。重点是具有较小增量的更快迭代。

看板是一种敏捷框架，有时也称为工作流管理系统，可帮助团队可视化其工作并最大化效率（因此变得敏捷）。看板通常由数字或物理板代表。团队的工作随着进度的进行而全面发展，例如，从没有开始到进行中，一直到测试，完成。看板允许每个团队成员随时查看所有工作的状态。

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绝不是对抗性的（或者至少没有意图）。在敏捷革命中，他们相同之处多于敌对。敏捷和DevOps可以排他性和包容性地运行，这使两者都可以存在于同一空间中。

两者之间的差异在于开发后会发生什么。

早期，软件开发并不真正使用特定的管理框架。然后是瀑布开发方式，它提出了一个想法，即可以通过应用程序创建或构建所花费的时间来定义软件开发。

那时，创建，测试和部署软件通常要花费很长时间，因为在开发过程中没有制衡手段。结果是软件质量差，存在缺陷，错误和未满足的时间表。重点在于软件项目是长期计划。

瀑布开发项目已与三重约束模型关联，该模型也称为项目管理三角形。三角形的每一边代表项目管理三重约束的一部分：范围，时间和成本。正如安吉洛·巴雷塔（Angelo Baretta）所写，三重约束模型“说成本是时间和范围的函数，这三个因素以定义和可预测的方式相关... [如果要缩短时间表（时间），我们必须增加成本。它说，如果我们想扩大范围，就必须增加成本或进度。”

从瀑布过渡到敏捷

瀑布来自制造和工程，其中线性过程才有意义。在建造屋顶之前先建造墙壁。同样，软件开发问题被视为可以通过计划解决的问题。从头到尾，开发流程均由路线图明确定义，该路线图将导致最终交付产品。

最终，瀑布被认为对软件开发有害且违反直觉，因为通常，直到项目周期的最后才确定价值，而且在许多情况下，项目失败了。此外，直到项目结束，客户才可以看到任何有效的软件。

敏捷采取了一种不同的方法，该方法从计划整个项目，承诺估计日期以及对计划负责开始。而且，敏捷假定并包含不确定性。它建立在响应变化的想法之上，而不是超越变化或忽略变化的需求，更改被视为满足客户需求的一种方式。

敏捷价值观

敏捷受《敏捷宣言》的约束，该宣言定义了12条原则：

1.让用户满意是重中之重

2.即使在开发后期，也欢迎不断变化的需求

3.高频度交付软件

4.开发与业务必须携手合作

5.让有上进心的人建立项目

6.面对面交流是传达信息的最有效方法

7.成功的主要衡量标准是运行软件

8.敏捷过程促进可持续发展

9.持续关注卓越的技术和良好的设计

10.简洁至关重要

11.最好的架构，需求和设计来自自组织团队

12.定期反思工作，然后调整和改变行为

敏捷的四个核心价值是：

   个人与流程和工具之间的互动

   运行软件胜于完整的文档

   客户合作而非合同谈判

   响应计划变更

这与瀑布开发的刚性规划风格形成鲜明对比。在敏捷中，客户是开发团队的成员，而不是仅在开始时设置业务需求时才参与，而在结束时检查最终产品时才参与（例如瀑布开发）。客户帮助团队编写验收标准，并在整个过程中保持投入。此外，敏捷还需要整个组织范围内的变革和持续改进。开发团队与其他团队合作，包括项目管理办公室和测试人员。完成的工作和何时完成的工作由指定的角色领导，并由团队整体同意。

敏捷软件开发

敏捷软件开发需要自适应计划，渐进式开发和交付。许多软件开发方法，框架和实践都属于敏捷框架，包括：

Scrum

看板（可视工作流程）

XP（极限编程）

Lean

开发运维

功能驱动开发（FDD）

测试驱动开发（TDD）

Crystal

动态系统开发方法（DSDM）

自适应软件开发（ASD）

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

Scrum是一个框架，在这个框架下，通常由Scrum负责人，产品所有者和开发人员组成的团队可以跨职能并以自我指导的方式进行运作，以提高软件交付和交付的速度。

为客户带来更大的商业价值。重点是具有较小增量的更快迭代。

看板是一种敏捷框架，有时也称为工作流管理系统，可帮助团队可视化其工作并最大化效率（因此变得敏捷）。看板通常由数字或物理板代表。团队的工作随着进度的进行而全面发展，例如，从没有开始到进行中，一直到测试，完成。看板允许每个团队成员随时查看所有工作的状态。

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绝不是对抗性的（或者至少没有意图）。在敏捷革命中，他们相同之处多于敌对。敏捷和DevOps可以排他性和包容性地运行，这使两者都可以存在于同一空间中。