Acelerar o estado das DevOps 2021

O relatório Agilizar o estado das DevOps deste ano pela equipe de DevOps Research and Assessment (DORA) do Google Cloud representa sete anos de pesquisa e dados de mais de 32 mil profissionais em todo o mundo.

Nossa pesquisa examina os recursos e as práticas que promovem a entrega de software, a operação e o desempenho organizacional. Usamos técnicas estatísticas rigorosas para entender as práticas que levam à excelência na entrega de tecnologia e aos poderosos resultados comerciais. Para isso, apresentamos insights baseados em dados sobre as maneiras mais eficazes e eficazes de desenvolver e entregar tecnologias.

Nossa pesquisa continua a mostrar que a excelência na entrega de software e o desempenho operacional impulsionam o desempenho organizacional nas transformações tecnológicas. Para permitir que as equipes façam comparações de mercado, usamos uma análise de cluster para formar categorias de desempenho significativas, como com desempenho baixo, médio, alto ou de elite. Depois que suas equipes tiverem uma ideia do desempenho atual em relação ao setor, você poderá usar as descobertas da nossa análise preditiva para segmentar práticas e recursos a fim de melhorar os principais resultados e, por fim, sua posição. Este ano enfatizamos a importância de alcançar metas de confiabilidade, integrar a segurança a toda a cadeia de suprimentos de software, criar documentação interna de qualidade e aproveitar a nuvem ao máximo. Também analisamos se uma cultura de equipe positiva pode atenuar os efeitos do trabalho remoto como resultado da pandemia da COVID-19.

Para fazer melhorias significativas, as equipes precisam adotar uma filosofia de melhoria contínua. Use os comparativos de mercado para medir seu estado atual, identificar restrições com base nas capacidades investigadas pela pesquisa e testar melhorias para aliviar essas restrições. A experimentação envolverá uma combinação de vitórias e falhas, mas em ambos os cenários as equipes poderão realizar ações significativas como resultado das lições aprendidas. 

As empresas com melhor desempenho crescem e continuam elevando o padrão.

Agora, as equipes da Elite compõem 26% das equipes do nosso estudo e reduziram os tempos de lead relacionados a alterações na produção. O setor continua a acelerar, e as equipes veem benefícios significativos ao fazer isso.

SRE e DevOps são filosofias complementares.

As equipes que usam práticas operacionais modernas descritas pelos nossos amigos de engenharia de confiabilidade do site (SRE) conseguem um melhor desempenho operacional. As equipes que priorizam a entrega e a excelência operacional relatam o maior desempenho organizacional.

Mais equipes estão usando a nuvem e têm vantagens significativas.

As equipes continuam movendo cargas de trabalho para a nuvem, e aquelas que usam todos os cinco recursos da nuvem veem aumentos na entrega de software e no desempenho operacional (SDO) e no desempenho organizacional. A adoção de várias nuvens também está aumentando para que as equipes possam aproveitar os recursos exclusivos de cada provedor.

Uma cadeia de suprimentos de software segura é essencial e melhora o desempenho.

Devido ao aumento significativo de ataques maliciosos nos últimos anos, as organizações precisam mudar de práticas reativas para medidas proativas e de diagnóstico. Equipes que integram práticas de segurança em toda a cadeia de suprimentos de software entregam software de maneira rápida, confiável e segura.

Uma boa documentação é fundamental para implementar os recursos de DevOps com sucesso.

Pela primeira vez, medimos a qualidade da documentação interna e das práticas que contribuem para essa qualidade. Equipes com documentação de alta qualidade são mais capazes de implementar práticas técnicas e ter um desempenho melhor como um todo.

Uma cultura de equipe positiva atenua o esgotamento em circunstâncias desafiadoras.

A cultura de equipe faz uma grande diferença na capacidade da equipe de fornecer software e atingir ou exceder as metas organizacionais. As equipes inclusivas com uma cultura generativa^1,2 tiveram menos burnout durante a pandemia da COVID-19. 

____________________________

1. Da cultura de tipos de organização de Westrum, uma cultura de equipe generativa refere-se a equipes que são altamente cooperativas, quebram silos, permitem que as falhas levem a consultas e compartilhem o risco de tomada de decisão.

2. Westrum, R. (2004). “A typology of organizational cultures.” BMJ Quality & Safety, 13(suppl 2), ii22-ii27.

Examinamos como as equipes desenvolvem, entregam e operam sistemas de software e, em seguida, segmentamos os participantes em quatro clusters de desempenho: elite, alto, médio e baixo desempenho. Ao comparar o desempenho da sua equipe com o de cada cluster, é possível ver o contexto das descobertas descritas neste relatório.

Desempenho operacional e da entrega de software

Para atender às demandas de um setor em constante mudança, as organizações precisam fornecer e operar software de maneira rápida e confiável. Quanto mais rápido as equipes puderem fazer mudanças no software, mais rapidamente você conseguirá agregar valor aos seus clientes, realizar experimentos e receber feedback. Com sete anos de coleta e pesquisa de dados, desenvolvemos e validamos quatro métricas que medem o desempenho da entrega de software. Desde 2018, incluímos uma quinta métrica para capturar os recursos operacionais. 

As equipes que se destacam nas cinco medidas demonstram um desempenho organizacional excepcional. Chamamos essas cinco medidas de desempenho operacional e da entrega de software (SDO, na sigla em inglês). Observe que essas métricas se concentram nos resultados no nível do sistema, o que ajuda a evitar as armadilhas comuns de métricas de software, como comparar funções e realizar otimizações locais ao custo de resultados gerais.

As quatro métricas de desempenho da entrega de software podem ser consideradas em termos de capacidade de processamento e estabilidade. Medimos a capacidade de processamento usando o tempo de lead das alterações de código (ou seja, o tempo da confirmação do código até o lançamento na produção) e a frequência de implantação. Medimos a estabilidade usando o tempo para restaurar um serviço após um incidente e a taxa de falha nas alterações.

Mais uma vez, a análise de cluster das quatro métricas de entrega de software revela quatro perfis distintos de desempenho (elite, alto, médio e baixo), com diferenças estatisticamente significativas na capacidade de processamento e medidas de estabilidade entre eles. Assim como nos anos anteriores, as equipes com melhor desempenho tiveram um desempenho significativamente melhor em todas as quatro medidas, e aquelas com desempenho baixo tiveram um desempenho significativamente pior em todas as áreas.

A quinta métrica representa o desempenho operacional e é uma medida de práticas operacionais modernas. A principal métrica de desempenho operacional é a confiabilidade, que é o grau em que uma equipe pode cumprir promessas e fazer declarações sobre o software que opera. Historicamente, medimos a disponibilidade, e não a confiabilidade, mas, como a disponibilidade é um foco específico da engenharia de confiabilidade, ampliamos a medição para aumentar a confiabilidade de modo que a disponibilidade, a latência, o desempenho e a escalonabilidade sejam são representados de maneira mais ampla. Especificamente, pedimos aos participantes para avaliar a capacidade deles de atingir ou exceder as metas de confiabilidade. Descobrimos que equipes com diferentes graus de desempenho de entrega têm resultados melhores quando também priorizam a performance operacional.

Assim como os relatórios anteriores, comparamos os desempenhos de elite com os de baixo desempenho para ilustrar o impacto de recursos específicos. No entanto, este ano, queremos considerar o impacto do desempenho operacional. Em todas as categorias de desempenho da entrega (até a elite), vimos grandes benefícios em vários resultados para equipes que priorizaram reuniões ou excederam as metas de confiabilidade.

A cada ano, continuamos vendo o setor evoluir e acelerar a capacidade de entrega de software com mais velocidade e melhor estabilidade. Pela primeira vez, nossos artistas de alto e alto nível representam dois terços dos participantes. Além disso, os artistas de elite deste ano aumentaram novamente o desempenho, reduzindo o tempo de lead para alterações em comparação com avaliações anteriores (por exemplo, a redução de menos de um dia em 2019 para menos do que uma hora em 2021). Além disso, pela primeira vez, apenas as equipes de elite minimizaram a taxa de falha de alteração em comparação aos anos anteriores, em que média e alta performance foram capazes de fazer o mesmo.

Capacidade

Frequência de implantação

De maneira consistente com os anos anteriores, o grupo de elite relatou que implanta rotineiramente sob demanda e executa várias implantações por dia. Em comparação, os desempenhos mais baixos informaram uma implantação menos de uma vez a seis meses (menos de dois por ano), o que é novamente uma redução no desempenho em comparação com 2019. Os números de implantação anuais normalizados variam de 1.460 implantações por ano (calculadas como quatro implantações por dia x 365 dias) para aquelas com melhor desempenho e 1,5 implantações por ano para baixo desempenho (média de dois implantações e uma implantação). Essa análise estima que os desenvolvedores de elite implantam códigos 973 vezes com mais frequência do que os de baixo desempenho.

Tempo de lead das mudanças

Uma melhoria de 2019, as empresas de alto desempenho relatam tempos de lead de mudança menores do que uma hora, e o tempo de lead de alteração é medido como o tempo do código comprometido a ter esse código implantado na produção. Esse é um aumento no desempenho em comparação com 2019, quando os desenvolvedores com melhor desempenho informaram tempos de lead de alteração menores que um dia. Em contrapartida à nossa elite, as equipes de baixo desempenho exigiam tempos de lead maiores que seis meses. Com tempos de lead de uma hora para artistas de elite (uma estimativa conservadora no limite de "menos de uma hora") e 6.570 horas para baixo desempenho, calculado pela média de 8.760 horas por e 4.380 horas em seis meses: o grupo de elite tem tempos de lead de mudança 6.570 vezes mais rápidos do que os de baixo desempenho. 

Estabilidade

Tempo de restauração do serviço

O grupo de elite informou um tempo para restaurar o serviço em menos de uma hora, enquanto os usuários com baixo desempenho relataram mais de seis meses. Para esse cálculo, escolhemos períodos conservadores: uma hora para contas com alto desempenho e a média de um ano (8.760 horas) e seis meses (4.380 horas) para equipes com baixo desempenho. Com base nesses números, as elites têm tempo 6.570 vezes mais rápido para restaurar o serviço do que as de baixo desempenho. O tempo de restauração do desempenho do serviço permaneceu o mesmo para desempenhos de elite e aumentado para aqueles com baixo desempenho em comparação com 2019.

Taxa de falha nas mudanças

As equipes de elite relataram uma taxa de falha de alteração entre 0% e 15%, enquanto as de baixo desempenho relataram taxas de falha de 16% a 30%. A média entre esses dois intervalos mostra uma taxa de falha de 7,5% para falhas de alto desempenho e 23% para equipes com desempenho baixo. As taxas de falha de alteração para elites são três vezes melhores do que para as com desempenho inferior. Este ano, as taxas de falha nas alterações permaneceram as mesmas para os elites e melhorou para as de baixo desempenho em comparação a 2019, mas pioraram para os grupos de empresas intermediárias. 

Ao comparar o grupo de elite com os desenvolvedores de baixo desempenho, descobrimos que eles têm:

• 973x implantações de código mais frequentes
• 6.570 vezes mais rápido o tempo de lead da confirmação à implantação
• Taxa de falha de mudanças três vezes menor (as mudanças são 1/3 menos propensas a falhar) 
• 6570x mais rápido de recuperar incidentes 

Como podemos melhorar o SDO e o desempenho organizacional? Nossa pesquisa oferece orientações baseadas em evidências para ajudar você a se concentrar nos recursos que impulsionam o desempenho.

O relatório deste ano analisou o impacto da nuvem, práticas de SRE, segurança, práticas técnicas e cultura. Nesta seção, apresentamos cada um desses recursos e observamos o impacto deles em vários resultados. Para as pessoas que conhecem os modelos de pesquisa State of DevOps da DORA, criamos um recurso on-line que hospeda o modelo deste ano e todos os modelos anteriores.³

^{____________________________}

3. https://devops-research.com/models.htm

____________________________

De maneira consistente com o Accelerated State of DevOps 2019, cada vez mais organizações estão escolhendo soluções de nuvem híbrida e de várias nuvens. Em nossa pesquisa, os participantes foram perguntados sobre onde o serviço ou aplicativo principal estava hospedado e o uso da nuvem pública está aumentando. 56% dos entrevistados indicaram usar uma nuvem pública (incluindo várias nuvens públicas), um aumento de 5% em comparação a 2019. Este ano, também perguntamos especificamente sobre o uso de várias nuvens, e 21% dos entrevistados informaram a implantação em várias nuvens públicas. 21% dos entrevistados indicaram não usar a nuvem e, em vez disso, usaram um data center ou uma solução no local. Por fim, 34% dos participantes informaram usar uma nuvem híbrida e 29% usam uma nuvem privada. 

Acelere os resultados dos negócios com o modo híbrido e com várias nuvens

Este ano, observamos um crescimento no uso de nuvem híbrida e várias nuvens, com impacto significativo nos resultados importantes para as empresas. Os participantes que usam o modo híbrido ou de várias nuvens estavam 1,6 vez mais propensos a exceder as metas de desempenho organizacional do que aqueles que não usaram. Também vimos efeitos significativos no SDO com usuários de ambientes híbridos e de várias nuvens 1,4 vez mais propensos a se destacar em termos de frequência de implantação, tempo de lead para mudanças, tempo de recuperação, taxa de falha de alteração e confiabilidade.

Por que usar várias nuvens?

Assim como na avaliação de 2018, pedimos aos participantes que expliquem os motivos para usar vários provedores de nuvem pública. Em vez de selecionar todas as opções relevantes, este ano, pedimos aos participantes para informar o principal motivo do uso de vários provedores. Mais de um quarto (26%) dos entrevistados fizeram isso para aproveitar os benefícios exclusivos de cada provedor de nuvem. Isso sugere que, quando os participantes selecionam outro provedor, eles procuram diferenciação entre o provedor atual e as alternativas. O segundo motivo mais comum para migração para várias nuvens foi a disponibilidade (22%). É claro que os participantes que adotaram vários provedores de nuvem tinham 1,5 vez mais chances de atingir ou exceder as metas de confiabilidade.

Principal motivo para usar vários provedores

Alterações nos comparativos de mercado

Como implementar a infraestrutura em nuvem

Historicamente, descobrimos que nem todos os participantes adotam a nuvem da mesma maneira. Isso leva a uma variação na eficácia da adoção da nuvem para a geração de resultados comerciais. Abordamos essa limitação focando nas características essenciais da computação em nuvem, conforme definido pelo Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês), e usando isso como nosso guia. Ao usar a definição de computação em nuvem do NIST, investigamos o impacto de práticas essenciais no desempenho do SDO em vez de apenas analisar o impacto da adoção da nuvem no SDO.

Pela terceira vez, descobrimos que o que realmente importa é como as equipes implementam os serviços de nuvem, não apenas o uso de tecnologias de nuvem. Os artistas de elite tinham 3,5 vezes mais chances de atender a todas as características essenciais da nuvem do NIST. Apenas 32% dos entrevistados que afirmaram usar a infraestrutura em nuvem concordaram ou concordaram totalmente que eles atendem a todas as cinco características essenciais da computação em nuvem definidas pelo NIST, um aumento de 3% em relação a 2019. No geral, o uso das características da computação em nuvem do NIST aumentou de 14% a 19%, com uma elasticidade rápida mostrando o maior aumento.

Autoatendimento sob demanda

Os consumidores podem provisionar recursos de computação conforme necessário, automaticamente, sem qualquer interação humana necessária na parte do provedor.

73% dos entrevistados usaram o autoatendimento, um aumento de 16% em 2019.

Acesso amplo à rede

Os recursos estão amplamente disponíveis e podem ser acessados por vários clientes, como smartphones, tablets, laptops e estações de trabalho.

74% dos entrevistados usaram acesso amplo à rede, um aumento de 14% em 2019.

Pool de recursos

Os recursos do provedor são agrupados em um modelo multilocatário, com recursos físicos e virtuais atribuídos e reatribuídos dinamicamente sob demanda. O cliente geralmente não tem controle direto sobre o local exato dos recursos fornecidos, mas pode especificar a localização em um nível de abstração mais alto, como país, estado ou data center.

73% dos entrevistados usaram pool de recursos, um aumento de 15% em 2019.

Elasticidade rápida

Os recursos podem ser provisionados e liberados de maneira elástica para expandir ou reduzir a demanda rapidamente. Os recursos disponíveis para provisionamento parecem ser ilimitados e podem ser apropriados em qualquer quantidade a qualquer momento.

77% dos entrevistados usaram elasticidade rápida, um aumento de 18% em 2019.

Serviço mensurado

Os sistemas do Cloud controlam e otimizam automaticamente o uso de recursos com um recurso de medição em um nível de abstração adequado ao tipo de serviço, como armazenamento, processamento, largura de banda e contas de usuário ativas. É possível monitorar e controlar o uso de recursos, além de gerar relatórios sobre a transparência no uso. 

78% dos entrevistados usaram o serviço medido, um aumento de 16% em 2019.

Enquanto a comunidade de DevOps estava surgindo em conferências e conversas públicas, um movimento de mentalidade semelhante estava se formando no Google: engenharia de confiabilidade do site (SRE). SRE e abordagens semelhantes, como a disciplina de engenharia de produção do Facebook, aderem às mesmas metas e técnicas que motivam o DevOps. Em 2016, a SRE entrou oficialmente no discurso público quando o primeiro livro⁴ sobre engenharia de confiabilidade do site foi publicado. Desde então, o movimento tem crescido. Hoje, uma comunidade global de profissionais de SRE colabora em práticas para operações técnicas.

Talvez inevitavelmente houve confusão. Qual é a diferença entre SRE e DevOps? Preciso escolher uma delas? Qual é melhor? Na verdade, não há conflito aqui. SRE e DevOps são altamente complementares, e nossa pesquisa demonstra o alinhamento deles. A SRE é uma disciplina de aprendizado que prioriza a comunicação multifuncional e a segurança psicológica, os mesmos valores que estão no centro da cultura generativa orientada a desempenho, típica das equipes de DevOps de elite. Estendendo-se pelos princípios básicos, o SRE fornece técnicas práticas, incluindo o framework de métricas de objetivo do indicador de nível de serviço/objetivo de nível de serviço (SLI/SLO). Assim como o framework de produto enxuto especifica como alcançar os ciclos de feedback rápidos dos clientes compatíveis com nossa pesquisa, o framework de SRE oferece definição de práticas e ferramentas que podem melhorar a capacidade de uma equipe manter consistentemente promete aos usuários.

Em 2021, ampliamos nossa consulta sobre operações, expandindo de uma análise de disponibilidade de serviço para a categoria mais geral de confiabilidade. A pesquisa deste ano introduziu vários itens inspirados em práticas de SRE para avaliar o grau em que as equipes:

• Definir a confiabilidade em termos de comportamento voltado ao usuário
• Usar o framework de métricas do SLI/SLO para priorizar o trabalho de acordo com os orçamentos de erro 
• Use a automação para reduzir o trabalho manual e alertas que causam interrupções
• Definir protocolos e exercícios de preparação para resposta a incidentes
• Incorporar princípios de confiabilidade ao longo do ciclo de vida de entrega de software ("mudar para a esquerda").

Ao analisar os resultados, encontramos evidências de que as equipes que se destacam nessas práticas operacionais modernas têm 1,4 vez mais chances de informar um melhor desempenho de SDO e 1,8 vez mais chances de informar melhores resultados de negócios.

As práticas de SRE foram adotadas pela maioria das equipes em nosso estudo: 52% dos participantes informaram o uso dessas práticas até certo ponto, embora a profundidade de adoção varie. substancialmente entre as equipes. Os dados indicam que o uso desses métodos prevê maior confiabilidade e melhor desempenho geral do SDO: o SRE impulsiona o sucesso do DevOps. 

Além disso, descobrimos que um modelo de operações de responsabilidade compartilhada, refletido no nível em que os desenvolvedores e operadores podem, juntos, contribuir para a confiabilidade, também prevê melhores resultados de confiabilidade.

Além de melhorar as medidas objetivas de desempenho, a SRE melhora a experiência de trabalho dos profissionais técnicos. Normalmente, pessoas com uma grande carga de tarefas operacionais são propensas a burnout, mas a SRE tem um efeito positivo. Descobrimos que quanto mais uma equipe emprega práticas de SRE, menor a probabilidade de que os membros tenham burnout. A SRE também pode ajudar a otimizar recursos: as equipes que atendem aos objetivos de confiabilidade usando o relatório de práticas de SRE informam que passam mais tempo escrevendo código do que as equipes que não praticam SRE.

Nossa pesquisa revela que as equipes em qualquer nível de desempenho do SDO, de baixo a elite, provavelmente receberão benefícios pelo aumento do uso de práticas de SRE. Quanto melhor o desempenho de uma equipe, maior a probabilidade de empregar os modos modernos de operações: as equipes de elite têm 2,1 vezes mais probabilidade de relatar o uso de práticas de SRE como empresas de baixo desempenho. Mas mesmo as equipes que operam nos níveis mais altos têm espaço para crescimento: apenas 10% dos entrevistados de elite indicam que as equipes implementaram totalmente todas as práticas de SRE que investigamos. À medida que o desempenho dos SDOs em todos os setores continua a avançar, a abordagem de cada equipe em relação às operações é um fator essencial para a melhoria contínua do DevOps.

____________________________

4. Betsy Beyer et al., eds., Site Reliability Engineering (O’Reilly Media, 2016).

____________________________

Documentação

Neste ano, observamos a qualidade da documentação interna, que é a documentação (como manuais, READMEs e até comentários do código) dos serviços e aplicativos que um equipe trabalha. Medimos a qualidade pelo grau em que a documentação:

• Ajuda os leitores a alcançar metas
• É precisa, atualizada e abrangente.
• É encontrada, bem organizada e clara⁵ ;

Gravar e acessar informações sobre sistemas internos é uma parte essencial do trabalho técnico de uma equipe. Descobrimos que cerca de 25% dos participantes têm documentação de boa qualidade, e o impacto desse trabalho é claro: equipes com documentação de qualidade superior são 2,4 vezes mais propensas a ver melhor desempenho da exibição e operacional (SDO) de software. Equipes com uma boa documentação entregam software com mais rapidez e confiabilidade do que aquelas com má documentação. A documentação não precisa ser perfeita. Nossa pesquisa mostra que qualquer melhoria na qualidade da documentação tem um impacto positivo e direto no desempenho.

O ambiente tecnológico atual tem sistemas cada vez mais complexos, além de especialistas e papéis especializados para diferentes aspectos desses sistemas. Da segurança aos testes, a documentação é uma maneira importante de compartilhar conhecimento e orientação especializada entre essas subequipes especializadas e com a equipe em geral.

Descobrimos que a qualidade da documentação prevê o sucesso das equipes na implementação de práticas técnicas. Essas práticas, por sua vez, preveem melhorias nos recursos técnicos do sistema, como observabilidade, testes contínuos e automação de implantação. Descobrimos que as equipes com documentação de qualidade são:

• 3,8 vezes mais propenso a implementar práticas de segurança
• 2,4 vezes mais probabilidade de atingir ou exceder suas metas de confiabilidade
• 3,5 vezes mais provável de implementar práticas de engenharia de confiabilidade do site (SRE) 
• 2,5 vezes mais probabilidade de aproveitar plenamente a nuvem

Como melhorar a qualidade da documentação

O trabalho técnico envolve encontrar e usar informações, mas a documentação de qualidade depende de pessoas escrevendo e mantendo o conteúdo. Em 2019, nossa pesquisa descobriu que o acesso a fontes de informações internas e externas aumenta a produtividade. A pesquisa deste ano vai um pouco além na análise da qualidade da documentação que é acessada e das práticas que têm impacto na qualidade dessa documentação.

Nossa pesquisa mostra que as seguintes práticas têm um impacto positivo significativo na qualidade da documentação:

Documente casos de uso essenciais para seus produtos e serviços. O que você documenta sobre um sistema é importante, e os casos de uso permitem que seus leitores coloquem as informações e os sistemas em funcionamento.

Crie diretrizes claras para atualizar e editar a documentação existente. Grande parte do trabalho da documentação é manter o conteúdo existente. Quando os membros da equipe sabem como fazer atualizações ou remover informações imprecisas ou desatualizadas, a equipe pode manter a qualidade da documentação, mesmo com a mudança do sistema ao longo do tempo.

Defina os proprietários. As equipes que têm documentações de qualidade têm maior probabilidade de definir claramente a propriedade dos documentos. A propriedade permite responsabilidades explícitas para gravar novos conteúdos e atualizar ou verificar mudanças no conteúdo existente. As equipes com documentação de qualidade têm maior probabilidade de declarar que elas foram escritas para todos os principais recursos dos apps em que trabalham, e ter uma propriedade clara ajuda a criar essa ampla cobertura.

Inclua a documentação como parte do processo de desenvolvimento de software. As equipes que criaram a documentação e a atualizaram à medida que o sistema foi alterado têm documentação de maior qualidade. Assim como os testes, a criação e a manutenção de documentação são parte essencial de um processo de desenvolvimento de software de alto desempenho.

Reconhecer o trabalho da documentação durante avaliações e promoções de desempenho. O reconhecimento está correlacionado com a qualidade geral da documentação. Escrever e manter a documentação é uma parte essencial do trabalho de engenharia de software, e tratá-la como tal melhora a qualidade.

Outros recursos compatíveis com a documentação de qualidade são:

• Treinamento sobre como escrever e manter a documentação
• Teste automatizado para amostras de código ou documentação incompleta
• Diretrizes, como guias de estilo de documentação e guias para escrever para um público global

A documentação é fundamental para a implementação de recursos de DevOps. A documentação de qualidade mais alta amplia os resultados dos investimentos em recursos individuais de DevOps, como segurança, confiabilidade e uso completo da nuvem. A implementação de práticas que auxiliam na documentação de qualidade compensa por meio de recursos técnicos mais avançados e maior desempenho de SDO.

____________________________

5. Métricas de qualidade informadas por pesquisas existentes sobre a documentação técnica, como:

— Aghajani, E. et al. (2019). Software Documentation Issues Unveiled. Proceedings of the 2019 IEEE/ACM 41st International Conference on Software Engineering, 1199-1210. https://doi.org/10.1109/ICSE.2019.00122

— Plösch, R., Dautovic, A., & Saft, M. (2014). The Value of Software Documentation Quality. Proceedings of the International Conference on Quality Software, 333-342. https://doi.org/10.1109/QSIC.2014.22

— Zhi, J. et al. (2015). Cost benefits and quality of software development documentation: A systematic mapping. Journal of Systems and Software, 99(C), 175-198. https://doi.org/10.1016/j.jss.2014.09.042

____________________________

Segurança

[Shift à esquerda] e integrar ao todo

À medida que as equipes de tecnologia continuam a acelerar e evoluir, o mesmo acontece com a quantidade e a sofisticação das ameaças de segurança. Em 2020, mais de 22 bilhões de registros de informações pessoais confidenciais ou dados da empresa foram expostos, de acordo com o relatório 2020 Threat Landscape Retrospective da Tenable.⁶ O Security pode Ele não pode ser uma decisão final ou uma etapa final antes da entrega. Ela precisa ser integrada ao longo do processo de desenvolvimento do software.

Para entregar software com segurança, as práticas de segurança precisam evoluir mais rapidamente do que as técnicas usadas por agentes maliciosos. Durante os ataques da cadeia de suprimentos de software SolarWinds e Codecov 2020, os hackers comprometeram o sistema de compilação da SolarWinds e o script de envio bash da Codecov.⁷ para incorporar escondida na infraestrutura de milhares de clientes dessas empresas. Devido ao impacto generalizado desses ataques, o setor precisa passar de uma abordagem preventiva para um diagnóstico, em que as equipes de software precisam presumir que os sistemas já estão comprometidos e criar segurança na cadeia de suprimentos.

De maneira consistente com os relatórios anteriores, descobrimos que os artistas de elite se destacam na implementação de práticas de segurança. Este ano, os desenvolvedores de elite que alcançaram ou excederam as metas de confiabilidade tinham duas vezes mais chances de ter segurança integrada no processo de desenvolvimento de software. Isso sugere que as equipes que aceleraram a entrega ao manter os padrões de confiabilidade encontraram uma maneira de integrar verificações e práticas de segurança sem comprometer a capacidade de entregar software de maneira rápida ou confiável.

Além de exibir a alta entrega e o desempenho operacional, as equipes que integram práticas de segurança em todo o processo de desenvolvimento têm 1,6 vez mais chances de atingir ou exceder as metas organizacionais. As equipes de desenvolvimento que adotam a segurança veem valor significativo gerado para os negócios.

____________________________

6. https://www.tenable.com/cyber-exposure/2020-threat-landscape-retrospective

7. https://www.cybersecuritydive.com/news/codecov-breach-solarwinds-software-supply-chain/598950/

____________________________

Como fazer isso corretamente

É fácil enfatizar a importância da segurança e sugerir que as equipes precisam priorizá-la, mas isso exige várias mudanças dos métodos tradicionais de segurança de informações. Você pode integrar a segurança, melhorar a entrega de software e o desempenho operacional e melhorar o desempenho organizacional ao usar as seguintes práticas:

Teste a segurança. Teste os requisitos de segurança como parte do processo de teste automatizado, incluindo áreas em que o código pré-aprovado precisa ser usado.

Integre a análise de segurança a cada fase. Integre a segurança das informações (InfoSec) ao trabalho diário de todo o ciclo de vida da entrega de software. Isso inclui fazer com que a equipe da InfoSec forneça informações durante as fases de design e arquitetura do aplicativo, participe de demonstrações de software e forneça feedback durante as demonstrações.

Avaliações de segurança. Faça uma análise de segurança de todos os principais recursos. Crie um código pré-aprovado. Peça para a equipe da InfoSec criar bibliotecas, pacotes, conjuntos de ferramentas e processos pré-aprovados e fáceis de usar para desenvolvedores e operadores de TI. Convide a InfoSec desde o início e com frequência. Inclua o InfoSec durante o planejamento e todas as fases subsequentes de desenvolvimento de aplicativos, para que eles possam detectar fraquezas relacionadas à segurança antecipadamente, o que dá à equipe tempo suficiente para corrigi-los.

Crie um código pré-aprovado. Peça para a equipe da InfoSec criar bibliotecas, pacotes, conjuntos de ferramentas e processos pré-aprovados e fáceis de usar para desenvolvedores e operadores de TI.

Convide a InfoSec desde o início e com frequência. Inclua o InfoSec durante o planejamento e todas as fases subsequentes de desenvolvimento de aplicativos, para que eles possam detectar fraquezas relacionadas à segurança antecipadamente, o que dá à equipe tempo suficiente para corrigi-los.

Como já observado, a documentação de alta qualidade impulsiona o sucesso de diversos recursos e a segurança não é exceção. Descobrimos que as equipes com documentação de alta qualidade tinham 3,8 vezes mais chances de integrar a segurança durante o processo de desenvolvimento. Nem todo mundo em uma organização tem experiência com criptografia. A experiência de quem faz isso é mais bem compartilhada em uma organização com práticas de segurança documentadas.

Nossa pesquisa mostra que as organizações que passam por uma transformação de DevOps adotando a entrega contínua têm mais chances de ter processos de alta qualidade, baixo risco e economia.

Especificamente, medimos as seguintes práticas técnicas:

• Arquitetura com acoplamento flexível
• Desenvolvimento baseado em troncos
• Teste contínuo
• Integração contínua
• Uso de tecnologias de código aberto
• Práticas de monitoramento e observabilidade
• Gerenciamento de alterações no banco de dados
• Automação de implantação

Descobrimos que, embora todas essas práticas melhorem a entrega contínua, a arquitetura acoplada com flexibilidade e o teste contínuo têm o maior impacto. Por exemplo, neste ano, descobrimos que os desenvolvedores de elite que atendem aos objetivos de confiabilidade têm três vezes mais chances de empregar uma arquitetura acoplada com flexibilidade do que os colegas de baixo desempenho.

Arquitetura levemente acoplada

Nossa pesquisa continua mostrando que é possível melhorar o desempenho da TI trabalhando para reduzir as dependências refinadas entre serviços e equipes. Na verdade, este é um dos indicadores mais fortes de entrega contínua bem-sucedida. Usando uma arquitetura acoplada com flexibilidade, as equipes podem escalonar, falhar, testar e implantar de maneira independente. As equipes podem avançar no próprio ritmo, trabalhar em lotes menores, acumular menos dívidas técnicas e se recuperar mais rapidamente em caso de falha.

Testes e integração contínuas

De acordo com nossas descobertas de anos anteriores, mostramos que o teste contínuo é um forte indicador de entrega contínua bem-sucedida. Os artistas de elite que atendem às metas de confiabilidade têm 3,7 vezes mais chances de aproveitar os testes contínuos. Ao incorporar testes antecipados e frequentes durante o processo de entrega, com testadores trabalhando com desenvolvedores ao longo do tempo, as equipes podem iterar e fazer mudanças nos produtos, serviços ou aplicativos com mais rapidez. Use esse ciclo para agregar valor aos clientes e incorpore facilmente práticas como testes automatizados e integração contínua. 

A integração contínua também melhora a exibição contínua. Os artistas de elite que atendem às metas de confiabilidade têm 5,8 vezes mais chances de aproveitar a integração contínua. Na integração contínua, cada confirmação aciona uma versão do software e executa uma série de testes automatizados que fornecem feedback em alguns minutos. Com a integração contínua, você diminui a coordenação manual e, muitas vezes, complexa, necessária para uma integração bem-sucedida.

A integração contínua, conforme definida por Kent Beck e a comunidade Extreme Programming, onde surgiu, também inclui a prática de desenvolvimento baseado em troncos, discutidas a seguir.⁷

Desenvolvimento baseado em troncos

Nossa pesquisa mostrou de maneira consistente que organizações de alto desempenho têm mais chances de implementar um desenvolvimento baseado em troncos, em que os desenvolvedores trabalham em pequenos lotes e mesclam o trabalho em um tronco compartilhado com frequência. Na verdade, os desenvolvedores de elite que atendem aos objetivos de confiabilidade têm 2,3 vezes mais chances de usar o desenvolvimento baseado em troncos. As equipes com menor desempenho são mais propensas a usar ramificações de longa duração e atrasar a mesclagem.

As equipes devem mesclar o trabalho pelo menos uma vez por dia, várias vezes por dia, se possível. O desenvolvimento baseado em entroncamento está intimamente relacionado à integração contínua. Portanto, implemente essas duas práticas técnicas simultaneamente, porque elas têm mais impacto quando são usadas em conjunto.

Automação de implantação

Em ambientes de trabalho ideais, os computadores realizam tarefas repetitivas, enquanto os humanos se concentram em resolver problemas. A implementação da automação de implantação ajuda as equipes a se aproximarem dessa meta. 

Ao fazer a migração de software para a produção de forma automática, diminui o tempo de lead, permitindo implantações mais rápidas e mais eficientes. Também reduz a probabilidade de erros, que são mais comuns em implantações manuais. Quando suas equipes usam a automação de implantação, elas recebem feedback imediato, o que pode ajudar a melhorar o serviço ou o produto a uma taxa muito mais rápida. Embora não seja necessário implementar testes contínuos, integração contínua e implantações automatizadas simultaneamente, é provável que você veja melhorias maiores ao usar essas três práticas juntas. 

Gerenciamento de mudanças no banco de dados

Rastrear alterações por meio do controle de versões é uma parte crucial da criação e manutenção de códigos e do gerenciamento de bancos de dados. Nossa pesquisa descobriu que os desenvolvedores de elite que atendem aos objetivos de confiabilidade têm 3,4 vezes mais chances de exercer a gestão de mudanças no banco de dados em comparação com os colegas de baixo desempenho. Além disso, para um bom gerenciamento da mudança no banco de dados, as chaves são a colaboração, a comunicação e a transparência para todas as equipes relevantes. Embora seja possível escolher uma das abordagens específicas a serem implementadas, recomendamos que, sempre que você precisar fazer mudanças no seu banco de dados, as equipes se reúnam e revisem as alterações antes que você as atualize. 

____________________________

8. Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley Professional

____________________________

Monitoramento e observabilidade

Assim como nos anos anteriores, descobrimos que as práticas de monitoramento e observabilidade são compatíveis com a entrega contínua. Os artistas de elite que atendem com sucesso a seus objetivos de confiabilidade têm 4,1 vezes mais chances de ter soluções que incorporam a observabilidade da integridade geral do sistema. As práticas de observabilidade ajudam suas equipes a entender melhor os sistemas, o que diminui o tempo necessário para identificar e resolver problemas. Nossa pesquisa também indica que as equipes com boas práticas de observabilidade passam mais tempo programando. Uma possível explicação para essa descoberta é que a implementação de práticas de observabilidade ajuda a afastar o tempo do desenvolvedor da pesquisa de causas de problemas para solução de problemas e, por fim, de volta à programação. 

Tecnologias de código aberto

Muitos desenvolvedores já usam tecnologias de código aberto, e a familiaridade delas com essas ferramentas é um diferencial para a organização. Uma desvantagem das tecnologias de software proprietário é que elas limitam sua capacidade de transferir conhecimento para dentro e fora da organização. Por exemplo, não é possível contratar alguém que já conheça as ferramentas da sua organização, e os desenvolvedores não podem transferir o conhecimento que acumularam para outras organizações. Por contraste, a maioria das tecnologias de código aberto tem uma comunidade ao redor delas que os desenvolvedores podem usar para receber suporte. As tecnologias de código aberto são mais acessíveis, relativamente menores e personalizáveis. Os artistas de elite que atendem às metas de confiabilidade têm 2,4 vezes mais chances de aproveitar as tecnologias de código aberto. Recomendamos que você comece a usar mais software de código aberto ao implementar a transformação do DevOps. 

Para saber mais sobre as capacidades técnicas de DevOps, consulte os recursos da DORA em https://cloud.google.com/devops/capabilities

COVID-19

Neste ano, investigamos os fatores que influenciaram o desempenho das equipes durante a pandemia da COVID-19. Especificamente, a pandemia da COVID-19 afetou negativamente o desempenho de entrega de software e operação (SDO, na sigla em inglês)? As equipes têm mais burnout? Por fim, que fatores são promissores para reduzir o burnout?

Primeiro, queremos entender o impacto da pandemia na entrega e no desempenho operacional. Muitas organizações priorizaram a modernização para acomodar mudanças drásticas do mercado (por exemplo, a mudança da compra presencial para on-line). Na seção "Como comparamos?" discutimos como o desempenho no setor de software acelerou significativamente e continua a evoluir. As equipes com maior desempenho agora são a maioria das nossas amostras, e as empresas de elite continuam elevando os padrões, fazendo implantações mais frequentes com tempos de lead mais curtos, tempos de recuperação mais rápidos e taxas de falha de alteração melhores. Da mesma forma, um estudo realizado por pesquisadores do GitHub mostrou um aumento na atividade do desenvolvedor (isto é, push, solicitações de envio, solicitações de envio analisadas e comentários por usuário⁹) em 2020. É provável que o setor tenha continuado a acelerar apesar da pandemia, e não por isso, mas é notável que não observamos uma diminuição no desempenho do SDO durante esse período significativo.

A pandemia mudou a forma como trabalhamos e, para muitos, os locais de trabalho. Por isso, analisamos o impacto do trabalho remoto como resultado da pandemia. Descobrimos que 89% dos entrevistados trabalharam em casa devido à pandemia. Apenas 20% relataram ter trabalhado de casa antes da pandemia. A mudança para um ambiente de trabalho remoto teve implicações significativas na maneira como desenvolvemos softwares, executamos negócios e trabalhamos juntos. Para muitas pessoas, trabalhar de casa eliminou a capacidade de se conectar em conversas urgentes ou colaborar pessoalmente. 

____________________________

9. https://octoverse.github.com/

____________________________

O que reduziu o burnout?

Apesar disso, encontramos um fator que teve um grande efeito sobre se uma equipe estava com problemas de burnout devido ao trabalho remoto: cultura. As equipes com uma cultura generativa, composta por pessoas que se sentiam incluídas e que faziam parte da equipe, tinham metade da probabilidade de passarem por burnout durante a pandemia. Essa descoberta reforça a importância de priorizar a equipe e a cultura. As equipes que se saem melhor são capazes de lidar com períodos mais desafiadores que pressionam a equipe e as pessoas individualmente. 

Cultura

Em linhas gerais, a cultura é a corrente interpessoal inescapável de cada organização. É algo que influencia como os funcionários pensam, sentem e se comportam em relação à organização e uns aos outros. Todas as organizações têm a própria cultura única, e nossas descobertas mostram consistentemente que a cultura é um dos principais impulsionadores do desempenho organizacional e de TI. Especificamente, nossas análises indicam que uma cultura generativa, medida com a tipografia de cultura organizacional de Westrum, e o senso de pertencimento e inclusão das pessoas na organização, prevê um nível mais alto. desempenho de entrega de software e desempenho operacional (SDO). Por exemplo, descobrimos que os artistas de elite que atendem aos objetivos de confiabilidade têm 2,9 vezes mais chances de ter uma cultura de equipe generativa do que os de baixo desempenho. Da mesma forma, uma cultura generativa prevê um maior desempenho organizacional e menores taxas de esgotamento de funcionários. Em resumo, a cultura realmente importa. Felizmente, a cultura é fluida, multifacetada e sempre em fluxo, o que pode ser alterado.

A execução bem-sucedida do DevOps requer que sua organização tenha equipes que trabalhem de forma colaborativa e multifuncional. Em 2018, descobrimos que as equipes de alto desempenho eram duas vezes mais propensas a desenvolver e fornecer software em uma equipe multifuncional. Isso reforça que a colaboração e a cooperação são essenciais para o sucesso de qualquer organização. Uma pergunta importante é: que fatores contribuem para a criação de um ambiente que incentive e celebre a colaboração multifuncional?

Ao longo dos anos, tentamos tornar a construção da cultura tangível e fornecer à comunidade DevOps uma melhor compreensão do impacto da cultura no desempenho organizacional e de TI. Começamos essa jornada definindo operacionalmente a cultura usando a tipografia de cultura organizacional de Westrum. Ele identificou três tipos de organizações: com foco em energia, em regras e em desempenho. Usamos esse framework na nossa própria pesquisa e descobrimos que uma cultura organizacional voltada para o desempenho que otimiza o fluxo de informações, a confiança, a inovação e o compartilhamento de riscos é preditivo ao alto desempenho de SDO.

À medida que nosso conhecimento sobre cultura e DevOps evoluímos, trabalhamos para expandir nossa definição inicial de cultura para incluir outros fatores psicossociais, como a segurança psicológica. As organizações de alto desempenho são mais propensas a ter uma cultura que incentiva os funcionários a correr riscos calculados e moderados sem medo de consequências negativas.

Pertencimento e inclusão

Considerando o forte impacto que a cultura tem no desempenho, este ano expandimos nosso modelo para descobrir se o sentimento de pertencimento e inclusão dos funcionários contribui para o efeito benéfico da cultura no desempenho.

A pesquisa psicológica mostrou que as pessoas são inerentemente motivadas a formar e manter relacionamentos fortes e estáveis com outras pessoas.¹⁰ Estamos motivados a se sentir conectados com outras pessoas e a se sentirem aceitos dentro os vários grupos que habitamos. Os sentimentos de pertencimento levam a uma ampla variedade de resultados físicos e psicológicos favoráveis. Por exemplo, pesquisas indicam que a sensação de pertencimento afeta de forma positiva a motivação e leva a melhorias na conquista acadêmica.¹¹

Um componente desse senso de conexão é que a pessoa deve se sentir confortável para entrar no trabalho e que as experiências e experiências únicas dela são valorizadas e celebradas.¹² Concentrar-se em criar culturas inclusivas que pertencem a uma organização ajuda a criar uma força de trabalho bem-sucedida, diversificada e motivada.

Nossos resultados indicam que as organizações com foco no desempenho que valorizam os serviços de inclusão e inclusão têm mais chances de ter níveis mais baixos de esgotamento dos funcionários do que organizações com culturas menos positivas.

Considerando as evidências que mostram como os fatores psicossociais afetam o desempenho do SDO e os níveis de burnout entre os funcionários, recomendamos que, caso você queira passar por uma transformação bem-sucedida de DevOps, invista em abordar problemas relacionados à cultura como parte dos seus esforços de transformação. 

____________________________

10. Baumeister & Leary, 1995. The need to belong: Desire for interpersonal attachments as a fundamental human motivation. Psychological Bulletin, 117(3), 497–529. https://doi.org/10.1037/0033-2909.117.3.497

11. Walton et al., 2012. Mere belonging: the power of social connections. Journal of Personality and Social Psychology, 102(3):513-32. https://doi.org/10.1037/a0025731

12. Mor Barak & Daya, 2014; Managing diversity: Toward a globally inclusive workplace. Sage. Shore, Cleveland, & Sanchez, 2018; Inclusive workplaces: A review and model, Human Resources Review. https://doi.org/10.1016/j.hrmr.2017.07.003

Com sete anos de pesquisa e mais de 32 mil respostas feitas por profissionais do setor, o Accelerated State of DevOps 2021 apresenta as práticas de desenvolvimento de software e DevOps que tornam as equipes e as organizações mais bem-sucedidas. 

Este ano, 1.200 profissionais que trabalham em vários setores ao redor do mundo compartilharam experiências para ajudar a entender melhor os fatores que geram maior desempenho. Em resumo, a representação entre informações demográficas e firmográficas permaneceu incrivelmente consistente.

Assim como nos anos anteriores, coletamos informações demográficas de cada participante da pesquisa. As categorias incluem gênero, deficiência e grupos sub-representados.

Informações demográficas e firmografia 

Neste ano, observamos uma representação consistente com os relatórios anteriores em categorias firmográficas, incluindo tamanho da empresa, setor e região. Mais de 60% dos entrevistados trabalham como engenheiros ou gerentes, e um terço trabalha no setor de tecnologia. Além disso, vemos a representação do setor de serviços financeiros, varejo e empresas industriais/de manufatura. 

____________________________

13. https://www.washingtongroup-disability.com/question-sets/wg-short-set-on-functioning-wg-ss/

____________________________

Gênero

De maneira consistente com pesquisas anteriores, a amostra deste ano consiste em 83% de homens, 12% de mulheres e 1% de pessoas não binárias. Os participantes disseram que as mulheres representam cerca de 25% das equipes, o que é um grande aumento em relação a 2019 (16%) e é valor que está alinhado ao ano de de 2018 (25%).

Deficiência

A deficiência é identificada em seis dimensões que seguem as orientações do Washington Group Short Set.¹³ Este é o terceiro ano em que perguntamos sobre deficiência. A porcentagem de pessoas com deficiência é consistente à do relatório de 2019, 9%.

Grupos pouco representados

Identificar-se como membro de um grupo sub-representado pode se referir a raça, gênero ou outra característica. Este é o quarto ano que perguntamos sobre a falta de representatividade. A porcentagem de pessoas que se identificam como sub-representadas aumentou um pouco, de 13,7% em 2019 para 17% em 2021.

Anos de experiência

Os participantes da pesquisa deste ano têm muita experiência e 41% têm pelo menos 16 anos de experiência. Mais de 85% dos nossos participantes tiveram pelo menos seis anos de experiência.

Departamentos

Os participantes compostos principalmente por pessoas que trabalham em equipes de desenvolvimento ou engenharia (23%), equipes de DevOps ou SRE (21%), gerentes (18%) e equipes de operações de TI ou infraestrutura (9%). Observamos uma diminuição na representação de consultores (4% em 2019 para 2%) e um aumento na diretoria executiva (4% em 2019 para 9%). 

Setor

Como nos relatórios anteriores do Accelerated State of DevOps, vemos que a maioria dos participantes trabalha no setor de tecnologia, seguido por serviços financeiros, varejo e outros.

Funcionários

De acordo com os relatórios anteriores do Accelerated State of DevOps, os participantes são de vários tamanhos de organizações. 22% dos entrevistados são de empresas com mais de 10.000 funcionários, e 7% são de empresas com 5.000 a 9.999 funcionários. Outros 15% dos entrevistados estão em organizações com 2.000 a 4.999 funcionários. Também vimos uma representação justa dos participantes de organizações com 500 a 1.999 funcionários (13%), de 100 a 499 funcionários (15%) e, por fim, de 20 a 99 funcionários (15%).

Tamanho da equipe

Mais da metade dos participantes (62%) trabalha em equipes com 10 ou menos membros (28% para 6 a 10, 27% para 2 a 5 e 6% para equipes de uma só pessoa). Outros 19% trabalham em equipes com 11 a 20 membros.

Regiões

A pesquisa deste ano teve uma redução nas respostas da América do Norte (de 50% em 2019 para 39% em 2021). Em vez disso, observamos um aumento na representatividade da Europa (de 29% em 2019 para 32% em 2021), Ásia (de 9% em 2019 para 13% em 2021), Oceania (de 4% em 2019 para 6% em 2021) e América do Sul (de 2% em 2019 para 4% em 2021).

Sistemas operacionais

A distribuição de sistemas operacionais também foi consistente com os relatórios State of DevOps anteriores. Também reconhecemos e agradecemos os participantes que ajudaram a destacar que nossa lista de sistemas operacionais poderia usar uma atualização. 

Este ano, observamos onde os participantes implantam o serviço ou aplicativo principal em que trabalham. Para nossa surpresa, uma grande proporção de participantes usa contêineres (64%), com 48% usando máquinas virtuais (VMs). Isso pode refletir uma mudança no setor para tecnologias de destino de implantação mais modernas. Verificamos as diferenças entre diferentes tamanhos de empresa e não encontramos diferenças significativas entre os destinos de implantação.

As equipes que usam os princípios e recursos podem oferecer software de maneira rápida e confiável, ao mesmo tempo em que geram valor diretamente para a empresa. Neste ano, investigamos os efeitos das práticas de SRE, uma cadeia de suprimentos de software segura e a documentação de qualidade. Também vimos como aproveitar os recursos da nuvem. Cada área permite que pessoas e equipes sejam mais eficazes. Nosso foco é a importância de estruturar soluções que atendam às pessoas que aproveitam esses recursos, e não adequar as pessoas à solução.

Agradecemos a todos que contribuíram com a pesquisa deste ano e esperamos que ela ajude você e sua organização a criar equipes e softwares melhores, além de manter o equilíbrio entre trabalho e vida pessoal.

O relatório deste ano foi disponibilizado por uma grande família de colaboradores incríveis. Elaboração de perguntas, análises, textos, edições e elaboração de relatórios da pesquisa são apenas algumas das formas como nossos colegas ajudaram a realizar este grande esforço. Os autores gostariam de agradecer a todas essas pessoas pelas contribuições e orientações no relatório deste ano. Os agradecimentos estão em ordem alfabética pelo sobrenome.

Dustin Smith

Dustin Smith é um psicólogo de fatores humanos e gerente de pesquisa de experiência do usuário no Google. Ele trabalhou no projeto DORA por três anos. Nos últimos sete anos, ele estudou como as pessoas são afetadas pelos sistemas e ambientes ao redor delas em vários contextos: engenharia de software, jogos sem custo para jogar, saúde e militares. A pesquisa dele no Google identifica áreas em que os desenvolvedores de software podem se sentir mais felizes e mais produtivos durante o desenvolvimento. Ele trabalhou no projeto DORA por dois anos. Dustin é PhD em Psicologia Fatorial Humana pela Wichita State University.

Daniella Villalba

Daniella Villalba é pesquisadora de experiência do usuário dedicada ao projeto DORA. O foco dela é entender os fatores para deixar os desenvolvedores felizes e produtivos. Antes do Google, Daniella estudou os benefícios do treinamento de meditação, os fatores psicossociais que afetam as experiências de estudantes universitários, a memória de testemunhas e confissões falsas. Ela é doutora em psicologia experimental pela Universidade Internacional da Flórida. 

Michelle Irvine

Michelle Irvine é uma escritora técnica do Google que trabalha para preencher a lacuna entre as ferramentas para desenvolvedores e as pessoas que as usam. Antes do Google, ela atuou no setor editorial da área de educação e como escritora de conteúdo técnico para um software de simulação física. Michelle é formada em Física e mestre em Retórica e Design de Comunicação na Universidade de Waterloo.

Dave Stanke

Dave Stanke é um engenheiro de relações com o desenvolvedor no Google. Ele dá consultoria sobre práticas recomendadas para adotar DevOps e SRE. Dave já ocupou várias posições ao longo da carreira, incluindo CTO de startup, gerente de produtos, suporte ao cliente, desenvolvedor de software, sysadmin e designer gráfico. Ele tem mestrado em administração de tecnologia pela Universidade Columbia.

Nathen Harvey

Nathen Harvey é engenheiro de relações com desenvolvedores do Google. Ao longo de sua carreira, ele ajudou equipes a descobrir o próprio potencial ao mesmo tempo que alinhou a tecnologia aos resultados dos negócios. Nathen teve o privilégio de trabalhar com algumas das melhores equipes e comunidades de código aberto, ajudando a aplicar os princípios e as práticas de DevOps e SRE. Nathen coeditou e contribuiu para "97 Things Every Cloud Engineer Should Know", O'Reilly 2020.

Projeto de pesquisa

Este estudo usa um modelo multiseccional com base na teoria. Esse design com base em teoria é conhecido como preditivo e é um dos tipos mais comuns de pesquisa de negócios e tecnologia. O design inferido é usado quando o design puramente experimental não é possível e os experimentos de campo são preferidos.

População e amostragem

Nossa população segmentada para esta pesquisa foi composta por profissionais e líderes que trabalham ou estão perto de usar tecnologias e transformações, principalmente as que estão familiarizadas com DevOps. Promovemos a pesquisa usando listas de e-mails, promoções on-line, um painel on-line e mídias sociais. Além disso, pedimos às pessoas que compartilhassem a pesquisa em suas redes (ou seja, com amostragem de bolas de neve).

Como criar construções latentes

Formulamos nossas hipóteses e construções usando construções validadas anteriormente sempre que possível. Desenvolvemos novas construções com base em teoria, definições e informações de especialistas. Depois procuramos esclarecer a intenção para aumentar a probabilidade de que os dados coletados na pesquisa sejam confiáveis e válidos.¹⁴

Métodos de análise estatística

Análise de cluster. Usamos a análise de cluster para identificar nossos perfis de desempenho de entrega de software com base na frequência de implantação, tempo de lead, tempo para restaurar o serviço e alterar a taxa de falha. Usamos uma análise de classe latente¹⁵ porque não tínhamos motivos industriais ou teóricos para ter um número predeterminado de clusters e usamos o critério de informações bayesiano16 para determinar o número ideal de clusters.

Modelo de medição. Antes de realizar a análise, identificamos construções usando a análise fatorial com a análise do componente principal usando a rotação varimax.¹⁷ Confirmamos estatísticas testes de validade e confiabilidade convergentes e divergentes usando a variação média extraída (AVE), a correlação, a versão Alfa do Cronbach,¹⁸ e a confiabilidade composta.

Modelagem de equação estrutural. Testamos os modelos de equação estrutural (SEM) usando a análise de mínimos quadrados parciais (PLS, na sigla em inglês), que são um SEM baseado em correlação.¹⁹

^{________________________}

14. Churchill Jr, G. A. "A paradigm for developing better measures of marketing constructs", Journal of Marketing Research 16:1, (1979), 64–73.

15. Hagenaars, J. A., & McCutcheon, A. L. (Eds.). (2002). Applied latent class analysis. Cambridge University Press.

16. Vrieze, S. I. (2012). Model selection and psychological theory: a discussion of the differences between the Akaike information criterion (AIC) and the Bayesian information criterion (BIC). Psychological methods, 17(2), 228.

17. Straub, D., Boudreau, M. C., & Gefen, D. (2004). Validation guidelines for IS positivist research. Communications of the Association for Information systems, 13(1), 24.

18. Nunnally, J.C. Psychometric Theory. New York: McGraw-Hill, 1978

19. Hair Jr, J. F., Hult, G. T. M., Ringle, C. M., & Sarstedt, M. (2021). “A primer on partial least squares structural equation modeling (PLS-SEM).” Sage publications

Veja mais informações sobre os recursos de DevOps em https://cloud.google.com/devops/capabilities

Encontre recursos em engenharia de confiabilidade do site (SRE) em

https://sre.google

Faça a verificação rápida do DevOps:

https://www.devops-research.com/quickcheck.html

Explore o programa de pesquisa de DevOps:

https://www.devops-research.com/research.html

Saiba mais sobre o Programa de Modernização de Aplicativos do Google Cloud:

https://cloud.google.com/solutions/camp

Leia o artigo "O ROI da transformação de DevOps: como quantificar o impacto das suas iniciativas de modernização":

https://cloud.google.com/resources/roi-of-devops-transformation-whitepaper

Veja relatórios anteriores do estado de DevOps:

Estado do DevOps 2014: https://services.google.com/fh/files/misc/state-of-devops-2014.pdf

Estado do DevOps 2015: https://services.google.com/fh/files/misc/state-of-devops-2015.pdf

Estado do DevOps 2016: https://services.google.com/fh/files/misc/state-of-devops-2016.pdf

Estado do DevOps 2017: https://services.google.com/fh/files/misc/state-of-devops-2017.pdf

Accelerate State of DevOps 2018: https://services.google.com/fh/files/misc/state-of-devops-2018.pdf

Acelerar o estado das DevOps 2019:

https://services.google.com/fh/files/misc/state-of-devops-2019.pdf