BT

Início Artigos Quais os próximos passos em DevOps?

Quais os próximos passos em DevOps?

Favoritos

Pontos Principais

  • A transição de projeto para produto continua visando a manutenção e a adaptação a longo prazo;

  • A mudança para equipes menores e semi-autônomas continua, assim como o mercado de plataformas que integram e agregam informações de ferramentas diferentes;

  • É crescente importância do data science e da análise no ciclo de vida do desenvolvimento;

  • Conceitos como o mapeamento do fluxo de valor, que analisa todo o ciclo de vida do desenvolvedor, tornam-se cada vez mais importantes, e as ferramentas pré-criadas para dar suporte a isso tornam-se mais comuns;

  • Surgem fornecedores cada vez mais especializados e ofertas de parceiros de SI para ajudar nas necessidades de DevOps.

O movimento DevOps continua crescendo em termos de impacto e influência no meio tecnológico. Não há dúvidas de que o movimento DevOps está maduro o suficiente para ter força e voz quando comparado aos outros movimentos, como o Cloud e o Agile. Uma característica interessante do movimento DevOps é que ele surgiu de um desejo de dentro da tecnologia da informação de otimizar e harmonizar as atividades de diferentes equipes, mas amadureceu para levar em consideração as necessidades dos usuários finais de forma mais ampla e de como as empresas precisam agir para serem flexíveis e eficientes em escala.

Os líderes empresariais podem reclamar que os trabalhadores de TI não apreciam o contexto de negócios implícitos no qual estão operando, e historicamente, a área de TI dentro de uma empresa é vista como um centro de custo e não como um centro de valor. O resultado disso é que a tecnologia da informação lutou para justificar melhorias na infraestrutura e nos processos que aumentariam os custos, a menos que estivessem especificamente envolvidos a uma nova iniciativa voltada para os negócios. Mas a tecnologia está se tornando cada vez mais o centro dos negócios. Quando bem feito, a flexibilidade do software permite às empresas se adaptarem muito mais rápido do que quando era estruturado na forma pré-digital, tornando assim as equipes de TI mais eficientes e sendo os maiores facilitadores de valor.

Do projeto para Produto

A transformação digital se tornou a palavra da moda nas últimas décadas, mas é de suma importância que as empresas reconheçam que a transformação digital não é uma atividade única. O trabalho realizado por Mik Kersten em seu livro intitulado "Project to Product" (Do Projeto ao Produto - tradução livre, sem versão em português) destacava a incoerência de pensar em melhorias em TI como projetos únicos. Investigar a história das revoluções tecnológicas e testemunhar os processos de manufatura avançados atuais ajudou Kersten a reconhecer que mudar para uma mentalidade focada no produto é uma forma muito mais benéfica para as empresas se enquadrarem na tecnologia.

O que significa entender iniciativas internas como produtos? Um aspecto é reconhecer que os sistemas de tecnologia da informação envolvem responsabilidades de manutenção de longo prazo e não são algo que deva ser simplesmente criado e entregue a uma equipe qualquer. Outro aspecto é repensar a maneira como financiamos projetos. O orçamento anual é pensado para sistemas relativamente estáveis, onde as mudanças podem ser antecipadas com um ano de antecedência. As equipes dividem esse orçamento entre elas de maneira que nunca gastem menos do que lhe foi dado, para que assim não recebam menos no ano seguinte. O requisito de obter financiamento inicial tende a promover projetos grandes e caros, enquanto o orçamento para operações secundárias não são levados em consideração. O resultado disso são sistemas de TI complexos, mantidos por equipes que não participaram do desenvolvimento, que muitas vezes possuem excessos e que geralmente não atendem às necessidades dos usuários finais. A agilidade precisa fazer parte de todos os processos de um negócio, de como as equipes são estruturadas, como o trabalho é financiado, como e quando a empresa decide fazer as melhorias.

Um exemplo de mentalidade de produto é fazer com que a equipe responsável pelo sistema de CPQ (Configure - Price - Quote) seja responsável por criar e manter esse sistema no longo prazo, o mantra "você construiu, você é o dono". O poder dessa mentalidade está em promover estabilidade e flexibilidade no que é desenvolvido. Quando uma equipe tem responsabilidade de longo prazo pelo desenvolvimento e manutenção do produto e, por obter feedback sobre como ele é usado na produção, aumentam muito a chance desse produto agregar valor duradouro à empresa. O feedback sobre como os sistemas são utilizados na produção é a questão essencial para a melhoria contínua. É por esse motivo que, na comunidade DevOps, o motivo da linha de montagem do desenvolvimento de software dar lugar a um modelo circular, ou de loop infinito. O loop indica que o feedback constante dos usuários finais é tão importante quanto as especificações originais.

As empresas e as equipes de produto são, por natureza, mais estáveis do que aquelas que apenas constroem e seguem adiante. As equipes de projetos trabalham muito bem na construção e na engenharia civil, onde a infraestrutura raramente muda quando construída. Mas o software permite um nível totalmente diferente de agilidade. Pode ser reformulado ou refatorado sem que os usuários finais estejam cientes, seu design ou funcionalidade pode ser alterado nos últimos minutos antes de ser entregue aos usuários, e as versões diferentes podem ser colocadas para diferentes usuários para recebermos feedbacks. Essa agilidade é a razão pela qual o conhecimento necessário para desenvolver um produto de software deve ser mantido na equipe, se possível. Existe uma "certa incerteza" onde, no início do desenvolvimento de algo, sabemos o mínimo sobre os requisitos. À medida que avançamos no desenvolvimento e o sistema é utilizado, aprendemos coisas que nunca poderiam ter sido previstas, mesmo pela equipe de planejamento mais inteligente e atenciosa.

Topologias de Equipe

Relacionado ao tópico de mudança de "projeto para produto", esta é a pesquisa que foi realizada em torno da carga cognitiva da equipe, e a importância de estruturar as equipes de maneira a otimizar a comunicação e a confiança. Existem tanto bases matemáticas quanto empíricas para dizer que equipes menores que podem agir de maneira independente terão um desempenho mais eficiente do que as equipes grandes ou equipes com muitas dependências. O tamanho da equipe para duas pizzas da Amazon (de cinco a dez pessoas) não foi criado para simplificar as necessidades. É uma estrutura inteligente que maximiza o potencial do trabalho em equipe e minimiza a sobrecarga necessária para uma coordenação constante. A lei de Conway determina que a arquitetura do sistema reflita a estrutura da equipe. Dado que um tamanho de equipe é restrito a cinco a dez pessoas, a arquitetura modular é essencial se quiser manter a velocidade ao longo do tempo. A ideia é dar às equipes autonomia relativa sobre sistemas específicos. Isso alimenta tópicos como a integração contínua, que se esforça para reduzir o impacto da paralelização. Esses tipos de práticas recomendadas do DevOps começaram com pesquisa e experimentação em campo, e hoje são tradição na comunidade do DevOps, sendo alimentadas por meio da pesquisa de equipes como o DevOps Research e Assessment e gradualmente se tornarão a base para ferramentas dedicadas e formas de trabalho duradouras.

Grande parte do crescimento das ferramentas que estamos vendo hoje, inclui plataformas de integração e gerenciamento de fluxo de valor, como o Copado, o Tasktop, a Plutora, a Xebialabs, o GitLab e o Cloudbees que estão se esforçando para trazer e reunir informações de diversos sistemas em uma única ferramenta. Espero que essa tendência de integração e agregação continue como uma prática de lidar com a realidade diversa dos sistemas corporativos. De fato, as equipes se beneficiam muito por poder escolher as próprias ferramentas. No livro "Team Topologies" (Topologias de equipe, tradução livre, sem versão em português) de Matthew Skelton e Manuel Pais, eles se referem à padronização como um tipo de monólito, "pensamento monolítico", que pode interferir na máxima eficácia. Se estamos tentando evitar o pensamento monolítico, mas precisamos de uma visão integrada dos sistemas e processos, a integração de dados é nossa única opção.

Evolução da Ferramenta

O LaunchDarkly mostrou que existe um mercado para produtos que facilitam práticas específicas de DevOps, neste caso, separando implantações de entregas. Essa prática é parte integrante de atividades como os testes A/B e as implantações de cenários que se tornaram reconhecidas como formas poderosas de reduzir riscos e permitir a experimentação. Gostaria que mais ferramentas aparecessem para habilitar as práticas de DevOps que, de outra forma, exigiria codificação personalizada.

Embora essa não seja uma nova tendência, espero ver serviços como a Amazon Web Services (AWS), o Azure e o Google Cloud Platform (GCP) continuarem a lançar novas ofertas de serviços, competir entre si e obter participação sobre o mercado de infraestrutura local. O Azure e o GCP ainda estão se esforçando em termos de variedade de produtos que oferecem, bem como da participação do mercado que controlam, mas espero que estejam acompanhando a AWS. Ofertas do Kubernetes como serviço ajudam a reduzir a complexidade do gerenciamento da infraestrutura. Podemos esperar que outros tipos de sistemas complexos continuem sendo agrupados em aplicativos prontos para uso.

Data Science

Os relatórios State of DevOps da Puppet e do Google estabeleceram o padrão para o uso dos dados para avaliar a eficácia das práticas de desenvolvimento. Esperamos ver mais ferramentas começarem a integrar análises e ciência de dados em suas ofertas. E ver mais equipes solicitando e utilizando esses recursos para facilitar a experimentação e validar os resultados dessas experiências.

Funções comerciais, como marketing, usam testes A/B e quantificam a eficácia há muitos anos. Há um grande número de ferramentas orientadas para o marketing que foram altamente ajustadas para fornecer métricas na taxa de cliques, adoção, tempo no local, retorno do investimento, etc. A mais antiga delas é o Google Analytics, mas os profissionais de marketing possuem uma vasta gama de ferramentas para escolher. Ironicamente, as equipes de tecnologia estão atrasadas em termos de práticas como testes A/B e garantir a adoção dos sistemas pelos usuários. Muitas vezes, é deixado para as equipes de negócios rastrear a adoção de uma aplicação. Mas os departamentos internos de TI são os que têm as maiores oportunidades de fazer as melhorias para atender às necessidades dos usuários.

Esperamos ver ferramentas para monitoramento de uso e, até mesmo, pesquisas incorporadas de feedback e satisfação do usuário serem cada vez mais usadas pelas equipes de desenvolvimento internas. Essas práticas ajudam a diminuir a distância entre os usuários finais e as equipes de desenvolvimento da mesma maneira que as equipes de marketing têm se esforçado em diminuir a diferença entre as empresas e seus clientes há muitos anos. Esse tipo de feedback é excepcionalmente poderoso, pois há uma ineficiência introduzida pelo envolvimento de um analista de negócios toda vez que desejamos solicitar feedback do usuário. As iniciativas de feedback seletivo também sofrem com o viés da amostra.

Lean e Agile

O DevOps visa "atualizar o Agile", garantindo que as equipes tenham os recursos técnicos necessários, além de encurtar o planejamento e a cadência do trabalho. É importante ressaltar que o DevOps também possui o Lean como parte de processo. Isso significa que há um foco no ciclo de vida de ponta a ponta, na otimização de fluxo e no planejamento de melhoria em termos de remoção de desperdícios, em vez de apenas adicionar mais capacidade. Há um grande número de empresas e equipes que ainda estão dando os primeiros passos nesse processo. Para eles, embora a terminologia e os conceitos possam parecer impressionantes a princípio, estão se beneficiando de uma ampla gama de opções bem desenvolvidas para atender às necessidades do ciclo de vida de desenvolvimento. Prevejo que muitas ferramentas de software vão otimizar a facilidade de uso e vão continuar competindo na usabilidade e na aparência da interface do usuário.

Enquanto a maioria das iniciativas do DevOps eram estritamente baseadas em arquivos de script e de configurações, muitas novidades ajudam a visualizar processos e dependências de uma maneira que é facilmente digerida por um segmento mais amplo da empresa. Especialmente quando elas tentam capturar a atenção e a participação nos orçamentos de CIOs, CTOs e outros tomadores de decisão organizacionais, reduzir a diferença entre a interface do usuário e como ela pode ser visualizada e comercializada se torna ainda mais importante. As ferramentas graficamente mais bonitas vendem a si mesmas (para usuários comerciais e técnicos). O mapeamento do fluxo de valor e os pipelines de entrega são formas particularmente populares e eficazes de visualizar o processo de entrega, além de fornecer acesso diário às métricas e monitoramento.

Integradores de Sistemas

Por fim, fica claro que o mercado e a demanda por práticas como o DevOps são superiores a quantidade de pessoas qualificadas para implementá-lo. Assim, os integradores de sistemas vão continuar a ter um papel em ajudar as equipes a acelerar essas tecnologias e processos e, em alguns casos, até ajudar a gerenciar o ciclo de vida do desenvolvimento. Pesquisas nos relatórios do State of DevOps indicam que a terceirização funcional é prevista por baixo desempenho, logo, as empresas devem ter muito cuidado ao delegar uma atividade específica, como teste ou implementação, a um terceirizado. A menos que seja feito com cuidado, a terceirização funcional vai contra o espírito do DevOps, que se baseia em reunir todos os stakeholders (do desenvolvimento à operação), juntamente com objetivos alinhados, visibilidade e tecnologias compartilhadas.

Contratar consultorias é uma maneira extremamente poderosa de obter ajuda na ausência de talento interno. Mas introduzem limites organizacionais, a menos que esses consultores estejam profundamente inseridos na empresa, trabalhando a longo prazo ao lado de funcionários integrais. Conte com os consultores de DevOps como facilitadores para ajudá-lo a adotar tecnologias, melhorar os processos, projetar as métricas e assim por diante. Mas tenha cuidado ao terceirizar partes específicas do processo, como os testes, que estão no caminho crítico para a produção.

Talvez funcione melhor, passar todo o processo de desenvolvimento de uma aplicação específica para uma consultoria. Mas considere o ciclo de vida de longo prazo disso e como desejamos manter a aplicação ao longo do tempo. No espírito de mudança de projeto para produto, existe o risco da equipe criar uma aplicação e uma outra equipe separada mantê-la. Pense no conhecimento que estamos construindo na equipe como parte crítica da nossa arquitetura. Assim como é imprudente extrair uma parte substancial da nossa arquitetura logo após a entrada em funcionamento, também não é aconselhado extrair uma parte substancial do conhecimento da nossa equipe logo após o go live em produção.

Resumo

Em resumo, o movimento DevOps continua a crescer e a ganhar influência no mundo da TI e dos negócios em geral. À medida que as empresas se tornam cada vez mais digitais, a agilidade dos sistemas de TI se tornam críticos para a vida e a saúde das empresas. O DevOps como um movimento combina psicologia, sociologia, gerenciamento técnico, automação, segurança e práticas como o Lean e o Agile para otimizar a capacidade de uma empresa de prosperar no mundo digital. O ecossistema de consultorias, ferramentas, infraestrutura e treinamento para dar suporte a tudo isso ainda está em evolução. O mercado para DevOps é de fato o mercado para o sucesso digital, portanto, esperamos um crescimento contínuo para 2020 e os próximos anos.

Sobre o Autor

Andrew Davis é um especialista em Salesforce DevOps, apaixonado por facilitar equipes a oferecer inovação, desenvolver confiança e melhorar o desempenho. Atualmente, trabalha como diretor sênior de marketing de produto na Copado, ajudando pessoas a entenderem a importância do DevOps para escalar implementações do Salesforce.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.