Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Acelerando o Desenvolvimento de Software - Pyth...

Acelerando o Desenvolvimento de Software - Python Sul 2024

Nessa palestra você irá conhecer as mais recentes discussões sobre produtividade e performance na indústria do desenvolvimento de software, junto com um conjunto de boas práticas a nível individual e de equipe inspiradas nessas discussões.

Jessica Pauli de C Bonson

September 14, 2024
Tweet

More Decks by Jessica Pauli de C Bonson

Other Decks in Technology

Transcript

  1. OLÁ! Eu sou Jéssica Bonson (@jpbonson) Staff Engineer @ MercadoLivre

    ⬢ Graduação/Mestrado em Ciências da Computação ⬢ 12+ anos de experiência em techstacks e projetos diversos
  2. Como medir performance de desenvolvimento de software? • Problemas: ◦

    É um processo subjetivo ◦ É um inventário invisível ◦ Design e entrega podem acontecer ao mesmo tempo • Tentativas: ◦ Linhas de código? Story points? Ocupação do time? ▪ Cuidado para não incentivar comportamentos indesejados!
  3. “O Grande Massacre dos ratos de 1902”, em Hanoi, Vietnã

    Agora com pessoas… (https://www.iflscience.com/the-great-rat-massacre-of-1902-and-how-it-backfired-spectacularly-has-eerie-parallels-with-covid19-58464)
  4. É baseado no maior e mais longo estudo de DevOps

    já conduzido (https://dora.dev/). • Objetivo: encontrar como medir a performance de entrega de software, e o que a impacta. • Utiliza uma grande quantidade de dados e análise estatística rigorosa. • Foco em predição e correlação dos dados. Em 2018 foi lançado esse livro: Reúne um conjunto de práticas que comprovadamente aumentam quantidade, qualidade e estabilidade das entregas de desenvolvimento de software de uma empresa.
  5. 1 Como medir performance de desenvolvimento de software de uma

    organização? De acordo com esse estudo…
  6. Métricas-chave ⬢ Delivery Lead Time: Tempo entre o código estar

    commitado e código executando com sucesso em produção. ⬢ Deployment Frequency: Frequência dos deploys em produção. ⬢ Mean Time To Restore (MTTR): O quão rápido se conserta falhas em produção. ⬢ Change Fail Percentage: % de mudanças em produção que falham (ie. rollbacks, fixes, outages…) Motivos: • Métricas globais • Medem velocidade e estabilidade • Valorizam resultados concretos, não ‘busywork’ • O estudo mostrou que empresas que tem bons valores nessas métricas também se saem bem em: • Performance financeira ◦ ex.: turnover e lucro • Performance não-financeira ◦ ex.: qualidade e satisfação do cliente
  7. Principais conclusões do estudo ⬢ Entrega de software de fato

    impacta a performance de uma empresa. ⬢ Não é necessário escolher entre estabilidade e velocidade: Na realidade, velocidade depende de estabilidade. ⬢ Quando bem implementadas, muitas das práticas dos movimentos Agile, Lean e DevOps tem um impacto positivo na performance de entrega de software.
  8. E o que é DevOps? Um movimento que surgiu a

    partir de empresas buscando maneiras de construir software que é seguro, resiliente e escalável. Era uma parceria entre as equipes de Dev e Ops de uma empresa. Valoriza: • Integração continua • Entrega continua • Métodos ágeis • Cultura colaborativa Não é apenas práticas e ferramentas, mas também uma cultura!
  9. O que é necessário para uma cultura de DevOps ser

    efetiva? ⬢ Cultura Generativa ⬢ Liderança de Alta performance ⬢ Práticas de Alta performance
  10. Cultura Generativa ⬢ A boa aplicação das métricas-chave depende da

    cultura da empresa. ⬢ Se os dados são utilizados como uma forma de controle, as pessoas passam a escondê-los. ⬢ Para melhorar a performance, é necessário melhorar a cultura. Modelo de Westrum para culturas organizacionais: • Patológico: baseado em poder • Burocrático: baseado em regras • Generativa: baseado em performance “Whenever there is fear, you get the wrong numbers”
  11. Cultura Generativa A cultura generativa cria um ambiente com um

    forte fluxo de informações, mas requer: ⬡ Confiança ⬡ Transparência ⬡ Responsabilidade compartilhada ⬡ Segurança para errar e aprender ⬡ Encorajar novas ideias ⬡ Alta colaboração entre as equipes “Accident investigations that stop at ‘human error’ are not just bad but dangerous. Human error should, instead, be the start of the investigation.”
  12. Como mudar a cultura? ⬢ A maneira como as pessoas

    trabalham influencia a cultura. ⬢ Ou seja, melhores práticas de trabalho podem melhorar a cultura! “The way to change culture is… to start by changing how people behave — what they do”
  13. Liderança de Alta Performance ⬢ Objetivo: Facilitar a criação e

    melhoria de uma cultura de alta performance. ⬢ Como? ⬡ Prover as ferramentas, coaching, objetivos e métricas para permitir que os times tenham autonomia. ⬡ Apoiar um ambiente que permita mudanças incrementais de forma colaborativa. “Going fast is of no value if you don’t go in the right direction.”
  14. Liderança de Alta Performance ⬢ Encoraja a todos (inclusive a

    si mesmo!) a desafiar suposições e tentar novos comportamentos, sempre aprendendo no processo. ⬡ Os comportamentos que funcionam e recebem reforço se tornam hábitos, e hábitos mudam a cultura. ⬢ Times podem avançar de forma independente quando: ⬡ Sabem porque eles estão fazendo o que estão fazendo. ⬡ Sabem como o sucesso vai ser medido.
  15. São 24 práticas divididas nas categorias: 1. Tecnologia 2. Arquitetura

    3. Produto & Processos 4. Gestão & Monitoramento 5. Cultura Práticas de Alta Performance
  16. Práticas: Tecnologia Objetivo: Criar um ambiente que permita entrega contínua

    de software que é valioso para os clientes, em iterações pequenas e rápidas, de forma segura e sustentável.
  17. Práticas: Tecnologia ⬢ Controle de versão ⬡ Tanto para aplicação

    como para a infraestrutura ⬢ Deploy automático ⬢ Integração Contínua (CI) ⬢ Trunk-based development ⬡ Ao invés de feature branches de longa duração ⬢ Testes automáticos ⬡ Testes confiáveis e frequentes ⬢ Gestão de dados de teste ⬢ Shift left on security ⬢ Continuous Delivery (CD) Princípios: 1. Construir já com qualidade 2. Trabalhar em batches pequenos 3. Automatizar trabalho repetitivo 4. Melhoria constante 5. Responsabilidade compartilhada
  18. Práticas: Arquitetura ⬢ Arquitetura de baixo acoplamento ⬡ Remover dependência

    tanto a nível de sistemas como de times ⬡ Não foque em ferramentas e tecnologias, mas em deployability e testability ⬡ Modularidade permite escalabilidade Deployability • Capacidade de deployar uma aplicação de forma independente, em múltiplos ambientes. • De preferência, a nível de componente, e sendo capaz de detectar e tolerar falhas. Testability • Capacidade de testar uma aplicação de forma independente, sem requerer um ambiente integrado. “High performance is possible with all kinds of systems, provided that systems — and the teams that build and maintain them — are loosely coupled”
  19. Práticas: Arquitetura “Following standard processes saves time and energy —

    but will prevent generative culture if the business doesn’t regularly re-evaluate it and improve it by empowering interested and skilled individuals to come together and be empowered to make the change from all levels.” ⬢ Times empoderados ⬡ Time autônomos com autoridade para tomar decisões. ⬡ Balanço entre padronização e times escolherem as ferramentas.
  20. Práticas: Produto & Processos Objetivo: Iterar sobre o ciclo de

    vida do produto de forma rápida e com visibilidade.
  21. Práticas: Produto & Processos ⬢ Customer feedback ⬡ Buscar feedback

    dos clientes de forma ativa e incorporá-lo no design dos produtos. ⬢ Value stream ⬡ Entender e ter visibilidade do fluxo ponta-a-ponta entre o negócio e o cliente. ⬢ Trabalhar em batches pequenos ⬡ Tanto a nível de código, como de entregas, e de produto (ex.: MVPs) ⬢ Team experimentation ⬡ Times terem liberdade para experimentar novas ideias ⬡ Ter autoridade para fazer mudanças sem aprovação externa O objetivo da experimentação é poder fazer decisões informadas em dados, através de feedback dos clientes e performance do software, e assim permitir um processo rápido de testes e validação.
  22. Trabalhar em batches pequenos A nível de produto, histórias/features, e

    código. É importante decompor uma entrega em features, e decompor a feature em PRs pequenos. Vantagens: ⬢ Reduz o cycle time e a variabilidade ⬢ Permite obter resultados em produção e iterar sobre isso ⬢ Reduz risco e overhead ⬢ Reuso de código ⬢ Evita retrabalho com conflito de código ⬢ Permite revisões de código mais rápidas Recomendação de leitura: https://newsletter.pragmaticengi neer.com/p/stacked-diffs
  23. Práticas: Gestão & Monitoramento ⬢ Processos de aprovação leves ⬡

    ex.: revisões por pares ou da própria equipe ⬢ Monitoramento do sistema ⬢ Notificações pró-ativas ⬢ Limites de WIP ⬡ Não deve ser um limite fixo, mas um processo de melhoria ⬢ Visualizar o trabalho ⬡ Tarefas, métricas… ⬡ Deve ser de fácil acesso
  24. Práticas: Cultura ⬢ Cultura Generativa ⬢ Encorajar aprendizado ⬡ Ideias:

    ser seguro falhar, ter um budget, espaços para compartilhar conhecimento ⬢ Forte colaboração entre times ⬡ Uma relação de confiança: manter palavra, previsibilidade, comunicação aberta ⬡ Encorajar e incentivar trabalhos que facilitem a cooperação ⬢ Satisfação com o trabalho ⬡ Trabalho desafiador e com significado ⬡ Ter autonomia para exercer suas habilidades e conhecimento ⬡ Ter as ferramentas e recursos necessários ⬢ Liderança transformadora Caracteristicas: • Visão • Comunicação inspiradora • Estimula intelectualmente • Se importa • Reconhecimento pessoal • Dá o exemplo “High-performance culture… is the development, through experimentation and learning guided by evidence, of a new way of working together that is situationally and culturally appropriate to each organization.”
  25. Burnout Fatores que reduzem burnout: ⬢ Remover a ‘dor de

    deployment’. ⬢ Líderes focados em remover impedimentos, não em comando-e-controle. ⬢ Investimento em DevOps. ⬢ Práticas de Gestão Lean e Entrega Contínua. “The technical practices that improve our ability to deliver software with both speed and stability also reduce the stress and anxiety associated with pushing code to production”
  26. É possível aumentar a performance de uma empresa com: •

    Cultura generativa orientada a resultados • Arquitetura modular • Práticas de engenharia que facilitam a entrega contínua • Liderança efetiva Conclusão
  27. Mais pontos de vista https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity https://newsletter.pragmaticengineer.com/p/low-quality-eng-culture https://martinfowler.com/articles/architect-elevator.html (“ArchOps”) “Unplanned work

    and rework are useful proxies for quality, because they represent a failure to build quality into our products” “Building slack into the system is critical to allow for responsiveness — “As utilization approaches 100%, lead times approach infinity”