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

Melhores Práticas para Desenvolvimento Remoto de Software

Melhores Práticas para Desenvolvimento Remoto de Software

Versão revisada em 27/11/2020.

13beaa3b7239eca3319d54c6a9f3a85a?s=128

ASERG, DCC, UFMG

November 12, 2020
Tweet

Transcript

  1. Melhores Práticas para Desenvolvimento Remoto de Software Marco Tulio Valente

    ASERG, DCC, UFMG
  2. Hipótese 1: Pandemia vai acabar! 2

  3. Hipótese 2: Legado da pandemia será um aumento expressivo de

    Trabalho Remoto (TR) 3
  4. Algumas evidências 4

  5. 5

  6. 6

  7. 7

  8. 8

  9. O que não está no contexto da palestra 9

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

    Incerteza • Medo • Crianças em casa • etc 10
  11. TR ≠ TR na pandemia 11

  12. 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
  13. 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
  14. Para ficar claro, vai existir um trade-off 14

  15. Assumindo que trabalho remoto será mais comum, quais as melhores

    práticas que devemos seguir? 15
  16. Trabalho remoto não é novidade! 16

  17. 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
  18. 18 TI é uma das indústrias mais "adequadas" para trabalho

    remoto
  19. Foco: Práticas de desenvolvimento de software 19

  20. 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
  21. Não vamos tratar de práticas de socialização • Happy hour

    virtual • Café no Zoom • Daily + socialização • etc 21
  22. Como fazemos software hoje em dia? 22

  23. 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
  24. Scrum em 1 slide 24 fonte: https://www.scrum.org/resources/scrum-framework-reduce-risk-and-deliver-value-sooner

  25. Scrum em 1 slide 25 fonte: https://www.scrum.org/resources/scrum-framework-reduce-risk-and-deliver-value-sooner

  26. Scrum em 1 slide 26 fonte: https://www.scrum.org/resources/scrum-framework-reduce-risk-and-deliver-value-sooner 4 hr 3

    hr 4 hr 15 min
  27. Não parece ser difícil, pois maior evento dura 4 horas,

    para sprints de 15 dias 27
  28. Porém, não é tão simples assim…. 28

  29. Problema: natureza síncrona das comunicações durante um sprint 29

  30. Hoje ... Product Owner senta junto dos desenvolvedores e "explica"

    requisitos para eles PO Devs Fonte: @engsoftmoderrna
  31. 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
  32. Mandamento #1 de Trabalho Remoto: minimize comunicação síncrona 32

  33. Não dá para ficar o dia inteiro no Zoom, Slack,

    WhatsApp, mail, etc. 33
  34. Será que temos que voltar para Waterfall? 34 Linguagem natural

    (poderia levar anos para ficar pronto) Stakeholders Analista de Requisitos Devs Fonte: @engsoftmoderrna
  35. Provavelmente não! Basta dar um pequeno passo para trás 35

  36. Processo de desenvolvimento da BaseCamp 36 https://basecamp.com/shapeup

  37. Três Fases • Shape Up • Ciclos (~ sprints) •

    Cool down 37
  38. 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
  39. Exemplos de Pitches 39

  40. Exemplo de Pitch

  41. None
  42. 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
  43. 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
  44. 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
  45. 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
  46. Cool Down • Duração: 2 semanas • Tempo para os

    devs "respirarem" ◦ Corrigir bugs ◦ Refactorings ◦ Estudar um nova tecnologia ◦ etc 46
  47. 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
  48. Exemplo mais real de pitch 48

  49. 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
  50. 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
  51. Solução (cont.) 51

  52. Solução (cont.) 52

  53. 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
  54. Limitações • Interface bem simples, apenas linha de comando 54

  55. Portanto, pitch é diferente de colar alguns post-its na parede

    55
  56. Mais alguns conceitos de Shape Up 56

  57. 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
  58. 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
  59. Hill Charts (para acompanhamento de projetos) 59

  60. Análise um pouco mais crítica 60

  61. Dois tipos de software • Produto: múltiplos clientes • Personalizado:

    para um único cliente 61
  62. 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
  63. 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
  64. Breve comentário sobre modelo híbrido 64

  65. Modelo Híbrido • Alguns devs presenciais • Alguns devs remotos

    (exemplo: em outra cidade) 65
  66. Problema: pode causar uma "divisão" na empresa remotos = colaboradores

    de 2a classe 66
  67. 67 Fonte: Five Nonobvious Remote Work Techniques, CACM 2020

  68. Concluindo 68

  69. 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
  70. Obrigado! Marco Tulio Valente ASERG, DCC, UFMG 70