比赛的一方是公认的 Scrum 高手、朋友们称之为“极端编程者”，麾下有“LeSS SAFe DAD”等选手...这就是“敏捷”！
Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation.
There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.
对有些团队而言，使用 Scrum，意味着团队工作高效且富有成效；否则，就是没完没了的繁琐，令人痛苦不堪。对另一些团队而言，Scrum 让客观和专注取代了政治和过度投入。还有人将它视为信条而欣然接受。当业务限制或工作本身有特殊需求时，敏捷团队会利用 Scrum 的基本原则，然后检查自己的具体做法，并做出调整以变得更加高效。当 Scrum 应用在软件开发环境之外时，这一点尤其重要。
In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).
In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviews, automated acceptance tests, and continuous integration.
其他的敏捷流程（例如极限编程）则明确规定了技术实践如何支持团队来维护可持续的步伐并向管理层和利益相关方提供透明度和可见性。有些 Scrum 团队采用将技术任务放入待办事项列表的做法。虽然这一做法在 Scrum 的指导范围内非常合适，但很快就会遇到一个现实问题：产品负责人偏向功能。除非产品负责人对技术非常精通，否则其可能无法评估技术实践的成本/收益。随着技术任务延伸至运维领域以支持可靠性、性能和安全性，产品负责人就更难以应对了。
在 Atlassian，我们发现为我们经营的产品设置两个不同的角色是非常有益的。我们的产品负责人擅长了解用户需要的功能，但不擅长在这些功能与非功能特性（如性能、可靠性和安全性）之间进行取舍。因此，Atlassian 为一些 SaaS 产品设置了服务负责人，他们的工作是优先处理这些非功能特性。这两种负责人有时可能需要进行一些“讨价还价的交易”，但大多数时候功能与非功能特性是由独立的团队负责。这可能不是“放大反馈”的唯一方法，但确实有助于消除产品负责人在功能方面极为常见的偏见。这种“双负责人”的方法不是实践 DevOps 的唯一途径。重要的是将这些非功能特性视为“功能”，并向对待功能性用户故事一样，对它们做出规划、确定优先顺序。
归根结底，所有这些对 Scrum 的批评都不是完全由 Scrum 本身所造成的。与所有敏捷方法一样，Scrum 有一个内置的名为“回顾”的过程改进机制。因此，我们有理由相信，有些 Scrum 团队会将 DevOps 作为灵感来源，并利用 Scrum 回顾做出调整，向 DevOps 转型。但是，意识到大多数团队需要吸纳外部想法更简单实用。在 DevOps 成为主流之前（甚至在学校教授之前），DevOps 不会是 Scrum 的必然成果。无论团队是雇用敏捷教练还是 DevOps 教练，只要该教练可以提供软件构建、测试和部署方面的自动化经验，效果都一样。
When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.
The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).
The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.
DevOps 并不仅限于实现部署管道的自动化。用 John Allspaw 的话来说，DevOps 就是“以开发的形式运维，以运维的形式开发”。为了详细阐述这一想法，Gene Kim 将这“三种方法”作为 DevOps 的原则：
|第一种方法||系统思维||emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.|
持续交付 (CD) 侧重于第一种方法：实现从开发到运维的流程自动化。自动化在帮助加快部署系统的速度方面发挥着极大作用。但系统思维远不止自动化。
The Second Way is characterized by the practice, "Devs wear pagers too." Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.
The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.
在 Scrum 中，每一次回顾都是一次改进具体做法和工具使用的机会。但是，如果团队不能利用这些机会解决短期和长期技术问题，那么他们只能等待产品负责人将 CD 任务放入待办事项列表中，而这永远不会发生。
这表示敏捷更注重接受传入和传出的变化，而不是站立会议和 Sprint 规划等仪式。实际上，敏捷宣言中还包含另外 10 条原则。您不应该在这些原则当中进行取舍，而应该将它们视为一个整体。这些原则共同代表着敏捷和 DevOps 共有的对于变化的态度。
这些人员一直努力尝试运行脆弱的系统，这些系统对于企业来说又是最重要的。正因为这些系统对于企业来说最重要，才最迫切需要进行变革。因此，乐于变革的敏捷观念不是“为了变革而变革”，而是让开发对变革质量负责，同时提高综合能力以提供业务价值。侧重业务价值是另一敏捷和 DevOps 均认同的原则。
Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.