
A maioria das empresas segue algum tipo de processo Scrum. Normalmente isso envolve sprints de 2 ou 3 semanas. No final de cada sprint as mudanças são demonstradas, retrospectivas são realizadas e o backlog é refinado. Durante cada sprint o tempo de conclusão das tarefas é capturado, o que permite à gestão projetar para o futuro quando os projetos serão concluídos.
Muitos dos projetos Scrum dos quais participei enfatizam “comprometer-se” com tarefas ou “assumir responsabilidade”. No final do sprint muitos engenheiros são responsabilizados por tarefas incompletas. Velocidade do sprint é outra ideia que é martelada. Temos que manter nossa velocidade! É como se criar software fosse uma corrida, mas não é. Se os engenheiros são responsabilizados por uma métrica, eles vão otimizar para a métrica, isso não é o que você quer.
Scrum cria uma estrutura fácil de entender para as equipes seguirem e dá à gestão as ferramentas para prever o futuro. Equipes que praticaram waterfall acham Scrum fácil de compreender.
Muitas das práticas do Scrum não são necessárias. Por exemplo, a maioria dos softwares de rastreamento de problemas permite que gerentes executem relatórios sobre a frequência de conclusão de tickets. Com essa informação, gerentes são capazes de inferir velocidade, em vez de incorporar velocidade no processo e torná-la uma grande questão. Assumir responsabilidade é uma farsa, fazemos isso naturalmente, torná-lo explícito é insultuoso. Todos os projetos dos quais participei cada engenheiro tem um canto da aplicação que é seu espaço.
Outras maneiras de melhorar a entrega de software:
- Se você precisa de deployments semanais, agende-os. Faça deploy do que está pronto.
- Mantenha o backlog refinado; assim os engenheiros nunca ficam sem trabalho.
- Na minha opinião, retrospectivas são a atividade não-desenvolvimento mais essencial. Sem ela, você não tem chance de se tornar uma organização melhor e mais eficiente.
- Automatize, automatize, automatize
- Comprometer-se com uma lista de funcionalidades é ridículo. Classifique as tarefas e complete o que puder. Preocupar-se com por que a “tarefa A” não foi concluída é perda de tempo. É claro que a tarefa era muito grande, ou trabalho de maior prioridade foi assumido.
- Demos são perda de tempo a menos que o cliente se importe e forneça feedback.
- Reuniões diárias podem ou não ser necessárias. Prefiro me reunir a cada dois dias.
No final das contas, trata-se de fornecer valor ao cliente da maneira mais eficiente.
Autor: Chuck Conway é especialista em engenharia de software e IA Generativa. Conecte-se com ele nas redes sociais: X (@chuckconway) ou visite-o no YouTube.