Tchau, Tchau, DORA: Falhas do estado dos relatórios DevOps

Há dois anos, estudei o impacto do esgotamento dos desenvolvedores nos engenheiros de software e descobri que 83% sofriam de esgotamento . Nos últimos meses, tenho trabalhado em pesquisas adicionais sobre as percepções do desenvolvimento de software para diversas organizações, incluindo descobertas de que 75% dos engenheiros de software enfrentaram retaliação na última vez que relataram irregularidades e que 89% dos líderes empresariais estavam preocupados com o entrega pontual de software .

A equipe DORA do Google conduziu durante vários anos suas próprias pesquisas com engenheiros de software e os autores originais da estrutura de medição já produziram outras estruturas, incluindo SPACE e DevEx. Embora eu originalmente confiasse na pesquisa produzida por essas equipes, à medida que conduzia pesquisas adicionais, as falhas tornaram-se evidentes.

Durante o período de férias, estive lendo o livro do Dr. Andrew Jenkinson "Por que comemos (demais): a nova ciência do apetite", no livro que o Dr. Jenkinson critica um estudo conhecido como Estudo dos Sete Países, do Dr. Ancel Keys. O Dr. Jenkinson descreve o sucesso do Dr. Key da seguinte forma: “Ele venceu a discussão sobre seu maior rival, derrotando-o com fatos indiscutíveis, expondo sua lógica falha. A adulação da multidão o encheu de alegria e êxtase. O trabalho de sua vida havia alcançado frutos. O financiamento para sua pesquisa chegaria e sua reputação como cientista líder em sua área ficaria garantida por anos. A fama era boa, mas agora ele havia garantido os dois principais prêmios reais: poder e influência.”

No entanto, o Dr. Jenkinson observa: “Ele não foi desonesto em sua pesquisa – isso seria antiético e o desacreditaria. Tecnicamente, o que ele apresentou era a verdade. Mas ele sabia muito bem que não era toda a verdade.”

À medida que estudei os resultados da pesquisa da DORA e trabalhei posteriormente com mais detalhes, os paralelos entre essa descrição e o rigor da pesquisa no Relatório sobre o estado do DevOps da DORA e na estrutura subsequente do SPACE e do DevEx tornaram-se evidentes.

Onde estão os dados?

Em primeiro lugar, a investigação DORA é conduzida através de amostragem de milhares de programadores através da utilização de inquéritos subjetivos. Esta pesquisa é conduzida internamente pela equipe DORA. Normalmente, aqueles que realizam esse tipo de investigação para ganhar a vida juntaram-se a organizações como a Market Research Society (MRS) e o British Polling Council (BPC) para garantir que o público possa ter confiança na investigação realizada pelas organizações que são membros. Por exemplo; As regras do BPC impõem regras rígidas de divulgação a seus membros, exigindo que divulguem tabelas de dados completas com as perguntas feitas no prazo de 2 dias úteis após a publicação da pesquisa.

Aqui reside o nosso primeiro problema; a equipe DORA não publica seus dados brutos, apenas publica seu Relatório de Estado de DevOps.

Metodologia falha

A pesquisa DORA do Google e as estruturas SPACE e DevEx usadas nas configurações da equipe usam pesquisas subjetivas para criar medições. Ao usar pesquisas subjetivas, é importante tomar medidas para garantir que não haja preconceitos.

No entanto, a DORA utiliza quatro métricas principais para medir os resultados: tempo de execução da mudança, frequência de implantação, taxa de falha da mudança e tempo de recuperação (anteriormente tempo médio de recuperação). Estas são essencialmente medidas da velocidade de implantação de novos recursos e da velocidade de resolução de problemas.

Imagine que você perguntasse a algumas pessoas “Seus colegas comem muitas verduras?” e “Seus colegas malham muito?”. Aqueles que se sentem melhor em relação ao seu local de trabalho provavelmente teriam maior probabilidade de responder “sim” a ambas as perguntas – isto não significa que comer mais verduras levará sempre a maiores níveis de frequência ao ginásio. Embora possa haver uma correlação, não criamos uma relação de causa e efeito.

A investigação da DORA argumenta que a velocidade e a fiabilidade andam de mãos dadas, no entanto, fazem-no com base em medidas de resultados inteiramente baseadas na velocidade. Além disso, a utilização de inquéritos subjetivos pode influenciar os destinatários que se sentem melhor em relação ao seu trabalho a responder “sim” a ambas as perguntas. E embora as empresas mais competentes possam inevitavelmente ser mais competentes em ambos os factores, isso não cria uma relação causal.

Por exemplo; considere o quão altamente considerada é a confiabilidade do software de aviação, em comparação com a implantação pouco frequente de software em aeronaves. Ou considere como a Toyota, pioneira em metodologias ágeis, no caso de confiabilidade de software “Bookout v. Toyota” sobre um bug de aceleração não intencional que levou a fatalidades, admitiu na comunicação interna que "Na verdade, tecnologias como a failsafe não fazem parte do Toyota DNA da divisão de engenharia". Ou considere como durante o escândalo Horizon IT - responsabilizado por vários suicídios e pelo que foi descrito como “o erro judiciário mais generalizado na história do Reino Unido”, com pessoas presas injustamente, incluindo uma mulher grávida - o desenvolvedor de software, Fujitsu, foi pioneiro no uso de um metodologia ágil para desenvolvimento de software, nomeadamente Rapid Application Development .

Resultados de medição falhos

Conforme discutido, a pesquisa DORA avaliou quatro métricas principais que avaliam a velocidade de implantação de novos trabalhos e correção de bugs para avaliar o desempenho. No entanto, estas métricas só importam na medida em que são resultados úteis para medir.

Conduzi pesquisas com engenheiros de software e com uma amostra representativa do público em geral (com a empresa de pesquisa Survation) e descobri que ambos concordam que a velocidade é o fator menos importante. Em vez disso, o público se preocupa mais com a segurança e a precisão dos dados e com a prevenção de bugs graves. É difícil encontrar uma hipótese que ligue as Quatro Métricas Chave a estes resultados que os desenvolvedores de software e o público dizem ser os mais importantes - especialmente tendo em conta que prevenir bugs graves é uma prioridade menor do que corrigir bugs rapidamente ou trabalhar rapidamente. Mesmo para outros fatores, como segurança de dados, é difícil ver como eles se conectam a qualquer uma das Quatro Métricas Principais.

Mesmo entre os decisores empresariais, parece que a entrega no prazo é mais importante do que a entrega rápida. De acordo com a pesquisa que conduzi com a JL Partners, 98% desses tomadores de decisão de negócios no Reino Unido e 96% nos EUA concordam com a afirmação “O objetivo de uma equipe de engenharia de software é entregar software de alta qualidade no prazo”, com 65% no Reino Unido e 62% nos EUA concordam fortemente.

Finalmente; a pesquisa que conduzi com a Survation descobriu que a confiança nos engenheiros de software e as expectativas de confiabilidade do público podem variar consideravelmente de indústria para indústria, o que significa que uma abordagem única deve ser desencorajada em favor do que o Engineering Council UK sugere em seu Orientação sobre Risco : “adotar uma abordagem de tomada de decisão que seja proporcional ao risco e consistente com o apetite ao risco definido pela sua organização”.

Siga o dinheiro

Tal como o Dr. Keys recebeu financiamento da indústria açucareira para a sua investigação - em muitas investigações, é importante seguir o dinheiro para compreender onde residem os incentivos. A equipe DORA começou originalmente a fazer relatórios sobre o estado do DevOps para a Puppet, uma empresa focada na automação da infraestrutura de TI e agora faz esse trabalho para o Google Cloud. Ambos têm interesse em que os desenvolvedores possam implantar o trabalho o mais rápido possível. Isto não significa, contudo, que seja a solução para todos os nossos problemas.

A DORA contribuiu para o mundo da engenharia de software ao adicionar um grau de avaliação empírica ao processo. No entanto, devemos evitar confundir o material de marketing com toda a verdade e reconhecer as falhas em tal investigação.