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

Melhores Práticas para Desenvolvimento Remoto d...

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

  2. 5

  3. 6

  4. 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
  5. 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%
  6. Hoje ... Product Owner senta junto dos desenvolvedores e "explica"

    requisitos para eles PO Devs Fonte: @engsoftmoderrna
  7. 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
  8. Será que temos que voltar para Waterfall? 25 Linguagem natural

    (poderia levar anos para ficar pronto) Stakeholders Analista de Requisitos Devs Fonte: @engsoftmoderrna
  9. 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
  10. 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
  11. 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
  12. 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
  13. Cool Down • Duração: 2 semanas • Tempo para os

    devs "respirarem" ◦ Corrigir bugs ◦ Refactorings ◦ Estudar nova tecnologia, etc • Lembram "slacks" em XP 37
  14. 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
  15. 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
  16. 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
  17. 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