Agilidade e DevOps – Entenda essa relação

Como muitos já imaginam, o Gerenciamento ágil tem uma grande contribuição no movimento  DevOps. Diversas características atuais do DevOps, que ajudam os profissionais a evitar o espiral descender e a quebra da dívida técnica vieram da agilidade. Nós vamos comentar um pouco sobre esta relação, seus entrelaçamentos e resultados. Em princípio, agilidade tem suas origens no desenvolvimento de software, quebrando os velhos paradoxos de construção dos modelos de engenharia do software em estruturas do cascata. A extensão destas construções iterativas incrementais para espaços além do desenvolvimento, caracterizam os fundamentos do DevOps. A continuação transitaremos por vários orientações no paralelo Agilidade e DevOps.

Pequenas equipes de desenvolvimento

O ponto fundamental deste conceito é a possibilidade de que cada um dos membros da equipe consiga contribuir de forma mais efetiva no seu trabalho diário. Quando temos equipes muito grandes, a tendencia é que alguns membros participam menos ativamente do trabalho diário, começam também a aparecer algumas lideranças informais criando uma certa influência e gerando uma cisão no grupo, se perde criatividade e principalmente afinidade, a força de união do time. Além de tudo, todos os processos ficam mais demorados quando a equipe é muito grande, reuniões informais com assuntos mais diversos, que agregam menos valor. Assim ocorre a perda de interesse, engajamento, motivação, da participação entre os integrantes da equipe. Então quando você diminui o tamanho da equipe, as pessoas ficam mais ativas e focadas, participam mais, criam um sentimento de comunidade e são mais reconhecidas.

Eles são livres para desenvolver o gerenciamento de seus recursos, validar os hotfix em ambientes como produção e eles são capazes de implantar seus softwares de forma rápida, segura e bem protegida.

Existe um grande desafio em construir equipes pequenas, especialmente se a arquitetura é fortemente acoplada. A Lei de Conway nos revela a relação das estruturas de comunicação das equipes, espelham como resultado, modelos sintomáticas em arquiteturas resultantes. Mas DevOps nos apresenta possibilidades,  que nos permite abordar estes desafios. Por exemplo, que tipo de atividades serão executadas e por quem? Qual é a dependência do profissional na equipe e entre as equipes? Como trabalhar no modelo escalado? A arquitetura levemente acoplada tem grandes vantagens em soluções maiores, aliás, será um assunto a ser explorado em outro artigo…

Adotando esse conceito, se torna possível delimitar o esforço das atividades em tamanhos menores de entregas, delimitando o tamanho do lote. Alguns anos atrás os projetos duravam na ordem de anos, e com a chegada da agilidade esse tempo caiu para meses. Assim, com ajuda do DevOps, eliminando desperdícios e aumentando a automação de atividades repetitivas, está-se falando na ordem de horas, ou talvez no máximo dias. Assim uma pequena mudança, que entra em um fluxo automatizado, terá mais facilidades de entrar em produção rapidamente, a um risco mais controlado. O foco e abrangência do pacote fica reduzido para analisar, para testar, para homologar, para implantar, para corrigir e até para realizar rollback.

Do ponto de aumentar a estabilidade tanto da solução como do clima organizacional, a Implantação do software é realizada em horário de expediente, nos dias úteis, quando toda a equipe está no escritório e sem qualquer impacto para o cliente com implantações em paralelo (blue-green ou canário) . Na realidade, isso aproxima mais a TI do cliente, fazendo com que ele enxergue mais valor no trabalho que está sendo realizado.

Ciclos de Feedback rápido

Ou seja, se existe um retorno e retroalimentação das informações de produção mais rapidamente, é possível calibrar, ajustar, de forma muito mais eficaz, todas as ações necessárias para melhorar a solução. Desta maneira há um ciclo curto de entrega, onde os resultados indesejados são rapidamente resolvidos por todos os que participam deste processo, até o cliente e usuários, e o mais importante, com pouco investimento. A evolução das técnicas na construção de soluções, nos permite transitar de maneira mais estável, entre as diferentes versões incrementais, técnica que pode ser adotada na operação para a resolução de incidentes em forma automatizada após uma falha por uma mudança recente.

Sempre que o desenvolvedor atualiza o repositório de versão de código (commit), a alteração passa por um processo automatizado, onde o código é validado (construção sintática, compilação, testes unitários, análise de código, segurança etc.) em um primeiro momento, para rapidamente informar ao desenvolvedor para corrigir caso seja necessário. Enquanto o código é construído, o desenvolvedor não consegue visualizar as consequências que poderiam existir nas dependências do código, uma vez que ele só está olhando para um pedaço só dele.

Testes automatizados rápidos são realizados em ambientes similares ao de produção, fornecendo a garantia contínua de que o código/software e ambientes estão funcionando como projetados, com segurança e de forma estável. Este processo de validação é repetido muitas vezes para manter e enriquecer a abrangência de possíveis falhas, aumentar a cobertura frente as fragilidades, com a ideia de uma rápida detecção antes de produção. Esta prática reduz a tensão dos desenvolvedores de contribuir com erros despercebidos no seu dia a dia, aumenta a confiança, qualidade e produtividade.

Reduzir e pagar a dívida técnica

A dívida técnica, constituída por decisões tomadas em forma a priorizar necessidades de curto prazo, tem impactos acumulativos na qualidade de logo prazo. Agora com DevOps você começa a controlar o tempo que ela permanecerá como dívida, evitando impactos negativos como a falta de adaptabilidade, dilatação dos tempos de resposta para descobrir falhas e sua consequente resolução. Por outro lado, evita também a falta de flexibilidade de trabalho das equipes relacionadas à superespecialização dos profissionais. Com isso as melhorias, o Kaizen começa a ser importante, e quanto mais demora, pior é a consequência disso no futuro. Se se começa a criar metas para a correção da dívida, os problemas serão corrigidos assim que são fundados. É necessário engajar toda a organização, se necessário, porque as metas globais são mais importantes do que as metas locais, avaliar resultados mais do que entregas para a ressignificar a maneira de trabalhar.

O uso abrangente da telemetria em produção ajuda ao aumento dos conhecimentos e aos refinamentos dos ambiente de desenvolvimento e intermediários

Uma vez que o sistema está cada vez mais automatizado, é necessário aumentar a visibilidade do comportamento do serviço frente as diferentes situações de produção, situações de testes e simulações que nos permitam entender os limites do sistema. Isso é realizado com a monitoração e a instrumentação dentro de todo o ciclo de entrega. Para isso é necessário entender quanto demoraram os testes, qual é a abrangência, quais das regiões não acobertadas que tem pontos críticos e fragilidade, quantos ambientes foram criados, como foi a execução deles, onde falhou, qual a criticidade da falha, se ela é tolerável ou ainda poderia ser crítica. Isso abre uma possibilidade com a telemetria, para mensurar e ter informações, para conseguir tomar decisões mais assertivas, direcionando esforços na implantação de melhorias que foquem em  resultados que entreguem valor e de forma contínua.

Certifique-se de que os problemas sejam detectados e corrigidos rapidamente. Assim se realizara uma gestão menos reativa, controlando os esforços e certificando-nos de que tudo está funcionando como projetado, e o mais importante, que os clientes estão recebendo valor, usando o software que foi criado para tende-los de maneira eficaz.

Os esforços se transformam rapidamente em resultados. Isso é um motor gigante de motivação, de responsabilidade, de reconhecimento, de realização. A influencia dos profissionais técnicos ultrapassa de longe o potencial tradicional de trabalho dentro de um espaço limitado à tecnologia. A grande revolução do DevOps está muito além do trabalho articulado de Dev e Ops. DevOps implanta um revolucionário paradoxo de integrar as áreas de negocio e TI para abordar o cliente de maneira inovadora.  Os profissionais de TI desenvolvem habilidades laterais, e se especializam nas área de negocio onde atuam.

Em vez de uma longa espera

Agilidade trouxe um conceito importantíssimo, de quebrar o desenvolvimento do escopo completo de projetos clássicos do modelo cascata, em pequenas entregas realizadas por iteração de trabalho. Em cada iteração há entregas concretas, software funcionando (definição de completude da história, de pronto), que se consolidam agrupadas em uma Release construída em tempos também regulares, resultado de várias iterações. O processo fora do espaço do desenvolvimento está permeado por atividades manuais, demoradas, frágeis e de alto risco. DevOps integra aqui um conjunto de conceitos relacionados, que Lean desenvolve muito bem: o fluxo de uma peça, fluxo contínuo e diminuição do tamanho da peça. Estes conceitos levados ao contexto de TI, reduzem ainda mais o lote da agilidade, o tamanho da Release ao extremo é eliminado de vez, para substitui-lo por Deploy contínuo. Nada disso é possível sem mais uma vertente que se agrega ao movimento DevOps: as bases da Infraestrutura como código, com suas variações vindas da virtualização e cloud, que permitem automatizar os processos que estão fora das responsabilidades do desenvolvimento. As esperas são pontos sensíveis de desperdícios, e por isso, pontos de acompanhamentos contínuos para sua redução.

Como mencionado no ponto anterior, a Implantação continua é possível se se estabelece um fluxo continuo a partir das disciplinas do desenvolvedor, contribuindo com código de qualidade no início do processo. O processo contínuo é disparado a cada commit do desenvolvedor (contribuição de código no repositório de versão) realizado em forma frequente, várias vezes por dia. Se espera que todas as atividades subsequentes, até a entrada em produção estejam automatizadas. Sendo assim, o código novo precisará de conviver em paralelo com a versão atual, aquela que está funcionando até sua total substituição. É por isso que disponibilização de um novo recurso, não dependerá da implantação, já que este novo recurso já estará em produção. Dependerá da uma ação de visibilidade, de substituição usando por exemplo, alguma técnica como feature-flag, que permitirá administrar tanto a ida ou substituição como o retorno, de maneira muito mais estável e preparada.

Em vez de lutar por dias ou semanas para fazer um recurso funcionar corretamente, nós apenas mudamos a configuração do sistema

Esta capacidade “seletiva”, de aplicar através de uma opção ou flag, qual funcionalidade deverá aparecer ao usuário em dado momento, flexibiliza ao extremo a maneira de disponibilizar as funcionalidades em produção. Ela nos permite além de estabilizar as implantações, também inovar e até gerenciar a demandas em dado momento, direcionando quem pode e quando pode ser executada tal o qual ação, especialmente quando queremos atender demandas de pico de uso, desabilitando outras funcionalidades menos importantes momentaneamente para evitar sobrecargas.

Uma reflexão importante que podemos observar, é que o sucesso de uma organização, sua capacidade de inovar e se destacar frente à concorrência está muito além do método de desenvolvimento que se utilize, se pensamos um pouco nas discussões e conflitos entre a agilidade e os métodos tradicionais. Depende mais do envolvimento e engajamento das competências especialistas e das técnicas utilizadas no aumento da qualidade e da responsabilidade no que fazemos. DevOps é o grande desafio para além da agilidade.

Artigos relacionados: