DevOps是敏捷在软件开发团队的另外一应用。那么相比之下，哪一个更胜一筹？编程
一边，有业界承认的scrum master，它的朋友极限编程者，以及由其衍生的 LeSS、SAFe、DAD等，是敏捷。安全
另外一边，有精益文化机器，用代码持续交付其基础架构，它的名字左边是开发，右边是运维，合起来就是DevOps。markdown
虽然我已尽我所能在普及这两个概念，但人们关于敏捷和DevOps的争论依然让它们听起来彻底不一样。更糟糕的是，尽管他们都已经有了各自的行业术语和口号，但二者的概念仍是没办法准肯定义。鉴于敏捷诞生早于DevOps ，因此它的定义也相对清晰一些，但DevOps五花八门的定义仍然让不少人都很困惑。而正是由于两者都缺少准确的定义，因此致使人们常常会有一些误解。架构
不少人认为敏捷等于scrum，DevOps等于持续交付。过分简化的理解让敏捷和DevOps之间造成了没必要要的对峙，但最终你会惊讶地发现两者实际上是很是好的朋友！运维
毫无疑问DevOps和敏捷之间的联系由来已久。在2008敏捷大会上，Patrick DuBois和Andrew Clay Schafer尝试创建两者之间的关系并提出“敏捷架构”这一律念，这时，敏捷与DevOps之间的关系就已初现端倪。尽管Patrick后来提出了“DevOps”一词，但敏捷大会依然被追溯为DevOps的起点。因此咱们不妨透过Scrum和持续交付的表面，深刻了解两者的历史，来思考一下敏捷和DevOps之间还存在哪些关联。工具
1、敏捷毫不仅仅是Scrum
某些团队中，scrum让团队工做介于一成不变、苦苦挣扎和量产、高回报之间。还有一些团队，scrum用客观和聚焦代替主观和过分承诺。咱们也能够把它视为一种教条。当业务收到限制或工做自己须要作出改变的时候，敏捷团队将利用scrum的基本原则，审视自身的工做并作出更有效的调整。尤为是当scrum应用于软件开发环境以外的业务时，这点尤其重要。性能
提早规划计划外的工做
在DevOps社区，有敏捷经验的人都以为scrum可以有效追踪计划中的工做。一些正在运行中的工做能够被计划：如发布一个重大系统变动、切换数据中心或系统升级等。但在运行中大多数事情是没办法计划的：如性能到达峰值、系统中断或安全问题等。这些突发事件都须要快速作出反应。没时间等到把这些事项在backlog中肯定优先级后再作或放到下个sprint规划会议中处理。正因如此，不少团队开始慢慢接受DevOps思想，Scrum以外再引入Kanban。这样使得团队能够同时追踪两种类型的工做，帮助他们理解二者之间的联系。或者，他们采起了一种综合方法，叫作Scrumban 或 Kanplan （也就是有backlog的看板）。学习
在很大程度上，scrum得以普遍应用的关键可能在于它不对技术方法设限。Scrum做为轻量级管理方法，每每能为团队带来巨大变化。以前，可能会有来自多个master的优先事项互相竞争，但在scrum中，backlog中只会存在一组优先事项。以前，团队中可能会存在同时推动不少工做的状况，而如今取而代之的是一个在限定时间内能够完成的工做计划。综合来看，这些均可以将团队的生产率带到一个新的水平。然而，团队可能会因技术实践的缺少而受到限制，如代码审查、自动化验收测试、持续集成。测试
其余敏捷方法如极限编程，也对技术如何使团队保持可持续交付节奏并向管理层和利益相关者提供透明度和可见性提出了明确要求。一些Scrum团队倾向于将研发任务放在backlog中。虽然这在scrum的指导下适应得很好，但很快就会遇到Product Owner对产品功能的偏向性问题。除非Product Owner的技术能力很强，不然TA可能没法评估技术的成本或收益。尤为是当技术任务延伸到运维、可靠性支持、性能、安全性等方面时，对Product Owner来讲更加困难。设计
Product Owner 和Service Owner
在Worktile，咱们认识到，为咱们运营的产品设置两个不一样角色颇有必要。Product Owner善于理解用户的功能性需求，但可能并不擅长权衡产品功能与性能、可靠性和安全性等非功能性功能之间的优先级。所以，一些SaaS产品也配备了Service Owner角色，负责肯定前述非功能性功能的优先级。尽管两个角色常常须要讨价还价，但大部分状况下，独立的团队均可以自行完成这两个角色的任务。虽然这并非“强化反馈”的惟一方法，但确实可以克服Product Owner对产品功能中比较常见的偏见问题。但设置‘两个Owner’并不是实现DevOps的惟一途径。重要的是将非功能性特征理解为“功能”，并将它们像功能性的用户故事同样，进行规划和优先级排序。
在DevOps成为主流前，不能肯定scrum天然发展的结果必定是DevOps。
敏捷方法中，Scrum有一个内在的“过程改进”机制，叫作回顾会议。所以，咱们有理由相信一些scrum团队会想用DevOps做为灵感来源，用scrum回顾会议做为向DevOps方向调整的契机。然而，事实让咱们意识到大多数团队须要注入外部思想。在DevOps成为主流前（哪怕成为学校必学内容），咱们不能肯定scrum天然发展的结果必定是DevOps。团队究竟是有敏捷教练仍是DevOps教练参与并不重要，只要他能给团队带来在构建、测试、部署等方面的自动化经验便可。
2、DevOps也不只限于持续交付
若是应用得当，持续交付的规则能够有效限制在制品数量，而部署的自动化有助于打破工做局限。经过这样的方式，持续交付让软件开发团队频繁交付更高质量的产品，而没必要在两者之间抉择。然而，正如仅专一于scrum的团队可能会忽视更普遍的敏捷环境那样，仅专一于持续交付的团队也会错过更普遍的DevOps环境。
持续交付实践并不能直接解决业务部门和开发团队之间的沟通问题。若是业务部门设定了一个为期一年的预算驱动计划，那么产品交付团队每次交付产品后都须要等待数月才能获得业务部门给的反馈。而这些反馈一般都是一些影响后续工做的步骤性功能，像取消项目或者更糟糕的是须要扩充项目团队（由于大量涌入新人会影响团队已有的稳定性）。
敏捷流畅度模型将“价值聚焦”视为流畅度的第一层级，即团队须要注重透明度和一致性。若是价值不聚焦，持续交付很容易陷入技术改进的无限死循环而没法向业务交付可观的价值。团队可能擅长快速高质量的交付，但就产品自己而言，可能对终端用户或者企业来讲几乎没有价值。即便不少用户给出了较好的评价，但从较大的业务组合层面来看可能就会评估为低价值。所以，没有价值聚焦这一重要流畅度，团队很难在技术和功能之间权衡取舍。
这点对于有遗留代码库的团队来讲尤其重要，由于遗留代码库可能没有自动化测试或适合频繁部署的设计。在一个遗留环境中，持续交付转换可能须要数年的时间。所以，证实产品的商业价值就显得尤其重要。
三种方法
DevOps不只仅是自动化部署流水线。换句话说，DevOps方法要求“运维人员（Ops）可以像开发人员（Devs）那样思考，而开发人员（Devs）也要像运维人员（Ops）那样思考。” 如下是这一观点的进一步阐述以及可做为DevOps原则的三种方法：
第一种：系统思惟
强调整个系统的性能，而不是特定的工做孤岛或部门的性能——这个系统能够大到涵盖整个业务部门，小到仅包括单个工做项。
第二种：扩大反馈循环
建立全流程的反馈循环。几乎全部过程改进计划的目的都是为了缩短并强化反馈循环，以确保能够不断进行必要的修正。
第三种：不断实践和学习的文化
塑造一种聚焦在这两件事上的文化：不断实践、敢于冒险并从失败中学习经验；要明白重复和实践是熟练掌握的先决条件。
持续交付侧重于第一种方法： 即实现从开发到运维的自动化流程。自动化在加快系统部署上的做用很是明显，但系统思惟毫不止于自动化。
第二种方法的突出特色是实践， 即“开发人员也要随身携带传呼机”。虽然开发人员不必定真的要随身携带传呼机作到随叫随到，但他们也须要积极参与到运维工做中。这样能让开发人员了解到他们开发过程当中所作选择带来的后续影响。例如，这样作能让开发人员将本身的日志消息存放到更好的位置让它们发挥更大的做用。开发人员不只仅要了解运维工做，还要结合本身对系统的理解作一些故障排除的工做，这样能够更快地找到并实施解决方案。
第三种方法强调在整个系统中进行增量实验，而不只仅是应用程序在流水线中移动的变化。 换句话说，看出自动化所需的时间并用日益强大的基础设施来不断改进它相对来讲是比较容易的。而要清楚的知道角色或企业之间的交接如何致使延期是比较困难的。这意味着团队要“检查和调整”整个交付工做流，寻找能够提高人员协做效率的点。对于这个问题，持续交付要求团队养成不断适应和改进的习惯。若是团队历来不去思考如何变得更高效，并付诸行动去调整和改善，那么持续交付也没法持续发展和完善。团队要相信本身有能力解决本身的问题。
在scrum中，每次回顾会议都是一次改进实践和工具的机会。但若是团队没有抓住这些机会解决短时间和长期的技术问题，他们就无异于坐等Product Owner将持续交付任务放到他们的backlog中，而事实上，Product Owner永远不会这么作。
DevOps是敏捷在软件开发团队以外的应用
Scrum主要遵循“欣然面对需求变化，哪怕变动出如今开发后期。敏捷过程正是利用变化来帮助客户取得竞争优点”这一敏捷原则。
而持续交付遵循的敏捷原则是：“咱们的首要任务是经过尽早、持续地交付有价值的软件，来知足客户的需求”。
这意味着敏捷更强调输入和输出的变化，而不是每日站会和sprint规划会等仪式。事实上，《敏捷宣言》中还有另外10条原则。咱们应该将它们视为一个总体，而不是从中选择某些原则。由于这些原则合起来表明的是敏捷和DevOps对变动的态度。
DevOps旨在将敏捷关于变动的态度应用到新的领域：IT运维。
这些人一直在运行对于企业来讲很是重要但同时又很是脆弱的系统。也正是由于它的重要性，因此也最迫切须要得以改进。所以，这里敏捷强调的变化并非“为了改变而改变”。是为了让开发对其变动质量负责，同时提升总体交付商业价值。而这种对商业价值的关注是敏捷和DevOps的另外一个共通点。
最后，敏捷和DevOps自己并非业务指标。它们都是能够激励组织用更好的方法实现目标的企业文化。将敏捷和DevOps结合起来使用能取得更好的效果。而避免这两种文化发生冲突的诀窍就是要理解构成它们的更深层次的价值观和原则。武断而狭隘的定义会禁锢思惟。相信看完本文，你已经知道敏捷不只限于scrum，而DevOps也不只限于持续交付。那么接下来，你就能够尝试强大的Agile + DevOps组合了。
文章来源：Worktile敏捷博客