文：姚冬（华为云DevCloud首席技术布道师，资深DevOps与精益/敏捷专家，金融解决方案技术Leader，中国DevOpsDays社区核心组织者）
前言
敏捷是什么？DevOps是什么？两者有什么区别？
持续集成不是XP里面的么，怎么DevOps也有持续集成？
我们之前在做敏捷转型，现在又开始DevOps转型，到底啥情况？
总觉得与其去纠缠一个定义，不如踏踏实实做点儿事情。
没必要太纠结，因为两者都在演进，两者也越来越像，否则不会有这些疑问。
原本没想写这个话题，客户问起也只是简单说明。
只是最近不断有人问起，也看到有一些误导性的言论，所以也许还是有必要说说自己的观点。
这个话题注定讨论不清，也注定会有不同的意见；
所有文字仅代表我一家之言，没必要扣什么帽子；
我本人是先做敏捷后做DevOps的，这是我的知识背景；
欢迎讨论，如果初衷是好的话，道理越辩越明；
恕不奉陪，如果是以混淆视听为目的论战。
观点
先说我的观点：
敏捷与DevOps初衷，目的是为了解决问题，不是为了树碑立牌，更不是为了占领地盘。
两者并非泾渭分明，也没有一条线能够划出来，说哪边是敏捷，哪边是DevOps。
讨论敏捷与DevOps，目的是为了了解两者之间的内在联系，而不是为了划清界限。
常常在讨论的，是狭义的敏捷与DevOps概念，而广义的敏捷与DevOps，已经趋同。
两者都是试图去解决相同，或相近的问题，只是革命尚未成功，同志还需一起努力。
傻傻不分清楚，是不想分太清，没必要分清楚，难得糊涂。
狭义的敏捷和DevOps
狭义的敏捷与DevOps，也许是你想听到的两者区别。
强调一下，这里说的，注意是狭义而不是狭隘；有狭义就有广义，如果你坚持固守狭义的概念，会不会有点儿狭隘了呢？
传统的敏捷是为了解决第一个gap，即业务与开发之间的鸿沟。通过敏捷宣言中强调的个体和互动、可工作的软件、客户合作、响应变化，以及12条原则中的尽早的以及连续的高价值交付、自组织团队、小批量交付、团队节奏、可改善可持续的流程、保持沟通等，以及包括Scrum、Kanban、XP在内的众多管理和工程实践，来实现开发与业务之间的频繁沟通，快速响应变化。
而DevOps的出现，是为了解决图中的第二个gap，即开发与运维之间的鸿沟。前端的敏捷的确是快了，却发现因为Dev与Ops之间的隔阂，无法真正的将价值持续的交付给客户。
开发侧很快，运维侧太稳，这个就是我们常说的开发与运维之间固有的、根因的冲突，即下图中的混乱之墙。开发（尤其是“敏捷”后），求的是快速响应变化；运维，求的是稳定、安全和可靠的服务；更重要的，两者的KPI度量指标，绩效考核激励机制不同，决定了如果为达成各自的局部目标，势必存在无法调和的根因冲突。
DevOps的出现，就是为了打破开发与运维之间的部门墙，从这点上来说，我支持DevOps是敏捷在运维侧的延伸这一说法。只是，敏捷与DevOps，都已经不再是原来的那个敏捷和DevOps了；世界变化太快，问题域发生了变化，解决方案域自然也要随之变化。
广义的敏捷和DevOps
敏捷的好处是，有一个敏捷宣言，宣告其诞生；敏捷的缺点，也许也是因为有敏捷宣言；敏捷宣言并不应该被拿来约束和限制敏捷的范围；敏捷宣言也说拥抱变化，宣言诞生于2001年，时至今日，应该也当然会与时俱进，只是后来再没有这样的一个标志性的事件来做声明。
DevOps的不好之处，是没有一个明确的定义；DevOps的好处，却也正是因为没有一个明确的定义做限制，所以拿来主义，一切好的东西，都可以为我所用。
DevOps是个筐，什么都可以往里装，敏捷又何尝不是呢？（这里全是褒义）
我是2012年在IBM接触到DevOps的概念的，IBM对DevOps有D2O和E2E的概念，D2O，Dev to Ops，即经典、狭义的DevOps概念，解决的是Dev到Ops的鸿沟；E2E，End to End，即端到端、广义的DevOps，是以精益和敏捷为核心的，解决从业务到开发到运维，进而到客户的完整闭环。