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 an 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 were once competing priorities from multiple sources, 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 的指导范围内非常合适，但很快就会遇到一个现实问题：产品负责人偏向功能。除非产品负责人对技术非常精通，否则其可能无法评估技术实践的成本/收益。随着技术任务延伸至运维领域以支持可靠性、性能和安全性，产品负责人就更难以应对了。
At Atlassian, we have recognized that it helps to have two different roles for products we operate. Our product owners are good at understanding the features that users need but they are not so good at weighing those features against non-functional capabilities like performance, reliability, and security. So some SaaS products at Atlassian also have a service owner, responsible for prioritizing those non-functional capabilities. From time to time the two owners may have to do some "horse trading" but most of the time, these can be worked by independent teams. This might not be the only way to "amplify feedback" from operations, but it does help overcome an all-too-common bias in Product Owners about features. This "two-owner" approach isn't the only path to DevOps. What's important is understanding these non-functional characteristics as "features" and being able to plan and prioritize them just like any functional user story.
归根结底，所有这些对 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.
采用 CD 做法无法直接解决企业与软件团队之间的沟通问题。如果企业有一个长达一年的预算驱动的规划周期，那么要将每次提交成果都投入生产环境的团队可能需要等待数月，才能得到企业的回应。而很多时候，这种回应都是大幅度的，如取消项目，或更糟糕的是扩大项目团队（因为新人员的大量流入非常具有破坏性）。
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.|
|第三种方法||不断试验和学习的文化||creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to excellence.|
持续交付 (CD) 侧重于第一种方法：实现从开发到运维的流程自动化。自动化在帮助加快部署系统的速度方面发挥着极大作用。但系统思维远不止自动化。
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.
Connect your tools with automation
Perhaps the biggest challenge working across multiple tools is the constant change of context and the interruption that brings. It can take hours to get back into flow if you get interrupted by a non-code task. For this reason, more and more folks are automating across their git providers and work management tools. Here are three of the most common automation rules
- When a commit is created and the status is ‘To Do’ then transition this issue to ‘In Progress’. Go to rule.
- Transition to ‘done’ when the Pull Request is merged. Go to rule.
- If a build fails in Jenkins, add a comment to Jira and Slack the team. Go to rule.
在 Jira Automation 模板库中，您可以查看这些自动化规则以及另外 100 个规则。