Agile和DevOps：朋友还是敌人?

内容来源：DevOps社区Meetup
原作者：IAN BUCHANAN
原文网址：https://www.atlassian.com/agile/devops
译者：王子建朱露露
审校：王英伟

Agile和DevOps:朋友还是敌人?
Agile比Scrum拥有更多
计划外的工作
产品负责人和服务负责人
DevOps的意义不仅仅在于持续交付
三个层次
DevOps 就是应用在不同团队之间的 Agile

Agile和DevOps:朋友还是敌人?

DevOps和Aglie的应用范围超出了软件团队。但真正的问题是，在这场竞争中，谁会赢?

在一个角落里，我们有一位合格的Scrum Master，他的朋友们称为Extreme Programmer，而他的孩子们则称为LeSS SAFe DAD ...Agile！

在另一个角落，我们有精益文化设施，他一直坚持基础设施即代码的理念，他被看作开发人员和运维人员的左右手）.. DevOps！

尽管我一直强调，关于Agile和DevOps的言论，可能使它们听起来好像完全不同。尽管这两个概念都有自己的行话和标语，但似乎都违反了定义，使两者很容易混淆。作为先驱者，Agile也许不那么模糊，但是人们对于无数的DevOps定义，普遍感到沮丧。缺乏定义导致了一些常见的混淆。

许多人认为Agile意味着Scrum，而DevOps意味着持续交付。这种过于简单的做法在Agile和DevOps之间造成了不必要的紧张，其实你可以惊讶地发现它们是最好的朋友！

不可否认 DevOps和Agile之间的历史联系。当Patrick DuBois和Andrew Clay Schafer试图在有关“Agile基础设施”的Agile2008年会议上建立连接时，Agile与DevOps的连接就诞生了。尽管Patrick后来创造了“DevOps”一词，但Agile会议继续以DevOps track来纪念这种联系。但是，让我们深入了解历史，在我们深入研究Scrum和Continuous Delivery的表面时，考虑一下Agile与DevOps之间的实际联系。

Agile比Scrum拥有更多

在某些团队中，Scrum与不进行改变的协作方式的区别在于：Scrum更有利于团队之间的合作,而不改变的协作方式只会让人越来越沮丧。在另一些情况下，Scrum用客观和专注代替了政治和过度承诺。它也可以被当作教条。当业务与工作本身的约束条件有所不同时，Agile团队将利用Scrum的基本原理，然后检验其实践，并变得更加有效。当Scrum在软件开发范围之外应用时，这一点尤其重要。

计划外的工作

在DevOps社区中，具有Agile经验的人承认Scrum对于跟踪计划的工作很有用。可以计划一些运行中的工作：发布大型系统变更，迁移数据中心或执行系统升级等。但是，许多运维工作是计划外的：性能峰值，系统中断和安全性受到威胁。这些事件需要立即响应。没有时间等待项目在待办事项列表中，进行优先级排序或等待下一个sprint计划会。因此，许多团队开始接受DevOps的思考，不仅仅是Scrum,还有看板。这有助于他们跟踪两种工作方式，并帮助他们了解Scrumban和Kanplan之间的相互作用。或者，他们采用一种混合方法，通常称为Scrumban或 Kanplan（带有待办事项的看板）。

在许多方面，Scrum广泛采用的关键可能是它没有规定任何技术实践。Scrum的轻量级管理实践通常会对团队产生重大影响。曾经有来自多个方面的需求竞争优先级，现在待办事项列表中只有一组优先级。在曾经有太多工作要做的地方，现在有了一个受时间制约并切实可行的计划。结合起来，这些可以使团队的生产力提高到新的水平。但是，团队可能会发现自己因缺乏技术实践而受到限制，例如编码审查、自动验收测试和持续集成。

其他Agile过程，比如极限编程，对于技术实践如何支持团队能力，以保持可持续的进度，并为管理层和干系人提供透明度和可预见性有着明确的看法。一些Scrum团队倾向于将技术任务放入backlog中。虽然这很适合Scrum的指导，因为它很快就会解决产品负责人偏爱功能的实际问题。但是,这需要产品负责人的技术水平很高，否则他们可能不具备评估技术实践的成本/收益的能力。对于产品负责人而言，这变得更加困难，因为技术任务已经扩展到支持可靠性，性能和安全性的操作中。

产品负责人和服务负责人

在Atlassian，我们认识到在我们维护的产品中，扮演两个不同的角色会有所帮助。我们的产品负责人善于理解用户所需的功能，但不擅长将这些功能与非功能性功能（如性能，可靠性和安全性）进行权衡。因此Atlassian的某些SaaS产品负责人与服务负责人，负责对那些非功能性功能进行优先级排序。两位所有者有时可能需要做一些妥协，但是在大多数情况下，这可以由独立团队进行。这可能不是从操作中“放大反馈”的唯一方法，但它确实有助于克服产品所有者在功能方面普遍存在的偏见。这种“两个所有者”的方法并不是通往DevOps的唯一途径。

在DevOps成为主流之前，它不是Scrum的必然发展结果。

最终，这些对Scrum的批评并没有依据Scrum固有的特征。与所有Agile方法一样，Scrum具有内置的“流程改进”机制，称为回顾。因此，有理由相信一些Scrum团队将借鉴DevOps作为灵感来源，并利用Scrum回顾作为契机来调整和适应DevOps。但是，要意识到大多数团队都需要注入一些外部想法，这很实用。在DevOps成为主流（甚至在学校教书）之前，DevOps不是Scrum的必然发展结果。团队是否聘请Agile或DevOps教练可能并不重要，只要该人可以在构建、测试和部署软件方面带来自动化方面的经验即可。

DevOps的意义不仅仅在于持续交付

如果做得好，持续交付（CD）的原则将有助于限制在制品，而部署的自动化则有助于提高约束。这样，CD可以帮助软件团队更频繁地交付更高质量的产品，而不必在两者之间进行选择。但是，就像只专注于Scrum的团队可能会错过Agile的更广泛背景一样，专注于持续交付的团队也可能会错过DevOps的更广泛的背景。

敏捷成熟度模型将成熟度的第一级表示为“关注价值”，团队专注于透明度和一致性。如果没有这种成熟度，CD可能很容易演变为无止境的技术改进循环，对企业没有任何可观的价值。团队可能擅长以高质量快速交付产品，但对于最终用户或企业而言，产品的价值却不高。即使有许多用户说好话，也只能在较大的业务组合级别进行低价值评估。没有这种重要的成熟度，就很难权衡技术实践和功能。对于拥有传统代码库的团队而言，这尤其重要，因为他们可能没有自动测试或不适合频繁部署的设计。在传统情况下，CD转换可能需要数年时间。所以，能够展示商业利益就更加重要了。

三个层次

DevOps 不仅仅是部署流水线的自动化。以 John Allspaw 的话来说，DevOps 就是“运维像开发一样思考，开发像运维一样思考”。借鉴了这种思路，Gene Kim 将 DevOps 的原则表述为以下三个层面：

持续交付（CD）关注第一层次：从开发到运维的工作流程自动化。显而易见，自动化在快速部署系统方面占有举足轻重的地位。但系统化思考远远不止自动化这么简单。
第二层次的特点是实践。“开发也应该装配传呼机（随时待命，译者注）”。尽管没有必要真的装配传呼机，但是这需要开发也参与到运维的问题中来。这能帮助开发人员理解他们不同部署方式的结果。比如，这能启发开发人员将日志内容写入到更合适的地方，从而使日志更具有意义。第二层次不光影响开发的运维意识，开发也需要利用他们对系统的深入理解来解决问题，以便能够快速制定和实施解决方案。
第三层次着眼于在系统中不断地尝试。这些尝试应当被视作一个整体，而不仅仅是单个的对于某个应用的变更。换句话说，观测自动化任务运行的时间并且通过优化基础设施来提高自动化效率是比较容易的，然而不同角色、组织之间由于工作交接带来的延期却很难衡量。这便是团队在整个产品交付流程中的“自检和改进”，寻找机会提高人员之间的协作能力。因此，持续交付要求团队有不断改进和提高的习惯。如果团队不去反省如何变得更高效，反而关注在其他的事情上，持续交付过程将无法发展和进步。团队需要自主地解决自己的问题。

在 Scrum 中，每次复盘都是一次机会来优化团队实践和工具。如果团队不利用这些机会来解决短期或者长期的技术问题，他们只能等着产品负责人把持续交付相关的人物丢到任务清单里，然后再也不会提上日程。

DevOps 就是应用在不同团队之间的 Agile

Scrum 与这个 Agile 原则如出一辙，“欢迎需求变更，哪怕已经开发过半。利用Agile 流程管理变更，实现客户的竞争优势。”

持续交付则与这个 Agile 原则殊途同归，“我们的重中之重就是通过快速、持续地交付有价值的软件来满足客户的需求。”

这意味着 Agile 更关注拥抱即将到来和已经发生的变化，而不是站会、冲刺计划之类的形式。事实上，Agile宣言中还有其他 10 个原则。与其从这些原则中做选择，我们更应该把它们视为一个整体。这些原则共同展现了一种对待变化的态度，这对于 Agile 和 DevOps 来说都是适用的。

DevOps 寻求把 Agile 对于变化的态度引入到 IT 运维中来。

长久以来，IT 运维工程师囿于运维那些对于业务来说至关重要却又极其脆弱的系统。正因他们对业务来说至关重要，因此他们成为了最迫切最急需改变的一个角色。这些 Agile 里关于拥抱变化的思想并不是“为了变化而变化”，它要求开发人员对其变更的质量负责，以此达到提高综合能力生产业务价值的目的。关注业务价值是另一个 Agile 和 DevOps 中共有的内容。

综上，Agile 和 DevOps 都不是业务目标。两者都是一种能够激发你的组织用更好的方式实现目标的文化运动。Agile 和 DevOps 实友非敌，同心合力才能取得更好的效果。理解 Agile 和 DevOps 里更深层次的价值和原则可以帮助避免两种思想中的冲突。急功近利、思路狭隘和定式思维会导致闭门造车。至此，你已经知道了 Agile 不仅仅只是 Scrum，而 DevOps 也不只是持续交付，想必你已经准备好去尝试 Agile + DevOps 的强大组合技了！

金九银十，IDCF【冬哥有话说】10月特别邀请到3位来自银行的嘉宾，分享民生银行、中信银行、工商银行的DevOps探索与实践。

今晚8点，【冬哥有话说之金九银十】邀请到民生银行信息科技部APaaS和DevOps平台负责人胡稳安老师分享《从0-1搭建金融行业企业级DevOps云平台》，识别下图二维码回复“金九银十”即可获取直播地址~

Agile和DevOps：朋友还是敌人? | IDCF