DevOps可以看作是敏捷运动的延续，引入更多的概念和实践，将软件交付的方法论拓展到更广泛的领域。
DevOps 基于敏捷、精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优 化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。
敏捷运动起源于2000年前后，起因是软件行业的思想领袖们越发觉得瀑布模型已经无法适应软件发布的要求。敏捷宣言发布于2001年：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷的12条原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
随后发展出多种敏捷模型以取代瀑布模型，包括XP、Scrum、Lean、Kanban、TDD等，今天(2020年)我们使用的敏捷模型更像是以Scrum为主，结合了多种模型的实践，最终形成的混合体。
精益理论起源于丰田制造系统(TPS)，TPS经过多年的发展，推出大量的工具和实践，影响了整个汽车工业，并在制造行业得到广泛推行。 在敏捷运动的早期，精益管理就被引入到软件开发领域，发展出精益软件开发的敏捷模型。在《精益软件开发》中，Mary和Tom Poppendieck定义了精益开发七条原则：
- Eliminate waste
- Build quality in
- Create knowledge
- Defer commitment
- Deliver fast
- Respect people
- Optimize the whole
这七条原则来自TPS，并结合了软件行业的特点，用精益的方式看待和改善软件交付，为我们提供了基本的思路。此外，精益制造理论中的单件流、改善套路、可见性、价值流等工具也同样适用于软件开发领域，为快速高质量的交付提供更多理论基础。
约束理论（Theory of Constraints, TOC）是以色列物理学家、企业管理顾问戈德拉特博士(Dr．Eliyahu M．Goldratt)在他开创的优化生产技术(Optimized Production Technology，OPT)基础上发展起来的管理哲理，该理论提出了在制造业经营生产活动中定义和消除制约因素的一些规范化方法，以支持连续改进(Continuous Improvement)。TOC两个核心基础是：
- 系统化思维
- 一切阻碍皆约束 TOC的五大关键实施步骤：
- 识别系统的约束点
- 决定如何利用这个约束
- 考虑全局优化
- 改善系统约束
- 如果约束已经突破，回到第一步
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。[1]
DevOps的目标非常清晰，快速高质量地交付。为了达到这个目标，DevOps引入了很多的概念，可以从几个方面去理解--思维、文化、方法和技术。
Culture Automation Lean Measurement Sharing
Culture Process Tool
为了减少不必要的误解，这里有个DevOps认知误区列表，供各位参考：
- DevOps重点在自动化，只跟工具有关。
- DevOps只强调开发和运维的协作。
- DevOps是开发和运维的协调器，由双方的代表组成。
- DevOps是一个团队。
- DevOps是个职位。
- 你需要DevOps证书。
- DevOps只适合互联网企业。
- DevOps意味着缩减人力。
- 只有一种DevOps方法。
- 实施DevOps需要经历几个星期或几个月。
- DevOps很时髦。