Agile e DevOps: amigos ou inimigos?

DevOps é o Agile aplicado além da equipe de software. Porém, a verdadeira pergunta é: em uma competição, quem vence?

Ian Buchanan Ian Buchanan

Em um extremo, temos o mestre de Scrum certificado, conhecido pelos seus amigos como o "programador extremo" e pelos seus filhos como "LeSS SAFe DAD" (o pai menos seguro)… Agile!

No outro extremo, temos a máquina de cultura Enxuta, que entrega continuamente sua infraestrutura como código, ela deu ao seu braço esquerdo o nome de dev e ao braço direito, ops… DevOps!

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. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

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.

Agile é mais do que Scrum

Em algumas equipes, Scrum é a diferença entre uma luta contínua e frustrante e um trabalho em equipe produtivo e recompensador. Em outras, Scrum substitui políticas e excesso de compromisso com objetividade e foco. Também pode ser adotado como se fosse um dogma. Quando as restrições da empresa ou do trabalho em si exigem algo diferente, uma equipe agile aproveitará os princípios subjacentes do Scrum, então inspecionará suas práticas e as adaptará para tornar-se mais eficiente. Isso é particularmente importante quando o Scrum é aplicado fora do contexto de desenvolvimento de software.

Planejamento para trabalho não planejado

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 reviewsautomated acceptance tests, and continuous integration.

Outros processos Agile, como programação extrema, têm opiniões fortes sobre como práticas técnicas apoiam a habilidade da equipe de manter um ritmo sustentável e proporcionar transparência e visibilidade à gerência e às partes interessadas. Algumas equipes de Scrum recorrem a colocar tarefas técnicas na lista de pendências. Embora isso seja adequado na orientação do scrum, rapidamente bate no problema prático do viés do proprietário do produto em relação a recursos. A menos que o proprietário do produto seja bastante técnico, ele poderá não ter as habilidades para avaliar a relação custo/benefício de práticas técnicas. Isso fica ainda mais difícil para um proprietário de produto conforme as tarefas técnicas estendem-se para operações para dar suporte a confiabilidade, desempenho e segurança.

Proprietários do produto e proprietários do serviço

Na Atlassian, reconhecemos que ajuda ter duas funções diferentes para os produtos que operamos. Nossos proprietários do produto são bons em entender os recursos de que os usuários precisam, mas não são tão bons em equilibrar esses recursos com capacidades não funcionais, como desempenho, confiabilidade e segurança. Assim, alguns produtos de SaaS da Atlassian também têm um proprietário do serviço, responsável por priorizar essas capacidades não funcionais. De tempos em tempos, os dois proprietários podem precisar negociar, porém, na maioria das vezes, isso pode ser feito por equipes independentes. Essa pode não ser a única maneira de "amplificar o feedback" de operações, mas ajuda a superar o viés tão comum em proprietários de produto quanto a recursos. Essa abordagem de "dois proprietários" não é o único caminho para DevOps. É importante entender essas características não funcionais como "recursos" e poder planejá-las e priorizá-las assim como qualquer histórico do usuário funcional.

Em última análise, nenhuma dessas críticas ao Scrum é totalmente inerente ao próprio Scrum. Como acontece com todos os métodos Agile, o Scrum tem um mecanismo de "melhoria de processo" integrado chamado retrospectivas. Assim, é razoável crer que algumas equipes de Scrum aproveitarão DevOps como uma fonte de inspiração e usarão a retrospectiva do Scrum como oportunidade para ajustar e aperfeiçoar no sentido de DevOps. Porém, é simplesmente bom senso perceber que a maioria das equipes precisa de uma injeção de ideias externas. Até que DevOps seja dominante (talvez até ensinado na escola), ele não será um resultado orgânico do Scrum. Provavelmente não importa se a equipe contrata um coach de Agile ou DevOps, desde que essa pessoa possa levar experiência em automação para todo o processo de compilação, teste e implementação de software.

DevOps é mais do que entrega contínua

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.

As três maneiras

O DevOps é mais que apenas automatizar o pipeline de implementação. No mundo de John Allspaw, DevOps refere-se a "Ops que pensa como Devs. Devs que pensa como Ops". Elaborando essa ideia, Gene Kim explica As três maneiras como princípios de DevOps:

A primeira maneira Pensamento de sistema 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.
A segunda maneira Amplificar ciclos de feedback criar ciclos de feedback da direita para a esquerda. A meta de quase qualquer iniciativa de melhoria de processo é reduzir e amplificar os ciclos de feedback para que as correções necessárias possam ser feitas continuamente.
A terceira maneira Cultura de experimentação e aprendizagem contínuas criar uma cultura que promove dois elementos: experimentação contínua, assumindo os riscos e aprendendo com as falhas; e entender que repetição e prática são pré-requisitos da maestria.

 

Entrega contínua (CD) foca na primeira maneira: automatizar o fluxo de desenvolvimento para operação. A automação desempenha uma função óbvia em ajudar a acelerar um sistema de implementação. Porém, pensamento de sistemas é mais do que apenas automação.

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.

Em Scrum, cada retrospectiva é uma oportunidade de melhorar as práticas e as ferramentas. Porém, se a equipe não estiver aproveitando essas oportunidades para resolver problemas técnicos de curto e de longo prazo, ela apenas esperará o proprietário do produto colocar as tarefas de CD na lista de pendências, o que nunca vai acontecer.

DevOps é o Agile aplicado além da equipe de software

O scrum basicamente mapeia para o princípio Agile, "Acolher a mudança de requisitos, mesmo em um estágio avançado do desenvolvimento. Os processos Agile aproveitam a mudança para a vantagem competitiva do cliente."

A entrega contínua mapeia principalmente para o princípio Agile de "Nossa principal prioridade é deixar o cliente satisfeito por meio de entrega rápida e contínua de software útil."

Isso significa que o Agile está mais relacionado a adotar mudanças de entrada e saída do que a cerimônias como reuniões rápidas e planejamento de sprint. Na verdade, há 10 outros princípios no Manifesto do Agile. Em vez de tentar escolher entre os princípios, eles devem ser considerados como um todo. Juntos, esses princípios representam uma atitude em direção à mudança que é comum tanto ao Agile quanto ao DevOps.

Esse pessoal está empacado tentando executar sistemas frágeis que também são os mais importantes para a empresa. Por serem os mais importantes para a empresa, também são os que exigem as mudanças mais urgentes. Assim, essa ideia Agile de acolher a mudança não é "mudança pela mudança". O objetivo é responsabilizar o desenvolvimento pela qualidade das mudanças, ao mesmo tempo melhorando a capacidade geral de produzir valor de negócios. Esse foco no valor do negócio é outro aspecto compartilhado por Agile e 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.

Up Next
Tutorais