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

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.

13beaa3b7239eca3319d54c6a9f3a85a?s=128

ASERG, DCC, UFMG

February 03, 2021
Tweet

Transcript

  1. MPS Talks Melhores Práticas para Desenvolvimento Remoto de Software Marco

    Tulio Valente ASERG, DCC, UFMG
  2. Legado da pandemia será um aumento expressivo de Trabalho Remoto

    (TR) 2
  3. Algumas evidências 3

  4. 4

  5. 5

  6. 6

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

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

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

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

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

  13. Como fazemos software hoje em dia? 13

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

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

  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
  18. Não parece ser difícil, pois maior evento dura 4 horas,

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

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

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

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

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

    WhatsApp, mail, etc. 24
  25. Será que temos que voltar para Waterfall? 25 Linguagem natural

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

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

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

    down 28
  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
  30. Exemplos de Pitches 30

  31. Exemplo de Pitch

  32. None
  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
  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
  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
  36. Pitches + times pequenos ⇨ menos coordenação, menos comunicação síncrona

  37. Cool Down • Duração: 2 semanas • Tempo para os

    devs "respirarem" ◦ Corrigir bugs ◦ Refactorings ◦ Estudar nova tecnologia, etc • Lembram "slacks" em XP 37
  38. Exemplo mais real (e pessoal) de shaping 38

  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
  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
  41. Solução (arquitetura) 41 Rodrigo Brito, Marco Tulio Valente. RefDiff4Go: Detecting

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

    Refactorings in Go. SBCARS 2020
  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
  44. shaping ⇨ pitch pitch = problema + solução + rabbit

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

  46. Concluindo 46

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