Melhores Práticas para Desenvolvimento Remoto de Software

Versão revisada em 27/11/2020.

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