$30 off During Our Annual Pro Sale. View Details »

Melhores Práticas para Desenvolvimento Remoto de Software (MPS Talks - Softex)

Melhores Práticas para Desenvolvimento Remoto de Software (MPS Talks - Softex)

Palestra para a série MPS Talks, organizada pela Softex.

ASERG, DCC, UFMG

February 03, 2021
Tweet

More Decks by ASERG, DCC, UFMG

Other Decks in Technology

Transcript

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

    View Slide

  2. Legado da pandemia será um aumento
    expressivo de Trabalho Remoto (TR)
    2

    View Slide

  3. Algumas evidências
    3

    View Slide

  4. 4

    View Slide

  5. 5

    View Slide

  6. 6

    View Slide

  7. 7
    https://exame.com/carreira/hotmart-abre-400-vagas-de-emprego-com-home-office-para-sempre/

    View Slide

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

    View Slide

  9. Trabalho remoto não é novidade!
    9

    View Slide

  10. 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)
    10

    View Slide

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

    View Slide

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

    View Slide

  13. Como fazemos software hoje em dia?
    13

    View Slide

  14. Perguntamos para 415 devs brasileiros
    14
    Fonte: Surveying the Impacts of COVID-19 on the Perceived Productivity of Brazilian Software Developers.
    SBES 2020
    Ágil = 87%

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. Hoje (Scrum)
    22
    PO Devs
    Stakeholders
    ● Durante sprint, PO explica histórias (requisitos) para devs
    ● Troca-se documentação formal e escrita por comunicação
    verbal e informal
    ● Histórias são convites para conversas entre PO e Devs
    Fonte: @engsoftmoderrna

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  28. Três Fases
    ● Shaping
    ● Ciclos (~ sprints)
    ● Cool down
    28

    View Slide

  29. Shaping
    ● Especificação leve de requisitos e projeto (design)
    ● Resultado: pitch
    ○ Problema
    ○ Esboço da solução (sketches)
    ○ Rabbit holes (soluções para possíveis impasses)
    29

    View Slide

  30. Exemplos de Pitches
    30

    View Slide

  31. Exemplo de Pitch

    View Slide

  32. View Slide

  33. Shaping (cont.)
    ● Quem são os "shapers"?
    ○ 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
    33

    View Slide

  34. 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
    34

    View Slide

  35. 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
    35

    View Slide

  36. Pitches + times pequenos ⇨
    menos coordenação, menos comunicação síncrona

    View Slide

  37. Cool Down
    ● Duração: 2 semanas
    ● Tempo para os devs "respirarem"
    ○ Corrigir bugs
    ○ Refactorings
    ○ Estudar nova tecnologia, etc
    ● Lembram "slacks" em XP
    37

    View Slide

  38. Exemplo mais real (e pessoal) de
    shaping
    38

    View Slide

  39. Problema (Requisitos)
    ● A popularidade da linguagem Go está crescendo
    ● Precisamos que o RefDiff funcione com Go!
    ● RefDiff: ferramenta para detectar refactorings em commits
    ● Queremos detectar refactorings X, Y, Z, etc
    39

    View Slide

  40. Solução (design simplificado)
    ● Parser dos arquivos modificados em commit
    ● Usar parser XYZ
    ● Criar Code Structure Tree (CST); veja documentação
    ● Implementar call graph
    ● Acrescentar informações de call graph na CST
    40

    View Slide

  41. Solução (arquitetura)
    41
    Rodrigo Brito, Marco Tulio Valente. RefDiff4Go: Detecting Refactorings in Go. SBCARS 2020

    View Slide

  42. Solução (exemplos)
    42
    Rodrigo Brito, Marco Tulio Valente. RefDiff4Go: Detecting Refactorings in Go. SBCARS 2020

    View Slide

  43. Rabbit Holes
    ● Implementação de um call graph não é trivial
    ● Usar uma implementação simples:
    ○ Análise sintática bem simples
    ○ Sem considerar polimorfismo, interfaces, etc
    ○ Restrita aos arquivos modificados no commit
    43

    View Slide

  44. shaping ⇨ pitch
    pitch = problema + solução + rabbit holes
    44
    simplificado

    View Slide

  45. http://stevenoxley.com/blog/2020/10/19/book-review-shape-up/
    Mas existem críticos também….

    View Slide

  46. Concluindo
    46

    View Slide

  47. Boas práticas para trabalho remoto
    ● Trabalho remoto ~ Trabalho assíncrono
    ● Algumas boas práticas:
    ○ Documento simplificado de requisitos e projeto
    ○ Micro-times
    ○ Sprints longos (~6 semanas)
    ○ Período de cool down
    47

    View Slide

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

    View Slide