Developer Experience

Desbloqueando entregas ágeis

Olá pessoal

De onde vem a necessidade de entender

experiência de desenvolvimento?

  • Uma introdução ao conceito
  • Um case de sucesso
  • Outros exemplos surgindo no mercado
  • Um exercício

De onde vem a necessidade de entender a
experiência de desenvolvimento?

Primeiro precisamos de falar sobre

Agilidade e Entrega Contínua

Agilidade e Lean

Construção colaborativa, evitando desperdício

Processos para responder rápido a necessidades de negócio

Estamos construindo o que o negócio precisa?

Estamos medindo o impacto das decisões?

Podemos responder rápido a mudanças?

Entrega Contínua

Reduzindo riscos por entregar frequentemente

Ter um processo de entrega confiável e bem definido, onde o produto passa por build, test, deploy

Entrega Continua - Jez Humble & David Farley

Lead Time

Quanto tempo para fazer uma mudança e tê-la refletida em produção

Entrega Contínua é pré-requisito para boas entregas

Ter um processo confiável para garantir a qualidade ajuda a reduzir riscos

Se as mudanças são pequenas, você consegue identificar melhor o resultado

Lead Time pequeno correlaciona a um Mean Time to Recover pequeno

Se uma mudança demora 5 minutos para chegar a produção…

Voltar ao estado anterior demora apenas 5 minutos também

Passando pelo mesmo processo confiável que você construiu no dia a dia

Como crescer e manter uma Entrega Contínua?

10 pessoas desenvolvendo

Manter o contexto do negócio dentro da equipe é simples

As ferramentas e processos são simples

10 equipes de 10 pessoas desenvolvendo

A complexidade de negócio que esse grupo suporta cresce

As mudanças possuem riscos e impacto maiores

As ferramentas e processos precisam se adaptar ao crescimento da complexidade

10 pessoas x 100 pessoas

  • Qual o risco de uma mudança no código?
  • Qual o risco de uma mudança no banco de dados?
  • Qual o risco de uma mudança na plataforma?

Falamos sobre a jornada do usuário para entender como é interagir com nosso sistema

E se…

E se pensarmos nas pessoas que desenvolvem os nossos sistemas como Usuários dos nossos processos de entrega?

Qual a Experiência de Desenvolvimento?

Qual a experiência de uso que nossas ferramentas e processo de entrega tem?

Qual o custo e esforço ao fazer:

  • Uma mudança na lógica do código?
  • Uma mudança no banco de dados?
  • Uma mudança na infraestrutura?

Quais são os comportamentos que o nosso processo de entrega incentivam nas nossas equipes?

Quanto maior o esforço, menos o uso

O processo de entrega sob análise

Developer Experience busca incentivar a Entrega Contínua

Developer Experience é otimizar Entrega Contínua

É preciso reduzir os custos dos processos para incentivar Entrega Contínua

Quais os comportamentos que gostaríamos de incentivar nas equipes?

Case

Incentivando pequenas mudanças em bancos de dados entre 25 equipes

Cenário inicial

Uma mudança de banco de dados precisa:

  • Ser revisado pelo DBA
  • Não podemos permitir comandos que percam dados (Drop, deletes)
  • Não podemos permitir comandos que geram locks nas tabelas
  • Mudanças estruturais precisam de cuidado redobrado

Comportamentos adotados

  • Mudanças demoraram 5 dias para serem revisadas pelo DBA
  • Conflitos nas prioridades atrasavam as revisões
  • Equipes evitavam fazer mudanças no banco de dados
  • Falta de confiança por não saberem o que é aceitável
  • Falta de previsibilidade quando a mudança seria aplicada em produção
  • Mudanças aconteciam no final da sprint, gerando dependência no código que seria entregue

Mudanças em banco eram evitadas e deixados para o último dia da sprint

Esse não é o comportamento que gostaríamos de incentivar

Juntamos uma equipe para:

  • Automatizamos a maioria das checagens nas mudanças
  • Melhoramos a mensagem de feedback quando encontramos erros
  • Reduzimos o ciclo de feedback permitindo executar as verificações antes mesmo de criar um ticket
  • Nos casos que ainda não haviam verificações automáticas, enviávamos para o DBA nos ajudar

Mudanças foram de 5 dias de revisão para 1 hora

Lead Time foi de de 40 horas para 1 hora

O processo se tornou mais trivial

Mudanças passaram a acontecer no mais cedo durante a sprint

Mais mudanças aconteciam, por ter um baixo custo

E as mudanças eram menores

Mudanças menores carregam menos riscos

e buscamos reduzir riscos

Developer Experience em outras empresas

Nubank: Engineering Productivity

(EngProd)

Microserviços em desenvolvimento o tempo todo por diferentes equipes

Mudanças de todos se enfileiram para chegar em produção

Um squad dedicado a otimizar e reduzir a fricção do processo de entrega

  • Buscam novas técnicas de teste para acelerar os passos de integração
  • Criam novas ferramentas para ajudar o desenvolvimento
  • Tornam processos que todas as equipes passam em algo trivial, sempre que possível

Estamos experimentando com squads de EngProd em escalas menores, dentro das equipes

Em outros lugares, com outros nomes

Se você ainda não pratica Entrega Contínua

Uma boa experiência de desenvolvimento incentiva mudanças menores e mais frequentes, com riscos menores para o seu negócio

Um exercício para sua equipe

Para conhecer a ergonomia do seu processo de desenvolvimento

Quanto tempo demora para uma pessoa chegar no projeto e mudar algo em produção?

O ideal:

No mesmo dia

  • Escolha uma mudança de baixo risco
    • Uma mudança em um texto é um ótima primeira tarefa
  • Acompanhe a configuração do ferramental
  • Mostre o caminho para produção
  • Vejam a mudança em produção

Para quem está chegando na equipe

É o melhor momento para ser apresentado a um processo que você usará todo os dias

As próximas mudanças aconteceram em um

ambiente já configurado

No fim do dia você sente que já contribuiu no projeto

Para quem está acompanhando o onboarding

Você descobre onde de uso no processo de entrega

Você observa o que é preciso otimizar para

reduzir o Lead Time

E já começa com um bom onboarding

Obrigado

Bruno Tavares - @bltavares