敏捷和 DevOps 如何相互关联？

比赛的一方是公认的 Scrum 高手，朋友口中的“极限程序员”，孩子心中的“不安全老爸”... 这就是“敏捷”！

比赛的另一方是精益文化机器人，可持续交付基础架构即代码；左臂负责开发，右臂负责运维... 这就是 DevOps！

尽管我已经尽最大努力去解释，但有关敏捷和 DevOps 的宣传语让它们听起来非常不同。更糟的是，它们都有自己的术语和口号，但两者的概念仍有模糊之处。敏捷出现的时间较早，可能没那么模糊，但人们对 DevOps 领域里的大量定义感到不知所措，是非常寻常的事。界限不明确已经导致二者出现一定程度的重合。

不可否认的是，DevOs 与敏捷之间存在着历史关联。当 Patrick DuBois 和 Andrew Clay Schafer 在关于敏捷基础架构的“2008 年敏捷大会”上试图建立联系时，与 DevOps 的关联就诞生了。虽然 Patrick 之后创造了“DevOps”一词，但敏捷大会仍推崇这种与 DevOps 的关联。但是，让我们抛开历史，透过 Scrum 和持续交付的表面来了解敏捷与 DevOps 之间的实际联系。

对有些团队而言，使用 Scrum，意味着团队工作高效且富有成效；否则，就是没完没了的繁琐，令人痛苦不堪。对另一些团队而言，Scrum 让客观和专注取代了政治和过度投入。还有人将它视为信条而欣然接受。当业务限制或工作本身有特殊需求时，敏捷团队会利用 Scrum 的基本原则，然后检查自己的具体做法，并做出调整以变得更加高效。当 Scrum 应用在软件开发环境之外时，这一点尤其重要。

在 DevOps 领域，拥有敏捷经验的人都认可 Scrum 对于跟踪计划内的工作非常有用。运维中的一些工作确实是计划内的工作：发布重要系统变更、在数据中心间迁移或执行系统升级。但还有很多运维工作是计划外的工作：应对性能高峰、系统中断和安全威胁。我们需要对这些活动立即做出响应，而不是等着将它们优先列入待办事项列表或者在下一次 Sprint 规划活动中提出。因此，很多团队开始采用 DevOps 思维，转而将目光从 Scrum 投向看板。看板让他们能够追踪上述两种工作，并帮助他们了解两者间的相互作用。也有团队采用混合方案，通常称为 Scrumban 或 Kanplan（含待办事项列表的看板）。

从多方面来讲，Scrum 被大范围采用的关键在于它没有规定具体的技术实践。有时，轻度应用 Scrum 的管理实践就能为团队提供巨大的帮助。原来待办事项列表中存在来自多个来源的竞争性优先事项，现在只有一组优先事项；原来有着太多正在进行中的工作，现在的计划里只列出真正可行的时间安排。这些因素组合起来，可将团队的工作效率提升至新的高度。但是，团队可能会发现自己因缺乏技术实践（如编码审查、自动化验收测试和持续集成）而受到限制。

其他的敏捷流程（例如极限编程）则明确规定了技术实践如何支持团队来维护可持续的步伐并向管理层和利益相关方提供透明度和可见性。有些 Scrum 团队采用将技术任务放入待办事项列表的做法。虽然这一做法在 Scrum 的指导范围内非常合适，但很快就会遇到一个现实问题：产品负责人偏向功能。除非产品负责人对技术非常精通，否则其可能无法评估技术实践的成本/收益。随着技术任务延伸至运维领域以支持可靠性、性能和安全性，产品负责人就更难以应对了。

在 Atlassian，我们发现为我们经营的产品设置两个不同的角色是非常有益的。我们的产品负责人擅长了解用户需要的功能，但不擅长在这些功能与非功能特性（如性能、可靠性和安全性）之间进行取舍。因此，Atlassian 为一些 SaaS 产品设置了服务负责人，他们的工作是优先处理这些非功能特性。这两种负责人有时可能需要进行一些“讨价还价”，但大多数时候功能与非功能特性是由独立的团队负责。这可能不是“放大反馈”的唯一方法，但确实有助于消除产品负责人在功能方面极为常见的偏见。这种“双负责人”的方法不是实践 DevOps 的唯一途径。重要的是将这些非功能特性视为“功能”，并向对待功能性用户故事一样，对它们做出规划、确定优先顺序。

归根结底，所有这些对 Scrum 的批评都不是完全由 Scrum 本身所造成的。与所有敏捷方法一样，Scrum 有一个内置的名为“回顾”的过程改进机制。因此，我们有理由相信，有些 Scrum 团队会将 DevOps 作为灵感来源，并利用 Scrum 回顾做出调整，向 DevOps 转型。但是，意识到大多数团队需要吸纳外部想法更简单实用。在 DevOps 成为主流之前（甚至在学校教授之前），DevOps 不会是 Scrum 的必然成果。无论团队是雇用敏捷教练还是 DevOps 教练，只要该教练可以提供软件构建、测试和部署方面的自动化经验，效果都一样。

如果实施得当，持续交付 (CD) 原则有助于限制正在进行的工作，而部署自动化则有助于加强管束。如此一来，CD 可帮助软件团队更频繁地交付质量更好的产品，也就是同时兼顾效率和质量。但是，与那些只专注于 Scrum 而未能在更广泛层面实现敏捷的团队一样，只专注于持续交付的团队，也无法在更广泛的层面实现 DevOps。

采用 CD 做法无法直接解决企业与软件团队之间的沟通问题。如果企业有一个长达一年的预算驱动的规划周期，那么要将每次提交成果都投入生产环境的团队可能需要等待数月，才能得到企业的回应。而很多时候，这种回应都是大幅度的，如取消项目，或更糟糕的是扩大项目团队（因为新人员的大量流入非常具有破坏性）。

“敏捷流畅模型”表明，流畅的第一级是“关注价值”，也就是团队重视透明度和一致性。如果没有这种流畅性，CD 很容易就会陷入无休止的技术改进循环，而这种改进不会给企业带来可观的价值。某个团队可能擅长快速交付高质量，但对最终用户或企业来说价值不高的产品。即使有很多用户称赞，对价值的评判也只能在更大的业务组合级别进行。如果没有这个重要的流畅模型，则很难根据功能来衡量技术实践。这对于以下这类团队尤其重要：拥有传统的代码库，却没有适用于频繁部署的自动化测试或设计。在传统环境中，CD 转型可能需要数年时间。因此，能够展示业务效益就更为重要了。

DevOps 并不仅限于实现部署管道的自动化。用 John Allspaw 的话来说，DevOps 就是“以开发的形式运维，以运维的形式开发”。为了详细阐述这一想法，Gene Kim 将这“三种方法”作为 DevOps 的原则：

持续交付 (CD) 侧重于第一种方法：实现从开发到运维的流程自动化。自动化在帮助加快部署系统的速度方面发挥着极大作用。但系统思维远不止自动化。

第二种方法的特点是“开发人员也收到通知”。虽然不一定随传随到，但这意味着使开发人员也要面对运维问题。这有助于开发人员了解他们在开发中所做决策的后果。例如，可以促使开发人员将日志消息放在更好的位置，并让这些消息更加清晰易懂。当然开发人员不仅仅要具备意识，还应该将他们对系统的内部理解运用到故障排除过程中，以便找到解决方案并快速实施。

第三种方法是在整个系统中进行增量试验，而不只是更改管道中的应用。换句话说，了解自动化的用时并使用功能日益强大的基础架构来保持改进是相对容易的；而了解角色或组织间的交接如何引起延迟比较困难。这意味着，团队要在整个交付工作流中“检查并调整”，寻找改进人员协作的机会。因此，CD 要求团队具有调整和改进的习惯。如果团队不去反思如何提高效率并在方方面面去优化和调整行为，那么 CD 也不会发展壮大。团队需要觉得自己有能力解决自己的问题。

在 Scrum 中，每一次回顾都是一次改进具体做法和工具使用的机会。但是，如果团队不能利用这些机会解决短期和长期技术问题，那么他们只能等待产品负责人将 CD 任务放入待办事项列表中，而这永远不会发生。

Scrum 主要对应”欣然面对需求变化，即使在开发后期。敏捷过程能够驾驭变化以保持客户的竞争优势“这一敏捷原则。

持续交付主要对应”我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意“这一敏捷原则。

这表示敏捷更注重接受传入和传出的变化，而不是站立会议和 Sprint 规划等仪式。实际上，敏捷宣言中还包含另外 10 条原则。您不应该在这些原则当中进行取舍，而应该将它们视为一个整体。这些原则共同代表着敏捷和 DevOps 共有的对于变化的态度。

这些人员一直努力尝试运行脆弱的系统，这些系统对于企业来说又是最重要的。正因为这些系统对于企业来说最重要，才最迫切需要进行变革。因此，乐于变革的敏捷观念不是“为了变革而变革”，而是让开发对变革质量负责，同时提高综合能力以提供业务价值。侧重业务价值是另一敏捷和 DevOps 均认同的原则。

最后，就本身而言，敏捷和 DevOps 都不是业务目标，而是激励组织通过更好的方式实现目标的文化运动。让敏捷和 DevOps 结合起来而不是相互敌对，可以取得更好的效果。要避免这两个概念之间的冲突，秘诀是了解深层价值观以及形成这些价值观所依据的原则。草率且狭隘的定义会导致孤岛思维。现在，您已经知道敏捷性远不止是 Scrum，DevOps 也远不止是 CD，那么您不妨将功能强大的“敏捷 + DevOps”组合在一起。