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

Melhores Práticas para Desenvolvimento Remoto d...

Melhores Práticas para Desenvolvimento Remoto de Software

Versão revisada em 27/11/2020.

ASERG, DCC, UFMG

November 12, 2020
Tweet

More Decks by ASERG, DCC, UFMG

Other Decks in Research

Transcript

  1. 5

  2. 6

  3. 7

  4. 8

  5. Não vamos falar de TR na pandemia • Ansiedade •

    Incerteza • Medo • Crianças em casa • etc 10
  6. Não vamos tratar das vantagens de TR • Mais tempo

    com família • Menos tempo no trânsito • Menos interrupções • Horários mais flexíveis • etc 12
  7. Não vamos tratar das desvantagens de TR • Falta de

    contato social • Falta de motivação • Fadiga de reuniões virtuais • Dificuldade de desconectar do trabalho • etc 13 Trabalho remoto não é uma bala de prata
  8. Trabalho remoto - Pré-COVID • GitLab (~1,300 colaboradores, 65 países)

    • Automattic (~900 colaboradores, 68 países) • Basecamp (~50 colaboradores, 32 cidades) • Zapier (~250 colaboradores, 28 países) • DuckDuckGo (100-150 colaboradores) • Discourse (< 10 colaboradores) 17
  9. Não vamos tratar de práticas genéricas • Ter um bom

    espaço de trabalho em casa • Ter uma boa cadeira, computador, Internet, etc • Ter uma rotina; não trabalhar fora do expediente • Sempre ligar a câmara, mas mutar o microfone • Não fazer reuniões com mais de 4-5 participantes • etc 20
  10. Não vamos tratar de práticas de socialização • Happy hour

    virtual • Café no Zoom • Daily + socialização • etc 21
  11. Fizemos a seguinte pergunta para 415 devs brasileiros 23 Fonte:

    Surveying the Impacts of COVID-19 on the Perceived Productivity of Brazilian Software Developers. SBES 2020
  12. Hoje ... Product Owner senta junto dos desenvolvedores e "explica"

    requisitos para eles PO Devs Fonte: @engsoftmoderrna
  13. Hoje (Scrum) 31 PO Devs Stakeholders • Durante sprint, PO

    explica histórias (requisitos) para devs • Troca-se documentação formal e escrita por documentação verbal e informal • Histórias são convites para conversas entre PO e Devs Fonte: @engsoftmoderrna
  14. Será que temos que voltar para Waterfall? 34 Linguagem natural

    (poderia levar anos para ficar pronto) Stakeholders Analista de Requisitos Devs Fonte: @engsoftmoderrna
  15. Shape Up • Especificação simplificada de requisitos • Resultado: pitch

    (documento simplificado de requisitos) ◦ Problema ◦ Esboço da solução (sketches) ◦ Rabbit holes (soluções para possíveis impasses) ◦ No-gos (limitações que serão aceitas) 38
  16. Shape Up • Quem propõe e escreve o pitch? ◦

    Gerentes sêniores (produto) ◦ No caso da Basecamp: 4 pessoas • Processo de escrita: ◦ Assíncrono ◦ Reunião final, síncrona, para decidir os pitches do próximo ciclo 42
  17. Ciclos • Duração: 6 semanas ◦ Mais longos que sprints

    de Scrum ◦ Embora possam existir ciclos de duas semanas • Não existe prorrogação na duração de um ciclo 43
  18. Times • Tamanho: 2 devs + 1 designer ◦ Ainda

    menores que os times Scrum • Autonomia: ◦ Implementar pitches (pitch = projeto; e não tarefas) ◦ Definir horários de trabalho, reuniões, daily, etc 44
  19. Como os devs recebem o pitch e como os times

    são menores, necessidade de coordenação e comunicação síncrona é também menor
  20. Cool Down • Duração: 2 semanas • Tempo para os

    devs "respirarem" ◦ Corrigir bugs ◦ Refactorings ◦ Estudar um nova tecnologia ◦ etc 46
  21. Cool Down lembra slacks em XP 47 "You can structure

    slack in many ways. [For example], one week in eight could be Geek Week." -- K. Beck, Extreme Programming Explained
  22. Problema • A popularidade da linguagem Go está crescendo •

    Precisamos que o RefDiff funcione com Go! • RefDiff: ferramenta para detectar refactorings em commits ◦ Para depois ajudar na realização de code reviews, etc 49
  23. Solução • Parser dos arquivos modificados em commit • Usar

    parser XYZ • Criar CST; veja documentação neste [link] • Implementar call graph • Acrescentar informações de call graph na CST 50
  24. Rabbit Holes • Implementação de um call graph não é

    trivial • Usar a implementação mais simples possível ◦ Baseada em uma análise sintática bem simples ◦ Sem considerar escopo, polimorfismo, interfaces, etc ◦ Restrita aos arquivos modificados no commit 53
  25. Estimativa vs Apetites • Projetos tradicionais: fixa-se escopo e prazo

    (estimativa) • Shape Up: fixa-se apenas prazo e escopo pode variar ◦ Implementação pode ser mais simples ou complexa ◦ Prazo (ou apetite): sinalização de quanto a feature vale para o negócio da empresa 57
  26. Circuit Breaker • Se time não entrega no final do

    ciclo, projeto é cancelado • Ou seja, não existem extensões de prazos • Coloca uma pressão (positiva?) sobre o time 58
  27. Software Produto • Clientes não têm poder para escolher features

    • Features definidas por um gerente de produto • Mais fácil entender o que gerentes de produto querem • Mais fácil trabalhar assincronamente • Caso da Basecamp (Shape Up) 62
  28. Software Personalizado • Requisitos específicos (muitas vezes, complexos) • Apenas

    alguns clientes conhecem os requisitos • Domínio bem específico (exemplo: seguros de aviões) • Desenvolvedores sem experiência no domínio • Papel do PO é fundamental! • Mais desafiador trabalhar assincronamente 63
  29. Boas práticas para trabalho remoto [dentre outras] • Trabalho remoto

    ~ Trabalho [bastante] assíncrono • Algumas práticas: ◦ Documento simplificado de requisitos ◦ Micro-times ◦ Período de cool down 69