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

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

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. View Slide

5. View Slide

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