Para um projeto grande andar, você desce o trabalho em três níveis (direção, blocos e tarefa atômica) até cada tarefa caber em no máximo 4 horas de execução. Depois confirma o entendimento com quem pediu antes de abrir o editor e avisa o desvio no mesmo dia em que ele aparece, nunca na véspera do prazo.
Foi com isso que uma dev pleno que mentorei saiu de 12 sprints seguidas sem bater o compromisso para 95% de entrega em seis sprints, sem trocar de stack, de time ou de PO.
Por que projeto grande sempre atrasa?
Em todo projeto que eu vi atrasar nos meus 16 anos liderando time, a última tarefa nunca foi a culpada. O atraso foi se acumulando antes: tarefa aceita mal definida, estimativa otimista, retrabalho chamado de “polimento”, aviso que chegou tarde. Quando o prazo estoura, a empresa cobra como falha de execução e o profissional aceita a culpa como se fosse dele. Os dois erram o alvo. O defeito está em como alguém quebrou e acompanhou o trabalho.
Tarefa grande esconde escopo. “Implementar autenticação no app” parece uma coisa só e carrega uma dúzia de decisões que ninguém tomou ainda. Você começa, trava no meio e não sabe dizer quanto já andou. Aí responde “tá quase” na daily por quatro dias seguidos. Você conhece esse colega. Talvez seja você.
Como funciona a quebra Macro, Meso e Micro?
São três níveis, e cada um tem uma função diferente.
Macro é a direção: “migrar o billing para o novo provedor”, “lançar o onboarding novo”. Ninguém executa uma frase dessas. Ela serve para todo mundo saber para onde o time está indo.
Meso são os blocos que compõem a entrega. No caso da autenticação: tela de login, cadastro, recuperação de senha, integração com a API, validação de e-mail e mensagens de erro. Já dá para enxergar o tamanho, mas cada bloco ainda esconde dias de trabalho.
Micro é a tarefa atômica: criar o componente do formulário de login com validação no cliente, implementar a rota de login que devolve o token, escrever o teste de ponta a ponta com credencial válida, configurar o redirecionamento depois do login. No livro eu fixo a régua assim: “Tarefa atômica equivale a até 4 horas de execução.” Passou disso, você ainda não terminou de quebrar.
O erro que eu mais vejo em pleno travado é pegar um bloco Meso e sair executando. O profissional experiente quebra o Meso em Micro antes de escrever a primeira linha de código.
Como saber se a tarefa está pequena o bastante?
Use o teste dos 5 minutos. Olhe para a tarefa e responda: você consegue começar nos próximos 5 minutos sem nenhuma dúvida sobre o que fazer? Se sim, ela está atômica. Se a resposta honesta for “preciso pensar uma hora antes”, a quebra ainda não terminou. Quase todo atraso que eu rastreei começou numa tarefa dessas, que alguém pegou e tocou assim mesmo.
Com agente de IA a coisa piora. O agente começa em 5 segundos, sem pensar nada, e entrega o lado errado com documentação bonita.
O que fazer antes de começar a codar?
Confirmar o entendimento por escrito. Uma mensagem curta para quem pediu: “Entendi que é [resumo], é isso? Quer que eu confirme algum detalhe antes de começar?” Custa dez minutos.
“Eu fiz o que pediram” é a frase de quem fez o que interpretou. Quando a entrega vai para o lado errado, a culpa recai na empresa que “não foi clara”. Errado. A culpa fica com quem não perguntou.
A conta a favor desses dez minutos tem dono: Boehm e Basili mediram que corrigir um problema depois da entrega custa até 100 vezes o que custaria na fase de requisito e design (IEEE Computer, 2001).
Como acompanhar o andamento sem virar microgestão?
Com dois rituais pessoais que somam 7 minutos por dia.
De manhã, o microplanejamento de 5 minutos: as três coisas que você vai entregar hoje, o obstáculo que já enxerga e de quem precisa de resposta, com horário. No fim do dia, o checkout de 2 minutos: o que ficou pronto de verdade, o que não ficou e por quê, por onde você começa amanhã e o alerta que alguém precisa receber hoje.
Em um mês fazendo isso, você tem histórico real do seu ritmo, e esse histórico vale mais que qualquer planning poker como base de estimativa. Quando o time inteiro faz o checkout num canal escrito, o gestor para de perguntar “como vai a sprint?” em umas quatro semanas, porque a resposta já está lá antes da pergunta.
O que fazer quando a tarefa vai atrasar?
Avisar na hora em que você percebe, com plano. Esse comportamento separa quem eu promovo de quem eu substituo. O formato que eu uso e ensino:
“Tarefa X. Estava previsto até quinta. Identifiquei agora [bloqueio Y]. Estou tentando A. Se não funcionar até [hora], vou pra B. Nova previsão se for B: sexta. Te aviso novamente em [tempo] com decisão.”
Repare no que a mensagem carrega: o bloqueio, duas rotas e um prazo novo condicionado. Quem recebe consegue replanejar a semana. Nunca vi gestor mandar alguém embora por ter avisado cedo. O que custa o emprego é o atraso que o time descobre na véspera.
Quando a tarefa está pronta de verdade?
Quando passa num Definition of Done pessoal, um checklist que você roda antes de mover o card para “Concluído”. Funciona testado à mão. Você mesmo revisou o código antes de abrir o PR. Tem log e telemetria básicos. A documentação essencial está em dia, os testes automatizados passam, quem pediu validou e o critério de aceite foi confirmado, não presumido.
Falhou um item, o card vai para “em revisão” e você termina. Card fechado sem DoD vira dívida que cobra juros na sprint seguinte, quando volta da revisão com três comentários.
Estimar em story points ainda faz sentido?
Depende da maturidade do time. Story point nasceu com boa intenção, estimar complexidade em vez de horas, e azedou na prática: virou hora disfarçada, a velocity virou vara de cobrança e o planning poker passou a consumir uma ou duas horas discutindo se a tarefa era 5 ou 8.
Na minha leitura de campo, time que entrega não faz planning poker. Quebra em micro, segura o trabalho em andamento baixo, mantém lead time curto e conta itens: se fechou 18 nas últimas duas sprints, a próxima fecha algo entre 15 e 20. Mas eu não tiraria estimativa de time imaturo, aquele em que a sprint é lista de desejos. Ali, tirar a muleta gera caos. Para o time do meio, T-shirt sizing (P, M, G, GG) serve de ponte.
O que muda quando alguém passa a quebrar direito?
Carla (nome trocado, caso real de mentoria, com permissão) era dev pleno numa scaleup de e-commerce. Em 12 sprints seguidas, bateu 100% do compromisso zero vezes. Sempre aparecia um imprevisto com explicação razoável. Quando mapeei o ritmo dela, achei o pacote completo: aceitava tarefas Meso de 3 a 5 dias, não confirmava entendimento, avisava atraso na véspera, não tinha DoD e não media nada.
O plano de 60 dias foi o deste texto. Toda tarefa quebrada em Micro de até 4 horas, com a quebra mostrada ao tech lead. Entendimento confirmado com o PO por escrito. Microplanejamento e checkout visíveis para o time, desvio avisado na hora, DoD em todo PR e DORA pessoal medido toda semana.
Na primeira sprint do plano ela entregou 65% do compromisso. Na quarta, 90%. Na sexta, 95%. A taxa de mudanças que precisaram de correção em produção caiu de 28% para 6% e o lead time, de 5 dias para 1,5. Em dezembro ela foi promovida a sênior, nove meses depois do diagnóstico, e o CTO escreveu na carta de promoção: “Ela passou a ser confiável.” Carla não fez curso novo nem trocou de linguagem. Mudou a forma de quebrar e acompanhar o próprio trabalho.
A mesma quebra serve para comandar agentes de IA?
Serve, ponto por ponto. Eu opero com agentes em mais de vinte repositórios e nenhuma tarefa desce para um agente sem spec de meia página: critério de aceite verificável, o que está fora do escopo e as suposições com dono. O tamanho da mudança decide o rito, que é o Macro, Meso e Micro com crachá novo. O agente pergunta o que a spec não define em vez de inventar, e o teste nasce do critério de aceite, nunca do código que o próprio agente escreveu.
Quem nunca quebrou trabalho direito vai encontrar no agente o júnior mais rápido e mais confiante que já passou pelo time. Ele não trava, não pergunta e entrega torto com convicção.
Faça o teste nesta semana: escreva a spec de meia página da próxima tarefa que você ia delegar, para gente ou para máquina. Se você não conseguir escrever, a tarefa não estava pronta para ninguém.
Onde aprofundar
O capítulo 9 de Maturidade em TI traz o DORA pessoal com as faixas de Elite a Low, as nove ações na ordem em que eu aplico, as métricas para quem executa e para quem lidera e o fluxo completo de spec, sabatina e gate que eu uso com agentes. O livro está na Amazon: Maturidade em TI, de Vinícius Graciano.
Baixe os 22 templates do livro e comece amanhã cedo pelo checklist de DoD e pelo template de aviso de desvio.