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.

ASERG, DCC, UFMG

November 12, 2020
Tweet

More Decks by ASERG, DCC, UFMG

Other Decks in Research

Transcript

  1. Melhores Práticas para
    Desenvolvimento Remoto de Software
    Marco Tulio Valente
    ASERG, DCC, UFMG

    View Slide

  2. Hipótese 1: Pandemia vai acabar!
    2

    View Slide

  3. Hipótese 2:
    Legado da pandemia será um aumento
    expressivo de Trabalho Remoto (TR)
    3

    View Slide

  4. Algumas evidências
    4

    View Slide

  5. 5

    View Slide

  6. 6

    View Slide

  7. 7

    View Slide

  8. 8

    View Slide

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

    View Slide

  10. Não vamos falar de TR na pandemia
    ● Ansiedade
    ● Incerteza
    ● Medo
    ● Crianças em casa
    ● etc
    10

    View Slide

  11. TR ≠ TR na pandemia
    11

    View Slide

  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

    View Slide

  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

    View Slide

  14. Para ficar claro, vai existir um trade-off
    14

    View Slide

  15. Assumindo que trabalho remoto será
    mais comum, quais as melhores
    práticas que devemos seguir?
    15

    View Slide

  16. Trabalho remoto não é novidade!
    16

    View Slide

  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

    View Slide

  18. 18
    TI é uma das
    indústrias mais
    "adequadas" para
    trabalho remoto

    View Slide

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

    View Slide

  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

    View Slide

  21. Não vamos tratar de práticas de socialização
    ● Happy hour virtual
    ● Café no Zoom
    ● Daily + socialização
    ● etc
    21

    View Slide

  22. Como fazemos software hoje em dia?
    22

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  27. Não parece ser difícil, pois maior evento
    dura 4 horas, para sprints de 15 dias
    27

    View Slide

  28. Porém, não é tão simples assim….
    28

    View Slide

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

    View Slide

  30. Hoje ...
    Product Owner senta junto dos desenvolvedores e
    "explica" requisitos para eles
    PO
    Devs
    Fonte: @engsoftmoderrna

    View Slide

  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

    View Slide

  32. Mandamento #1 de Trabalho Remoto:
    minimize comunicação síncrona
    32

    View Slide

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

    View Slide

  34. Será que temos que voltar para Waterfall?
    34
    Linguagem natural
    (poderia levar anos para ficar pronto)
    Stakeholders
    Analista de
    Requisitos
    Devs
    Fonte: @engsoftmoderrna

    View Slide

  35. Provavelmente não!
    Basta dar um pequeno passo para trás
    35

    View Slide

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

    View Slide

  37. Três Fases
    ● Shape Up
    ● Ciclos (~ sprints)
    ● Cool down
    37

    View Slide

  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

    View Slide

  39. Exemplos de Pitches
    39

    View Slide

  40. Exemplo de Pitch

    View Slide

  41. View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  46. Cool Down
    ● Duração: 2 semanas
    ● Tempo para os devs "respirarem"
    ○ Corrigir bugs
    ○ Refactorings
    ○ Estudar um nova tecnologia
    ○ etc
    46

    View Slide

  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

    View Slide

  48. Exemplo mais real de pitch
    48

    View Slide

  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

    View Slide

  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

    View Slide

  51. Solução (cont.)
    51

    View Slide

  52. Solução (cont.)
    52

    View Slide

  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

    View Slide

  54. Limitações
    ● Interface bem simples, apenas linha de comando
    54

    View Slide

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

    View Slide

  56. Mais alguns conceitos de Shape Up
    56

    View Slide

  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

    View Slide

  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

    View Slide

  59. Hill Charts (para acompanhamento de projetos)
    59

    View Slide

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

    View Slide

  61. Dois tipos de software
    ● Produto: múltiplos clientes
    ● Personalizado: para um único cliente
    61

    View Slide

  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

    View Slide

  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

    View Slide

  64. Breve comentário sobre modelo
    híbrido
    64

    View Slide

  65. Modelo Híbrido
    ● Alguns devs presenciais
    ● Alguns devs remotos (exemplo: em outra cidade)
    65

    View Slide

  66. Problema: pode causar uma "divisão"
    na empresa
    remotos = colaboradores de 2a classe
    66

    View Slide

  67. 67
    Fonte: Five Nonobvious Remote Work Techniques, CACM 2020

    View Slide

  68. Concluindo
    68

    View Slide

  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

    View Slide

  70. Obrigado!
    Marco Tulio Valente
    ASERG, DCC, UFMG
    70

    View Slide