Não há como negar a conexão histórica entre o DevOps e a agilidade. Foi na Agile 2008 Conference sobre infraestrutura ágil que Patrick DuBois e Andrew Clay Schafer estabeleceram essa conexão com o DevOps.

Embora Patrick tenha apresentado o termo “DevOps” depois, a Agile Conference continua reverenciando essa conexão com um espaço para o DevOps. Mas vamos ir mais longe que a história e dar uma olhada nas conexões práticas entre a agilidade e o DevOps analisando os detalhes do Scrum e da entrega contínua.

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.

Na comunidade de DevOps, pessoas com experiência em método ágil reconhecem que o Scrum é útil no acompanhamento de 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 DevOps, indo além do Scrum e buscando 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 o fato de ele não prescrever nenhuma prática técnica. As práticas de gerenciamento leves do Scrum costumam fazer uma grande diferença para a equipe. Onde antes existia prioridades conflitantes de várias origens, agora existe um único conjunto de prioridades no backlog. E onde antes havia trabalho demais em andamento, agora há um plano restrito por aquilo que o tempo mostrou ser possível de verdade. Combinados, esses aspectos podem levar uma equipe a novos níveis de produtividade. Porém, a equipe pode estar 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 funções. 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.

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 as funções de que os usuários precisam, mas não são tão bons em equilibrar essas funções 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, é possível que os dois proprietários precisem negociar, mas, na maioria das vezes, as negociações podem ser feitas 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 funções. Essa abordagem de "dois proprietários" não é o único caminho para o DevOps. É importante entender essas características não funcionais como "funções" e poder fazer o planejamento e a priorização delas assim 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 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.

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 funções. 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.

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:

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.

O Scrum está relacionado aos princípios ágeis assim: “As alterações nos requisitos são bem-vindas, até mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para fornecer uma vantagem competitiva ao cliente.”

Já a entrega contínua se relaciona aos princípios ágeis desta maneira: “A maior prioridade é atender às necessidades do cliente por meio da entrega antecipada e contínua de software relevante.”

Isso significa que a agilidade tem mais a ver com aceitar as mudanças que entram e saem do que com cerimônias, como reuniões rápidas e planejamento de sprint. De fato, há outros 10 princípios no Manifesto Ágil. Em vez de tentar escolher determinados princípios, eles devem ser considerados como um todo. Juntos, eles representam uma atitude de mudança que é comum tanto para a agilidade quanto para o 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 ágeis e de 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 só Scrum e que DevOps é mais do que só CD, você está pronto para experimentar a poderosa combinação ágil + DevOps.

Talvez o maior desafio de trabalhar em várias ferramentas seja a constante mudança de contexto e a interrupção que traz. Pode levar horas para voltar ao fluxo se você for interrompido por uma tarefa que não seja código. Por esse motivo, mais e mais pessoas estão automatizando entre seus provedores de git e ferramentas de gerenciamento de trabalho. Aqui estão três das regras de automação mais comuns

1. Quando um commit for criado e o status for 'Para fazer', faça a transição desse item para 'Em andamento'.Vá para a regra.

2. Troque para 'concluído' quando a Pull request for mesclada. Vá para a regra.

3. Se um build falhar no Jenkins, adicione um comentário às equipes do Jira e do Slack. Vá para a regra.

Veja essas regras de automação e outras centenas na Biblioteca de templates do Jira Automation.

Ir para a biblioteca