Agile e DevOps: amigos ou inimigos?

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

Ian Buchanan Ian Buchanan
Buscar tópicos

Em um extremo, temos o  Certified Scrum Master, conhecido por seus amigos como Extreme Programmer e por seus filhos como LeSS SAFe DAD... Agile!

No outro extremo, temos a máquina de cultura Lean, que oferece continuamente sua infraestrutura como código, ele  chamou seu braço esquerdo de dev e seu braço direito de ops... DevOps!

Embora eu tenha levado o exagero a um extremo, o alarido sobre o Agile e o DevOps pode fazer com que eles soem como ideias muito diferentes. Para contribuir com a confusão, os dois conceitos parecem desafiar a definição, apesar de terem os próprios jargões e slogans. Como o mais velho, o Agile pode ser menos vago, mas certamente é comum as pessoas ficarem frustradas com a variedade de definições para DevOps. A falta de definição levou a uma certa confusão comum. 

Muitas pessoas acreditam que Agile significa Scrum e DevOps significa Entrega contínua. Essa simplificação excessiva cria uma tensão desnecessária entre o Agile e o DevOps e, portanto, talvez você fique surpreso em descobrir que eles são melhores amigos!

Não há como negar a conexão histórica entre o DevOps e o Agile. Quando Patrick DuBois e Andrew Clay Schafer tentaram se conectar à Agile 2008 Conference sobre "Infraestrutura do Agile", nasceu a conexão com o DevOps. Embora Patrick depois tenha cunhado o termo "DevOps", a Agile Conference continua a honrar essa conexão com um espaço para o DevOps. Mas vamos mais fundo do que a história e considerar as conexões práticas entre o Agile e o DevOps, ao olharmos sob a superfície do Scrum e da Entrega contínua.

Agile é mais do que Scrum

Em algumas equipes, o Scrum é a diferença entre uma luta constante e frustrante e um trabalho em equipe produtivo e gratificante. Em outras, o Scrum substitui a política e a sobrecarga por objetividade e foco. Ele também pode ser adotado como se fosse dogma. Quando as restrições do negócio ou do próprio trabalho exigem algo diferente, uma equipe Agile alavanca os princípios subjacentes do Scrum e, em seguida, inspeciona suas práticas e se adapta para se tornar mais eficaz. Isso é particularmente importante quando o Scrum é aplicado fora do contexto de desenvolvimento de software.

Planejamento para trabalho não planejado

Na comunidade de DevOps, aqueles com experiência com o Agile reconhecem que o Scrum é útil para controlar o trabalho planejado. Alguns trabalhos em operações podem ser planejados: lançamento de uma grande mudança do sistema, movimentação entre data centers ou execução de atualizações do sistema. Mas grande parte do trabalho de operações não é planejada: picos de desempenho, paralisações do sistema e segurança comprometida. Esses eventos exigem resposta imediata. Não há tempo para esperar a priorização dos itens em um backlog nem a próxima sessão de planejamento de sprint. Por essa razão, muitas equipes que adotaram o pensamento do DevOps, olham além do Scrum para o Kanban. Isso os ajuda a controlar os dois tipos de trabalho e a entender a interação entre eles. Ou adotam uma abordagem híbrida, frequentemente chamada de Scrumban ou Kanplan (kanban com um backlog).

De muitas maneiras, o segredo da ampla adoção do Scrum pode ser que ele não prescreve práticas técnicas. As práticas de gerenciamento leves do Scrum costumam fazer uma grande diferença para a equipe. Onde antes havia prioridades conflitantes de vários mestres, agora há um único conjunto de prioridades na lista de pendências. E onde antes havia trabalho demais em andamento, agora há um plano restrito por aquilo que o tempo mostrou ser realmente possível. Em combinação, isso pode levar uma equipe a novos níveis de produtividade. Porém, a equipe pode encontrar-se restrita pela falta de práticas técnicas, como revisões de codificaçãotestes de aceitação automatizadosintegração contínua.

Outros processos do Agile, como Extreme Programming têm opiniões fortes sobre como as práticas técnicas oferecem suporte à capacidade da equipe em manter um ritmo sustentável e fornecer transparência e visibilidade à administração e aos interessados. Algumas equipes do Scrum recorrem à colocação de tarefas técnicas no backlog. Embora isso se encaixe bem dentro da orientação do Scrum, também atinge rapidamente o problema prático da tendência de Proprietário do produto para os recursos. A menos que o Proprietário do produto seja bastante técnico, ele ou ela pode não ter as habilidades para avaliar o custo/benefício das práticas técnicas. Fica ainda mais difícil para um Proprietário do produto, à medida que as tarefas técnicas se estendem às operações, oferecer suporte à confiabilidade, ao 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. Os Proprietários do produto são bons em entender os recursos 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 SaaS na Atlassian também têm um Proprietário do serviço, responsável por priorizar esses recursos não funcionais. Periodicamente, os dois proprietários podem precisar "negociar", mas, 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 uma tendência comum em Proprietários do produto sobre recursos. Essa abordagem de "dois proprietários" não é o único caminho para o DevOps. O importante é entender essas características não funcionais como "recursos" e ser capaz de planejá-las e priorizá-las como qualquer história 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 do Scrum aproveitarão o DevOps como uma fonte de inspiração e usarão a retrospectiva do Scrum como oportunidade para ajustar e aperfeiçoar no sentido do DevOps. No entanto, é só a prática para perceber que a maioria das equipes precisa de uma injeção de ideias externas. Até que o 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

Quando bem executada, a disciplina de Entrega contínua (CD) ajuda a limitar o trabalho em andamento, enquanto a automação da implementação ajuda a aumentar as restrições. Assim, a CD ajuda uma equipe de software a entregar com mais frequência e maior qualidade, em vez de ter que escolher entre uma e outra. No entanto, assim como as equipes que focam apenas no Scrum podem deixar passar o contexto mais amplo do Agile, as equipes que focam na Entrega contínua também podem deixar passar o contexto mais amplo do DevOps.

A prática da CD não trata diretamente de problemas de comunicação entre a empresa e uma equipe de software. Se a empresa tiver um ciclo de planejamento orientado por orçamento com duração de um ano, uma equipe que cumpra todos os compromissos de produção talvez ainda precise esperar vários meses até a empresa poder reagir. Também com bastante frequência, essas reações vêm como funções em etapa, como cancelar o projeto ou, pior, dobrar a equipe de projeto (porque um grande fluxo de entrada de pessoas novas causa desordem).

O Modelo de fluência do Agile indica o primeiro nível de fluência como "Foco no valor", em que as equipes focam em transparência e alinhamento. Sem essa fluência, a CD pode facilmente desandar para um ciclo infindável de melhoria técnica sem valor tangível para os negócios. Uma equipe pode ficar boa em entregar rapidamente com alta qualidade, mas para um produto que tem baixo valor para os usuários finais ou a empresa. Mesmo quando há muitos usuários que dizem coisas boas, essa avaliação de baixo valor pode ser possível apenas em um nível maior de portfólio de negócios. Sem essa importante fluência, é difícil ponderar práticas técnicas com relação a recursos. Isso é particularmente importante para uma equipe com uma base de código legada, que pode não ter testes automatizados nem um design adequado para implementação frequente. Em um contexto legado, uma transformação da CD pode levar anos. Assim, é muito mais importante poder demonstrar benefício comercial.

As três maneiras

O DevOps é mais que apenas automatizar o pipeline de implementação. Nas palavras de John Allspaw, o 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 do DevOps:

A primeira maneira Pensamento sistêmico enfatiza o desempenho de todo o sistema, em oposição ao desempenho de um silo específico de trabalho ou departamento. Pode ser tão grande quanto uma divisão ou tão pequeno quanto um contribuidor individual.
A segunda maneira Amplificar loops de feedback criar loops de feedback da direita para a esquerda. O objetivo de quase qualquer iniciativa de melhoria de processo é encurtar e amplificar os loops de feedback para que as correções necessárias possam ser feitas continuamente.
A terceira maneira Cultura de aprendizagem e experimentação contínua criar uma cultura que promova duas coisas: experimentação contínua, correndo riscos e aprendendo com as falhas; e entendimento de que a repetição e a prática são os pré-requisitos para o domínio.

 

A entrega contínua (CD) foca na primeira maneira: automatizar o fluxo de dev para ops. A automação desempenha uma função óbvia em ajudar a acelerar um sistema de implementação. Porém, o pensamento sistêmico é mais que apenas automação.

A segunda maneira é caracterizada pela prática, "Devs usam pagers também. " Embora o uso literal de pagers possa não ser necessário, ele significa levar os desenvolvedores para questões operacionais. Isso ajuda os desenvolvedores a entender as consequências de suas escolhas de desenvolvimento. Por exemplo, isso pode inspirar os desenvolvedores a colocar mensagens de log em lugares melhores e tornar essas mensagens mais úteis. Não se trata apenas de consciência. Os desenvolvedores também levam seu entendimento interno do sistema para os esforços de resolução de problemas, para que uma resolução possa ser encontrada e implementada mais rapidamente.

A terceira maneira está relacionada a fazer experimentos incrementais no sistema como um todo, não apenas como mudanças no aplicativo que está percorrendo o pipeline. Em outras palavras, é relativamente fácil ver quanto tempo leva a automação e usar uma infraestrutura cada vez mais potente para continuar seu aperfeiçoamento. É mais difícil entender como as transferências entre funções ou organizações geram atrasos. Isso significa que as equipes "inspecionam e adaptam" em todo o fluxo de trabalho de entrega, buscando oportunidades para melhorar a colaboração humana. Para isso, a CD requer o hábito de adaptar e melhorar. Se a equipe não refletir sobre como se tornar mais eficiente e, então, ajustar seu comportamento em todos os outros aspectos, a CD também não vai crescer nem prosperar. A equipe precisa sentir que tem autonomia para resolver os próprios problemas.

No Scrum, cada retrospectiva é uma oportunidade de melhorar as práticas e as ferramentas. Mas se a equipe não estiver aproveitando essas oportunidades para resolver problemas técnicos de curto e de longo prazo, eles apenas esperarão o proprietário do produto colocar as tarefas de CD no backlog, 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, "A 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 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.

Essas pessoas ficam tentando executar sistemas frágeis que são também os mais importantes para o negócio. Como eles são mais importantes para o negócio, eles também são onde as mudanças mais urgentes são necessárias. Assim, essa ideia do Agile de adotar a mudança não é "mudar por causa da mudança". É sobre manter o desenvolvimento responsável pela qualidade de suas mudanças, enquanto melhora a capacidade geral de entregar valor para o negócio. Esse foco no valor comercial é outro aspecto compartilhado pelo Agile e pelo DevOps

Finalmente, nem o Agile nem o DevOps são metas de negócio em si. Os dois são movimentos culturais que podem inspirar sua organização com meios melhores para atingir seus objetivos. Agile e DevOps funcionam melhor juntos do que como adversários. O segredo para evitar conflitos entre essas duas ideias é entender os valores e princípios mais profundos nos quais elas são formadas. Rápidas, mas limitadas, as definições levam a um pensamento compartimentado. Agora que você sabe que o Agile é mais do que o Scrum, e que o DevOps é mais que CD, você está pronto para experimentar a poderosa combinação Agile + DevOps.

a seguir
Agile Teams