Skip to content

Posts

Scrum é Superestimado

16 de março de 2021 • 2 min de leitura

Scrum é Superestimado

A maioria das empresas segue algum tipo de processo Scrum. Normalmente isso envolve sprints de 2 ou 3 semanas. Ao final de cada sprint, as mudanças são demonstradas, retrospectivas são realizadas e o backlog é organizado. Durante cada sprint, o tempo de conclusão das tarefas é capturado, o que permite que a gerência projete quando os projetos serão concluídos.

Muitos dos projetos Scrum dos quais participei enfatizam “se comprometer” com tarefas ou “assumir responsabilidade”. Ao final do sprint, muitos engenheiros são responsabilizados por tarefas incompletas. A velocidade do sprint é outra ideia que é martelada. Temos que manter nossa velocidade! É como se criar software fosse uma corrida, não é. Se os engenheiros são responsabilizados por uma métrica, eles otimizarão para a métrica, isso não é o que você quer.

Scrum cria um framework fácil de entender para as equipes seguirem e fornece à gerência 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 do software de rastreamento de problemas permite que gerentes executem relatórios sobre a frequência de conclusão de tickets. Com essas informações, os gerentes conseguem inferir velocidade, em vez de incorporar velocidade ao processo e torná-la um grande problema. Assumir responsabilidade é uma farsa, fazemos isso naturalmente, torná-lo explícito é insultuoso. Em 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ê precisar de implantações semanais, agende-as. Implante o que está pronto.
  • Mantenha o backlog organizado; assim os engenheiros nunca ficarão 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
  • Se comprometer com uma lista de recursos é ridículo. Classifique as tarefas e conclua o que puder. Se preocupar com o motivo de “tarefa A” não estar completa é uma perda de tempo. É claro que a tarefa era muito grande ou trabalho de maior prioridade foi assumido.
  • Demos são uma 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 reuniões a cada dois dias.

No final, trata-se de fornecer valor ao cliente da forma mais eficiente.

Autor: Chuck Conway é um Engenheiro de IA com quase 30 anos de experiência em engenharia de software. Ele constrói sistemas de IA práticos—pipelines de conteúdo, agentes de infraestrutura e ferramentas que resolvem problemas reais—e compartilha o que está aprendendo ao longo do caminho. Conecte-se com ele nas redes sociais: X (@chuckconway) ou visite-o no YouTube e no SubStack.

↑ Voltar ao topo

Você também pode gostar