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
Buscar tópicos

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!

Embora eu tenha levado a empolgação a um extremo, o breve discurso sobre método ágil e DevOps pode fazer com que pareçam ideias muito diferentes. Para contribuir para a confusão, ambos os conceitos parecem desafiar uma definição, embora tenham os próprios jargões e slogans. Sendo mais antigo, o ágil pode ser menos vago, mas é bem comum as pessoas ficarem frustradas com a variedade de definições para DevOps. A falta de definição levou a uma certa mistura.

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

Não há como negar a conexão histórica entre DevOps e o método ágil. Quando Patrick DuBois e Andrew Clay Schafer tentaram estabelecer uma conexão na Conferência Agile 2008 sobre infraestrutura ágil, a conexão com o DevOps nasceu. Embora Patrick depois tenha cunhado o termo "DevOps", a Conferência Agile continua a honrar essa conexão com um espaço para DevOps. Mas a gente pode ir mais fundo que a história e considerar as conexões práticas entre o método Ágil e DevOps ao olhar sob a superfície do Scrum e da entrega contínua.

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

Na comunidade DevOps, pessoas com experiência em método ágil reconhecem que o Scrum é útil para acompanhar trabalhos planejados. Parte do trabalho de operações pode ser planejada: lançar uma grande mudança de sistema, alternar entre data centers ou realizar upgrades do sistema. Porém, grande parte do trabalho de operações não é planejada: picos de desempenho, indisponibilidades do sistema e segurança comprometida. Esses eventos exigem resposta imediata. Não há tempo para esperar os itens serem priorizados em um backlog nem a próxima sessão de planejamento de sprint. Então muitas equipes que passaram a adotar o pensamento de DevOps vão além do Scrum e buscam o Kanban. Assim fica melhor de acompanhar os dois tipos de trabalho e entender a inter-relação entre eles. Ou elas podem adotar uma abordagem híbrida, muitas vezes chamada de Scrumban ou Kanplan (Kanban com 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ção, testes de aceitação automatizados e integração contínua.

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

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 elevar as restrições. Assim, a CD ajuda a equipe de software a entregar com mais frequência e com maior qualidade, em vez de precisar escolher entre uma ou outra. Porém, assim como as equipes que têm como foco apenas o Scrum podem deixar passar o contexto mais amplo do método ágil, as equipes que têm como foco a entrega contínua também podem deixar passar o contexto mais amplo de DevOps.

A prática de 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 conduzido por orçamento com duração de um ano, uma equipe que coloque todos os commits em produção ainda poderá precisar esperar vários meses até a empresa reagir. Com 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 Agile Fluency indica o primeiro nível de fluência como "foco em valor", em que as equipes têm como foco transparência e alinhamento. Sem essa fluência, é muito fácil que a CD desande para um ciclo infindável de melhoria técnica sem valor tangível para os negócios. Uma equipe pode ficar boa em entregas rápidas com alta qualidade, mas apenas para produtos que têm 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 fluência importante, é difícil ponderar práticas técnicas com relação a recursos. Esses aspectos são ainda mais importantes 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 de 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. 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 enfatiza o desempenho de todo o sistema, em vez do desempenho de um silo de trabalho ou departamento específico. Pode ser grande como uma divisão ou pequeno como um colaborador individual.
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.

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 para torná-las mais úteis. Não se refere apenas a consciência. Os desenvolvedores também levam seu entendimento interno do sistema para os esforços de resolução de problemas para que se possa encontrar e implementar uma solução mais rapidamente.

A terceira maneira está relacionada a fazer experimentos incrementais no sistema como um todo, não apenas como mudanças ao aplicativo que está percorrendo o pipeline. Em outras palavras, é relativamente fácil ver quanto tempo a automação leva e usar uma infraestrutura cada vez mais potente para continuar aperfeiçoando essa automação. É mais difícil entender como as transferências entre funções ou organizações geram atrasos. Requer que as equipes "inspecionem e adaptem" em todo o fluxo de trabalho de entrega, buscando oportunidades para melhorar a colaboração humana. Para chegar lá, a CD requer o hábito de adaptar e melhorar. Se a equipe não refletir sobre como ser mais eficiente e então ajustar e aperfeiçoar 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.

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

Por fim, nem o método ágil nem o DevOps são metas de negócios em si. Ambos são movimentos culturais que podem inspirar a sua organização com meios melhores de atingir suas metas. Os métodos ágil e DevOps funcionam melhor juntos do que como adversários. O segredo para evitar conflito entre essas duas ideias é entender os valores e princípios mais profundos com base nos quais elas são formadas. Definições rápidas e limitadas levam a pensamento compartimentado. Agora que você sabe que o método ágil é mais do que Scrum e que DevOps é mais do que CD, está pronto para experimentar a poderosa combinação de método Ágil + DevOps.

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

  1. When a commit is created and the status is ‘To Do’ then transition this issue to ‘In Progress’. Go to rule.
  2. Transition to ‘done’ when the Pull Request is merged. Go to rule.
  3. If a build fails in Jenkins, add a comment to Jira and Slack the team. Go to rule.

See these automation rules and 100s more in the Jira Automation Template Library.

Go to library

a seguir
Agile Teams