Como a agilidade e o DevOps se inter-relacionam?

De um lado, a gente tem o Mestre Scrum certificado, conhecido pelos amigos como Programador Radical e pelos filhos como LeSS SAFe DAD (o pai menos seguro)… o ágil!

Do outro, a gente tem a máquina cultural enxuta, que pratica a Entrega Contínua da Infraestrutura como Código, e batizou seu braço esquerdo de Dev e o direito de Ops... o 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.

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.

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 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.

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 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 á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.