Como otimizamos a entrega de código e isso melhorou a agilidade do nosso time

Neste bate-papo vamos abordar como o meu time otimizou os PRs e quebra das tarefas e isso melhorou nossa agilidade. Vou mostrar alguns erros e acertos durante este processo de melhoria e os resultados até o momento.

Transcript

1. Como otimizamos a entrega de código ...e isso melhorou a agilidade do nosso time Luís Fernando Murara
2. Olá! LUIS FERNANDO MURARA Engenheiro de Software Resultados Digitais Pós-graduado em Arquitetura de Software Em busca da alta performance
3. JARVIS s.m. squad de produto e engenharia da Resultados Digitais responsável pela automação de marketing do RDSM
4. Em 2018...
5. Kanban
6. Ainda em 2018... Desenho de Solução ToDo Doing Shipping Review/QA WIP Throughput: 2 a 7 cards por semana Cycle Time: > 14 dias em alguns casos Quebra de tarefas
7. Por que estamos levando tanto tempo para entregar os cards?
8. O escopo dos cards está muito grande
9. Os Pull Requests estão muito grandes PRs Grandes >800 linhas
10. Verificamos que... - PRs estavam envelhecendo - Cards demorados desmotivam o desenvolvedor - Durante o Review: - Complexidade cognitiva: muito código para revisar - Demora no review - Muitos ciclos de review - Muitos comentários e debate
11. Qual o escopo ideal para um card?
12. O que é um PR pequeno?
13. Quantas linhas ele deve ter?
14. Como lidar com dependências entre cards?
15. Após fazer debates internos e benchmark com outros times...
16. Um card deve fazer apenas uma coisa
17. E o PR pode ter apenas UMA linha de código
18. A entrega de valor pode estar em apenas UMA ÚNICA linha de código
19. e a dependência entre os cards é algo aceitável
20. Quebrando melhor as tarefas Desenho de Solução ToDo Doing Shipping Review/QA Quebra de tarefas Throughput: 4 a 7 cards por semana Cycle Time: > 12 dias em alguns casos PRs menores que 800 linhas Cards que fazem apenas uma “coisa”
22. Notamos que... - Estávamos refatorando códigos além do escopo - Estávamos refatorando testes além do escopo - Não estávamos detalhamento os cards - Tínhamos descobertas durante a execução da tarefa (e isso é OK)
23. “Só mais um detalhe e tá pronto!”
25. Determinamos que… - A descrição de um card ou PR nunca deve ter um “E” - Refatoração deve ser feita em PRs anteriores - Devemos ser mais críticos ao analisar a quebra de tarefas - Descobertas devem ser analisadas e enviadas em PRs separados
26. Cycle time Primeira onda Férias coletivas Segunda onda Novo patamar Fonte: Corrello
27. Tempo até o merge Fonte: Velocity
28. Ciclo de review Primeira onda Segunda onda Migrações para Redux Novo patamar Fonte: Velocity
29. Velocidade do review Fonte: Velocity
30. Analisando o todo Primeira onda Segunda onda Migrações para Redux Novo patamar - Review Cycles - Review Speed - Time to Merge - PR Sizes Fonte: Velocity
31. Conclusão - Menos código significa mais tempo para escrever com qualidade - Board Kanban mais fluído - Reviews mais rápidos e simples - Entregas mais ágeis - Rollback de código menor em caso de incidente - Mais motivação dos desenvolvedores Throughput: estável em 6 cards Cycle Time: < 8 dias
32. Obrigado LUIS FERNANDO MURARA murara@gmail.com Linkedin: https://linkedin.com/in/murara Github: https://github.com/murara Facebook: https://fb.com/SirMurara We're hiring!