A capa do 2017 State of DevOps Report.

Foi publicado mês passado o 2017 State of DevOps Report, um estudo publicado anualmente pela Puppet e DORA (DevOps Research & Assessment). Este estudo é uma leitura obrigatória para todo mundo, seja qual for a sua maturidade na adoção do DevOps.

Os números são surpreendentes por si só. DevOps funciona e times de alto desempenho, comparados com times de baixo desempenho:

  • Fazem mais deploys e mais rapidamente
    • Frequência de deploys 46 vezes maior
    • Templo de ciclo de commit para deploy 440 vezes mais rápido
  • Falham menos e se recuperam mais rapidamente
    • Tempo médio para recuperação de interrupção 96 vezes mais rápido
    • Taxa de falhas 5 vezes menor
  • Automatizam mais
    • A gestão de configuração é 33% mais automatizada
    • Os testes são 27% mais automatizados
    • Os deploys são 30% mais automatizados
    • O processo de aprovação de mudança é 27% mais automatizado
  • Tem 2 vezes mais chances de alcançar os objetivos

E agora, os meus três destaques.

Modelo de maturidade e melhoria contínua

Meu primeiro destaque não é sobre os números ou sobra uma descoberta chave. É sobre o modelo de maturidade do estudo. Eles classificam times de baixa, média e alta performance usando uma abordagem orientada por dados. A classificação é um resultado da análise anual da performance da TI, o que previne que times e organizações caiam numa “armadilha de sucesso”: após alcançar o nível de performance desejado, a melhoria contínua para, já que o objetivo era estático.

Este modelo de maturidade é um alvo em movimento, não um objetivo estático, e está realmente alinhado com o princípio da melhoria contínua do Lean. Times de alta performance e organizações inovadoras sabem que essa é a chave para a excelência.

Arquitetura

O segundo destaque vai para à arquitetura. Do estudo:

Em times de alta performance, a arquitetura do sistema é projetada para que times de entrega possam testar, fazer deploy e mudar seus sistemas sem depender de outros times para trabalho adicional, por recursos, aprovações e de vai-e-vem de comunicação. Portanto, nós descrevemos tanto a arquitetura quanto os times como sendo frouxamente acoplados.

E continua:

Abordagens arquiteturais que permitem esta estratégia incluem o uso de contextos delimitados (bounded contexts) e APIs como uma forma de desacoplar grandes domínios, resultando em unidades menores e mais frouxamente acopladas. A arquitetura também deve permitir o uso de dublês de testes e virtualização para permitir os testes dos serviços ou dos componentes de forma isolada. Arquiteturas orientadas a serviço presumem estas facilidades, como qualquer arquitetura que é realmente de microserviços deve presumir.

Não é surpresa que os Contextos Delimitados (Bounded Contexts) do Domain-Driven Design (DDD) seja citado como uma abordagem arquitetural que suporta esses times de alta performance. Para mim, DDD deveria ser parte da sua caixa de ferramentas na sua adoção DevOps1.

DDD também suporta naturalmente uma arquitetura microserviços. Sam Newman diz, em seu livro Building Microservices (ele também é um revisor desse estudo), que Contexto Delimitado é uma forma de modelar microserviços com alta coesão e baixo acoplamento.

A cobertura de Contexto Delimitado do Sam Newman é muito superficial. Eu recomendo a leitura de um dos livros do Vaughn Vernon para um tratamento correto do assunto.

Liderança

As características da liderança transformacional estão altamente correlacionadas com a performance da TI. De fato, nós observamos diferenças significativas nas características da liderança entre times de TI de baixa, média e alta performance. Times de alta performance reportaram terem líderes com os comportamentos mais fortes entre todas as dimensões: visão, comunicação inspiracional, estímulo intelectual, liderança de apoio e reconhecimento pessoal. Em contraste, times de baixa performance reportaram os menores níveis nessas características de liderança. As diferenças que encontramos foram estatisticamente significante em todos os níveis.

Você não pode subestimar como uma liderança ruim pode minar a performance de um time. Eu tenho o princípio de que todo mundo quer fazer um bom trabalho, mas gerenciar pessoas é difícil. E desenvolvimento de software é um esforço tecno-humano, e sem a parte humana, você não tem a parte tecnológica.

O que eu ouço das pessoas são as mesmas estórias de terror de sempre: gerentes que usam Ágil como sinônimo de uma corrida perpétua para jogar código em produção, sem se preocupar com qualidade, sem dar tempo para permitir melhoria contínua e uma completa alienação dos times de desenvolvimento, que são apenas macaquinhos codificadores. Pessoas infelizes, código ruim e ciclo de entrega lento.

As últimas quatro dimensões podem ser mapeadas diretamente para os três elementos da motivação do Daniel Pink. Se você não está preparado para trabalhar com a motivação das pessoas ou você não liga para o assunto, faça um favor a todos: peça demissão.

Conclusões

O estudo é de uma leitura simples e rápida, cheia de insights. DevOps, que começou como um movimento cultural, é agora algo maior, amplamente divulgado e que está movendo-se no caminho do hype cycle. O estudo nos lembra pra focar nos resultados e enfatiza as práticas técnicas.

Eu também gostei do design gráfico do estudo, ao qual mostra uma interessante diversidade de gênero, cor e etnias. Parece intencional e é incrível! O infográfico vale o download também.

E, finalmente, eu discuti sobre esse estudo com o Fernando Ike no podcast Na Estrada DevOps (episódio 007), confira!

Referências

  1. Eu poderia criar o termo DDDevOps, mas para o bem geral, não o farei. ↩