敏捷和 DevOps 如何相互关联？

当我们提到敏捷和DevOps的概念时，经常会觉得它们存在模糊之处，这是因为它们都有自己的术语和口号，两者之间的界限不够清晰，导致出现了一定程度的重合。然而，过度简化敏捷为Scrum、DevOps为持续交付的认识是不准确的，这种简化会导致敏捷和DevOps之间出现不必要的紧张感。

实际上，敏捷和DevOps之间存在着历史关联，当Patrick DuBois和Andrew Clay Schafer在2008年的敏捷大会上试图将敏捷基础架构与DevOps联系起来时，这种关联就开始了。尽管Patrick后来创造了“DevOps”一词，但敏捷大会仍推崇这种与DevOps的关联。因此，我们需要透过Scrum和持续交付的表面，深入了解敏捷与DevOps之间的实际联系。

敏捷性远不止是 Scrum

对于某些团队而言，采用Scrum方法可以提高工作效率和工作成果的质量，而否则会可能会陷入无休止的繁琐和痛苦之中。对于另一些团队，Scrum方法则有助于客观和专注的工作方式取代政治上的斗争和过度投入，并被视为一种信条而被广泛接受。当业务限制或工作本身有特殊需求时，敏捷团队会利用Scrum原则，检查自己的具体做法，并做出调整以提高工作效率。特别是当Scrum应用于软件开发环境之外时，这一点显得尤为重要。

规划计划外的工作

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

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

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

产品负责人和服务负责人

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

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

DevOps 远不止是持续交付

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

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

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

三种方法

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

名列前茅种方法	系统思维	重视整个系统的表现，而不是特定工作团队或部门（大至部门、小至个人贡献者）的表现。
第二种方法	扩大反馈回路	创建从右到左的反馈回路。所有过程改进举措的目标都是缩短和扩大反馈回路，以便持续执行必要的改正。
第三种方法	不断试验和学习的文化	营造能够促进两个方面的文化：不断试验、冒险并从失败中学习；了解重复和实践是达到卓越的前提条件。

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

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

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

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

DevOps 是指将敏捷运用到软件团队之外

Scrum 主要对应”欣然面对需求变化，即使在开发后期。敏捷过程能够驾驭变化以保持客户的竞争优势“这一敏捷原则。持续交付主要对应”我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意“这一敏捷原则。这表示敏捷更注重接受传入和传出的变化，而不是站立会议和 Sprint 规划等仪式。实际上，敏捷宣言中还包含另外 10 条原则。您不应该在这些原则当中进行取舍，而应该将它们视为一个整体。这些原则共同代表着敏捷和 DevOps 共有的对于变化的态度。

DevOps 寻求将敏捷对待变化的态度带给全新的受众：IT 运维人员。#DoDevOps

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

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