O que está atrasando sua equipe de DevOps (além de ser chamada de "equipe de DevOps")
Sem práticas ágeis, você estará apenas remendando a maneira como cria as diferentes pilhas de aplicativos.
Negligenciar o papel do desenvolvimento ágil no sucesso do DevOps fará com que a maioria das empresas enfrente dificuldades para alcançar os níveis mais altos de maturidade.
A teoria do DevOps é elegantemente simples. Remova a delimitação tradicional entre os grupos de desenvolvimento e de operações para se aproximar dos clientes e implantar recursos mais relevantes com maior frequência. Em outras palavras, inovar.
A realidade está um pouco aquém, e toda organização que diga ter uma equipe de DevOps já cometeu um erro fatal. Criar uma equipe não é o mesmo que transformar seu modelo operacional inteiro para colocar a voz do cliente no cerne da estratégia empresarial. E muitos acreditam ser apenas uma questão de ferramental, negligenciando o fato de que, sem haver o adequado respaldo cultural para o DevOps, as ferramentas nunca proporcionarão ganhos máximos de eficiência. Primeiramente, essa cultura tem em si maior colaboração. Para dar suporte a isso, deve haver um senso de responsabilidade compartilhada entre as equipes de desenvolvimento e de operações (a famosa mentalidade "você constrói, você executa", imortalizada por Werner Vogels, CTO da Amazon, em 2006). Organizacionalmente, não deve haver silos entre elas, e será necessário permitir que funcionem de forma autônoma.
O mecanismo de processo capaz de sustentar esse importante avanço cultural é outra metodologia muito experimentada, mas pouco compreendida: o desenvolvimento ágil.
Trocando em miúdos, não é possível fazer a transição para o modelo e a cultura autênticos do DevOps sem adotar práticas ágeis. Você pode implantar o máximo de ferramentas DevOps que quiser, mas, sem práticas ágeis, estará apenas remendando a maneira como cria as diferentes pilhas de aplicativos. Você construirá cada camada com mais automação no trajeto até o ponto de verificação seguinte, mas, sem remover completamente esses pontos de verificação, seus clientes — e seus desenvolvedores — acabarão por ver pouca diferença.
Como o ágil promove a inovação
A abordagem tradicional da inovação é um processo longo e de alto investimento. Os grupos de produto lançam as ideias em que desejam passar o próximo ano trabalhando e depois recebem alguns milhões de dólares para fazer exatamente isso. Talvez haja revisões regulares no final das fases para reavaliar aspectos do planejamento, mas é improvável que o objetivo mude de modo significativo. Então, eles ganham imediatamente milhões de dólares sem saber quais poderão ser os resultados, tornando o custo do fracasso extremamente alto.
Isso faz sentido quando se entrega hardware – uma plataforma de perfuração ou aeronave parcialmente construída tem pouca serventia –, mas não faz sentido com software, já que os recursos do produto podem ser adicionados e refinados enquanto a solução está no mercado.
O desenvolvimento ágil reflete isso ao permitir a entrega de soluções úteis em prazo mais curto e com investimento menor. Em vez de fazer apostas milionárias com cronogramas de 18 meses, o desenvolvimento ágil permite que você faça apostas de US$ 200 mil em produtos mínimos viáveis (MVPs) que podem ser entregues no prazo de três a seis meses. Dessa forma, o custo de descobrir que não há um mercado para seus recursos é muito menor, e as equipes podem se voltar rapidamente para onde a demanda realmente está.
Tudo isso gira em torno de orquestrar pessoas, processos e tecnologias para entregar rapidamente aos clientes recursos funcionais que tenham valor; coletar feedback deles; e então priorizar o desenvolvimento com base nesse feedback.
E é justamente aí que as organizações em dificuldade com o DevOps tendem a ser frágeis.
Modelos operacionais ineficazes enfraquecem o poder das pessoas
Sem a adoção de um modelo operacional ágil, é difícil manter as equipes de arquitetura, operações e engenharia alinhadas, e suas priorizações conflitantes logo prejudicarão os esforços empreendidos para lançar o código rapidamente. Quando estabelecidas como grupos separados, essas equipes sempre farão suas tarefas na própria toada, entregando cada camada à equipe seguinte, em cascata, somente quando ela estiver pronta.
Em vez disso, as equipes verticalmente segmentadas do modelo ágil congregam membros de cada organização em grupos autônomos e autodirecionados, podendo proporcionar a entrega de recursos específicos muito mais rapidamente.
A adoção inconsistente do ágil leva a processos mal-acabados
Embora vejamos muitas organizações adotando algumas práticas ágeis e grande parte da linguagem, só um número significativamente menor delas permanece fiel a seus princípios. Ao seguir a letra da lei, mas sem entender o propósito, elas não aplicam os processos de forma consistente nem os respaldam com medidas ou métricas adequadas.
O resultado é que mais pontos de passagem são inseridos no fluxo de valor (o número de etapas entre a ideia e a entrega do recurso ao cliente), fazendo com que as versões muitas vezes demorem mais para ser entregues do que antes. Quando isso acontece, a confiança da equipe no ágil evapora, o moral despenca e os clientes ficam de mãos vazias.
Tecnologia e ferramentas inadequadas
A combinação de tecnologia e ferramentas representa um desafio duplo no estabelecimento de um alicerce ágil para o êxito do DevOps. Primeiro, a base de código dos seus aplicativos deve ser rearquitetada em torno de contêineres e microsserviços para permitir a implantação de cada recurso. Sem isso, as equipes não podem dividir as "histórias de usuário" (explicação informal do objetivo de um recurso contada pela perspectiva do usuário) verticalmente, algo essencialmente característico do DevOps.
No que tange ao ferramental, normalmente vemos ferramentas legadas para gerir a configuração de alterações no lado do código, o que, invariavelmente, leva a processos desatualizados de gestão de configurações. E, se você usa ferramentas de gestão de projetos desatualizadas, então certamente tem o pacote de ferramentas errado.
Os seis fatores críticos para maturar o DevOps por meio do ágil
Para superar esses desafios e reiniciar a estratégia DevOps centrando-a em processos ágeis, recomendamos que os líderes de tecnologia se concentrem em gerar os seguintes fatores críticos ao sucesso.
1. Não tente comer o elefante todo de uma vez. Em vez disso, identifique um produto específico para começar, depois selecione/crie uma equipe para transformá-lo utilizando processos ágeis.
2. Intensifique e viabilize o ágil a partir do topo dedicando algum tempo para entendê-lo e fomentá-lo. Somente com adesão da liderança é que a voz do cliente poderá ser incutida na visão estratégica da empresa. A chave para isso é permitir que as equipes técnicas definam a cadência de lançamento dos recursos, retrocedendo a partir das datas de lançamento esperadas para definir o nível de MVP que é possível no tempo permitido. (Isso também levará a desenvolvedores mais envolvidos no trabalho e a melhorias culturais em geral.)
3. Realize o exercício de mapear o fluxo de valor para entender quantas etapas são necessárias para que a ideia transite da concepção ao cliente, depois utilize o modelo operacional verticalmente segmentado do ágil para reduzi-las.
4. Feche seus ciclos de feedback incorporando a voz do cliente em intervalos regulares. O timing é importante, pois os clientes não se sentirão ouvidos se os cronogramas forem muito longos. (O exercício de mapear o fluxo de valor também ajudará a identificar onde e quando esse ciclo de feedback ocorre – ou se está rompido.)
5. Avalie e defina suas metodologias DevOps e ágeis em relação às práticas recomendadas e identifique resultados mensuráveis e métodos para monitorar o desempenho em relação a essas práticas.
6. Por fim, trate a transformação para o modelo operacional DevOps como um exercício ágil em si, priorizando a melhoria contínua. Isso significa criar um plano para permitir que as equipes aprendam com o próprio desempenho e tornem o processo por trás de cada nova versão melhor do que o anterior.
Está na hora de recuperar o propósito original de "DevOps"
About the Authors
VP of AWS Professional Services
Myles Anderson
Myles, by nature, is a creative and strategic thinker, but also a very driven type-A personality. He was introduced to the cloud (AWS, specifically) in 2011 while working on a website for a customer. Immediately, he was blown away at the potential for the cloud to enhance their operations. His desire to get started using the AWS cloud was forestalled by a career transition in 2011, but within a few months the groundwork was laid for his new customer to explore using the cloud. Shortly thereafter he established a vision for moving their big data visualization platform (DataViser) into AWS. As Rackspace Technology's VP of AWS Professional Services he’s excited to help our customers leverage technology to truly transform their business!
Read more about Myles AndersonDirector, Delivery Engagement
Bethany Cook
Bethany Cook, Director, Delivery Engagement for Onica, A Rackspace Company. She lives in Colorado with her husband, two children, and a variety of pets. She is passionate for well-run IT consulting engagements, building client relationships, and solutioning.
Read more about Bethany CookRelated Topics