7 sinais reveladores de falso DevOps

Não há dúvida de que o DevOps ajudou muitas organizações de TI a atingir seu objetivo de fornecer aplicativos e serviços de maneira mais rápida e melhor do que os processos tradicionais de desenvolvimento de software. Infelizmente, enquanto alguns líderes de TI fazem um bom trabalho ao divulgar os benefícios do DevOps, suas equipes estão indo na direção errada, adotando ferramentas e práticas incompletas ou completamente erradas.

É responsabilidade dos CIOs garantir que as equipes de desenvolvimento não se desviem intencionalmente ou não do caminho do DevOps. Aqui estão os sete sinais que irão alertá-lo sobre a possível presença de falsos DevOps em sua organização.

Colocar o DevOps em um silo

O primeiro sinal de uma falsa implementação de DevOps pode ser facilmente detectado simplesmente visualizando um organograma. “Se você encontrar o DevOps em seu próprio silo, separado da engenharia e das operações, é um sinal inicial de que sua responsabilidade pelo DevOps não existe”, diz Fernando Cuadra, Consultor Principal da empresa de consultoria e pesquisa de tecnologia ISG. “Ao criar uma equipe de DevOps separada, o CIO basicamente adiciona outra camada de complexidade, outro silo e outra transferência para gerenciar”.

O organograma deve refletir um design que permita que as equipes resolvam problemas de forma holística em todas as áreas relevantes. “Opte por construir equipes multifuncionais de ponta a ponta, desde o projeto até as operações”, aconselha Cuadra. “DevOps não é sobre pipelines e CI/CD; trata-se de possuir sua entrega de valor com o mínimo de atrito em toda a empresa”.
O DevOps é apenas uma ferramenta no que deveria ser uma conversa muito maior sobre o lado humano da tecnologia, observa Cuadra. “Isso requer uma compreensão profunda dos principais blocos de construção de equipes de alto desempenho e como os CIOs podem atualizar sua percepção de como são as equipes altamente funcionais”.

Focar em ferramentas ao invés de pessoas

Uma organização que se concentra demais em uma cultura DevOps centrada em ferramentas e tecnologia, em vez de pessoas e processos, está 180 graus fora de sincronia. “É crucial avaliar as práticas e necessidades de negócios atuais”, diz Mohan Kumar, Arquiteto Sênior da TEKsystems, uma empresa de gerenciamento de serviços de TI.

Kumar recomenda priorizar as equipes. “Instile a cultura DevOps na comunicação, colaboração, coleta de feedback e análise”, ele sugere. “Um ambiente amigável para experimentos que permite que os desenvolvedores falhem rapidamente, recuperem-se rapidamente e aprendam mais rapidamente cria uma cultura livre de culpa dentro da organização”. Kumar também sugere alimentar um fluxo de ideias criativas explorando a inteligência coletiva das equipes.

A adoção do DevOps é um processo iterativo, portanto, o CIO deve começar avaliando o estado atual da equipe de desenvolvimento e, gradualmente, construir uma estratégia de melhoria contínua envolvendo pessoas, processos e ferramentas que podem evoluir junto com as necessidades e desenvolvimentos futuros. “Em última análise, a criatividade é um músculo que deve ser exercitado continuamente para crescer”, observa Kumar.

Pouca automação

O falso DevOps pode ocorrer quando os líderes de equipe carecem de uma mentalidade de automação, particularmente a capacidade de investir o tempo e os recursos necessários para construir uma arquitetura forte com entrega automatizada de código.

Antes de avançar com uma iniciativa de automação, considere cuidadosamente as necessidades de desenvolvimento, os contratos existentes e as equipes de projeto atuais. “Veja se as habilidades da organização estão no nível em que você pode automatizar a infraestrutura”, diz Ian Fogarty, Diretor Administrativo de Tecnologia e Operações da consultoria Accenture Federal Services.

No entanto, a automação pode ser uma faca de dois gumes. Kumar observa que é muito fácil mudar involuntariamente de processos manuais defeituosos para processos automatizados defeituosos. Ele aconselha resistir ao desejo de automatizar o máximo possível. Em vez disso, automatize tanto quanto for razoável. O objetivo final, observa Kumar, deve ser transformar os lançamentos de software em um processo de implantação automatizado repetível e confiável.

Automação aleatória

Embora a automação seja altamente benéfica, muitas organizações adotam a automação DevOps sem análise e planejamento suficientes. “Vimos organizações que priorizam a automação sem considerar outros aspectos, incluindo governança, pessoas, processos e tecnologia”, diz Aaron Oh, Diretor Administrativo de DevSecOps da Deloitte Risk & Financial Advisory. Essas organizações geralmente acabam perdendo uma quantidade significativa de tempo revisitando e consertando o trabalho de automação.

Antes de correr diretamente para a automação, Oh sugere estabelecer uma governança forte e padronizar requisitos e processos. “A colaboração entre as unidades de negócios é uma parte essencial do DevOps”, observa. Aborde quaisquer barreiras organizacionais que possam existir. “A orientação da liderança será importante para definir o tom”, diz Oh. “Além disso, aproveite as ferramentas de orquestração inteligentes para ajudar a remover ainda mais os silos e permitir comunicações eficientes”.

Alimentar expectativas irrealistas

Os líderes seniores de tecnologia devem se concentrar em um compromisso que vá além da simples introdução de novas ferramentas e práticas tecnológicas. “Eles precisam priorizar uma mudança de cultura e mentalidade dos funcionários”, diz Tim Potter, Diretor da Deloitte Consulting. “Eles também precisam definir cronogramas realistas para que a transformação crie raízes na organização”.

Uma organização que simplesmente implanta ferramentas mais automatizadas e renomeia as equipes de aplicativos existentes como “equipes de DevOps”, comprometida em controlar os problemas de produção de ponta a ponta, provavelmente ficará desapontada com os resultados, explica Potter.

Os líderes de tecnologia também devem estar dispostos a aceitar o fato de que, depois de se comprometer com o DevOps, a produção pode inicialmente diminuir antes de melhorar. “Eles precisam estar preparados para fornecer ‘cobertura aérea’ para suas equipes de aplicação, permitindo que testem e aprendam e se sintam confortáveis operando em um novo modelo”, aconselha Potter. “Definir expectativas inadequadas e não fornecer tempo suficiente para a transformação pode levar as organizações a adotar o DevOps apenas no nome”.

Equipes que estão presas no passado

Velhos hábitos custam a morrer. Durante décadas, o desenvolvimento de software seguiu a metodologia tradicional em cascata, um processo que exigia a coleta de requisitos com antecedência, a construção de recursos e, finalmente, o envio dos resultados para o controle de qualidade e outras equipes para lançamento, diz Ashish Kakran, Diretor da empresa de capital de risco de TI Thomvest Ventures. “Costumava levar meses até que os clientes vissem novos recursos”, observa ele.

Quando as equipes de desenvolvimento falham em sair completamente da cascata, elas acabam com estranhas combinações de processos que podem ser descritas como “queda ágil”, diz Kakran. “Isso indica que uma mudança completa não aconteceu para aproveitar os últimos avanços no desenvolvimento de software”.

Kakran sugere que uma maneira rápida e fácil de identificar uma equipe em dificuldades é examinando seus “Epics” e “Stories” de DevOps.

“O contexto completo de um projeto em andamento geralmente é capturado nessas tarefas”, explica ele. “Se você sente que o projeto de um mês já está dividido em tarefas com pouco ou nenhum feedback contínuo do cliente, é um sinal de que a equipe está se preparando para o fracasso, seja perdendo os prazos do projeto ou não fornecendo experiências úteis ao usuário”.

Inflexibilidade

DevOps não é uma metodologia de tamanho único. Para máxima eficácia, os fluxos e ferramentas de DevOps devem ser ajustados às necessidades específicas da organização, que podem variar amplamente dependendo de seu tamanho, tipos de aplicativos e experiência em desenvolvimento.

DevOps nunca deve ser estático. Processos e ferramentas devem se adaptar à medida que a organização cresce e segue em busca da melhoria contínua. Essas metas exigem ferramentas flexíveis, bem como a capacidade de analisar KPIs para revelar oportunidades de melhoria, diz Wing To, Vice-Presidente de Engenharia da Digitial.ai, que comercializa uma plataforma DevOps com tecnologia IA. Os líderes de TI também devem estar atentos à mudança cultural necessária para reunir as equipes de desenvolvimento e operações. Em vez de criar um departamento de DevOps separado, que apenas cria mais silos e gargalos de processo, a metodologia deve ser integrada a cada área de negócios.

DevOps é basicamente sobre pessoas e processos. Os líderes de TI devem entender que esses recursos devem ser específicos do contexto. “A maneira ideal de usar ferramentas e processos muda com o tempo, é dinâmica, não estática, e as ferramentas e processos precisam de treinamento cuidadoso para serem usados corretamente”, observa To.

Alcançando um equilíbrio

Há um equilíbrio push e pull que deve ser alcançado ao iniciar uma transformação DevOps bem-sucedida. “Se você tiver sorte, equipes ansiosas se apresentarão e se voluntariarão para estar entre os primeiros a adotar”, diz Potter. “É importante apoiar essas equipes – recompensá-las por sua coragem e comemorar seu sucesso, mantendo o foco no roteiro mais amplo de transformação da organização”.

Lembre-se, no entanto, que os benefícios serão limitados e adiados se toda a organização não aceitar a transformação. “Inevitavelmente, haverá interdependências que desacelerarão uma equipe de aplicativos se a organização mais ampla não fizer a mudança”, diz Potter.