O agente terminou a tarefa ontem à tarde. O diff parece bom, a suíte rodou e o PR está quase pronto. Na Daily, quando chega a sua vez, alguém pergunta como está o item. Você abre o git, rola a lista de arquivos e começa: "mexi no serviço de pagamento, num DTO, em dois testes…".
Ninguém na reunião consegue repetir o que mudou, e você também não. Ler em voz alta a mensagem de commit que o agente escreveu não é Daily. É só leitura de metadados.
O hábito proposto aqui é pequeno e dá para checar. Antes do push, ou antes da reunião, feche o diff e conte a mudança uma vez, em quatro campos: intenção, área, risco e verificação. Se você não conseguir sem reabrir o arquivo, descobriu algo importante antes de abrir o PR, e não no meio da reunião.
O que a Daily realmente pede
O Scrum Guide de novembro de 2020 diz que a Daily Scrum é "a 15-minute event for the Developers of the Scrum Team". O propósito também está escrito: "to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."
Não há nada sobre inventário de arquivos. O Sprint Backlog tem o Sprint Goal (o porquê), os itens selecionados (o quê) e um plano acionável para entregar o incremento (o como). A Daily confere o progresso em relação a isso. A lista de classes que o agente tocou não mostra se o time chegou mais perto do objetivo.
A Daily também não é um relatório de status para o gestor. O evento é dos Developers. Product Owner e Scrum Master só participam como Developers quando estão trabalhando em itens do Sprint Backlog. Na página de revisões, a revisão de 2013 já reforçava a Daily como evento de planejamento, porque ela era tratada como evento de status com frequência demais.
Também vale abandonar um costume antigo. A versão de 2020 removeu as três perguntas da Daily: o que fiz ontem, o que farei hoje e quais são os impedimentos. A mesma página lista essa remoção nas mudanças entre 2017 e 2020, no item "Even Less Prescriptive". Em 2017 as perguntas eram apenas um exemplo. Hoje o Guide deixa os Developers escolherem a estrutura e as técnicas, desde que a Daily trate do progresso em direção ao Sprint Goal e termine com um plano acionável para o dia seguinte.
Como o time escolhe a estrutura, o modelo a seguir é uma opção que ele pode adotar. Não é lei.
Um modelo de 60 segundos para a sua vez
| Campo | Pergunta | O que não conta |
|---|---|---|
| Intenção | Que comportamento muda, e por quê, em relação ao Sprint Goal? | "O agente mexeu em três classes" |
| Área | Onde a mudança encosta e onde ela não encosta? | Lista de caminhos de arquivo |
| Risco | O que quebra se a sua hipótese estiver errada? | "Acho que nada" |
| Verificação | Como você checou, ou como vai checar? | "O agente já testou" |
Os 60 segundos são uma heurística editorial da DevDojo para uma pessoa só, para que o time inteiro ainda caiba nos 15 minutos. Não é regra do Scrum, não é norma ISO e não saiu de nenhum estudo. A Daily continua tendo 15 minutos. O que dura um minuto é a sua vez.
Um exemplo falado com os quatro campos:
> "Para o Sprint Goal de checkout estável: a intenção é recusar pagamento duplicado no retry. Área: fluxo de captura no checkout, não o antifraude. Risco: barrar um pedido legítimo depois de um timeout. Verificação: reproduzi o retry em homologação e o segundo POST não captura."
Isso leva uns vinte segundos e ainda sobra tempo para alguém perguntar alguma coisa. Repare no que ficou de fora: nome de classe, quantidade de arquivos e a frase que o agente escreveu no commit.
O que continua sendo seu quando o agente digitou
O agente escreve o código. Quatro coisas continuam sendo suas:
- o porquê da mudança;
- o raio de impacto: o que mais pode ser afetado;
- a verificação e o rollback: como você sabe que funciona e como volta se não funcionar;
- a decisão de entregar.
A documentação do Linux kernel sobre conteúdo gerado por ferramentas é direta: "You are expected to understand and to be able to defend everything you submit. If you are unable to do so, then do not submit the resulting changes." Isso é regra de processo de um projeto, não tese jurídica. Aqui ela serve só para registrar uma ideia simples: entenda e saiba defender a mudança, ou não envie.
As práticas de engenharia do Google para descrições de CL pedem que a descrição explique o quê e o porquê, com uma primeira linha que se sustente sozinha. A sua vez na Daily é a versão falada disso, com risco e verificação junto. Lista de arquivos e mensagem do agente colada valem tanto quanto um "Fix bug".
Na prática, a frase que você precisa conseguir dizer é parecida com esta:
> "O diff é do agente; a decisão de abrir o PR é minha. O risco é captura dupla, e a verificação que eu aceito é o retry reproduzido em homologação."
O agente não participa da Daily no seu lugar. Quando um colega pergunta "e se falhar?", a resposta precisa sair de você, sem abrir o transcript da ferramenta. Uma história bonita de "pronto" contada por quem ainda não sabe dizer o risco é exatamente o que essa pergunta revela.
O teste de hoje: falar uma vez antes do push
No texto sobre revisar código sem reler no automático, o exercício era ler o próprio diff em silêncio. Aqui o exercício é falar a mudança do agente com o diff fechado.
Antes do push, ou antes da reunião:
- Feche o diff, o terminal com o
git loge a conversa com o agente. - Fale uma vez, em voz alta ou para um colega, os quatro campos: intenção, área, risco e verificação.
Reprova quem reabre o diff, lista nomes de arquivo ou lê a mensagem de commit do agente.
Passa quem consegue fazer o ouvinte repetir os quatro campos sem olhar o git.
O erro mais comum é deixar o primeiro ensaio para a própria Daily. Aí a vontade de reabrir o diff aparece justamente com o time esperando, e você acaba rolando arquivos enquanto a rodada fica parada no seu nome. Ensaie antes. Um colega na mesa ao lado ou uma chamada de dois minutos já bastam.
Se o seu time ainda está decidindo o que o agente pode fazer no repositório, esse é outro problema, com outra resposta: gates no repositório antes do primeiro PR. Este hábito vale com ou sem gates, porque é sobre o que você consegue explicar.
Quando a resposta honesta é "ainda estou investigando"
Às vezes você fecha o diff e o risco simplesmente não vem. Isso não reprova o hábito. Reprova é inventar um "pronto" para a rodada não perder o ritmo.
Esta linha passa:
> "Ainda estou investigando o retry no timeout; o risco é captura dupla; a verificação prevista é reproduzir dois POSTs em homologação antes de abrir o PR."
Os quatro campos continuam ali. "Investigando" é a intenção e o status, não uma frase vazia. O time sai sabendo o que falta e pode ajustar o plano do dia, que é justamente o propósito da Daily. O Guide chama isso pelos valores dele: Openness ("The Scrum Team and its stakeholders are open about the work and the challenges") e Courage ("to do the right thing, to work on tough problems"). Entendimento incompleto também é informação sobre o progresso.
A recomendação da DevDojo é condicional e firme: abra o PR só quando conseguir preencher os quatro campos sem reabrir o diff. Se não conseguir, a sua linha na Daily é "ainda estou investigando", e o PR espera. É a regra do kernel aplicada à reunião: se não sabe defender, não envia.
E se o time adotar o modelo e a Daily virar recitação de formulário, ou estourar os 15 minutos, abandone o modelo. Os Developers escolhem a estrutura, e o modelo só vale enquanto ajuda a inspecionar o progresso.
Próximo passo
Hoje, pegue o PR do agente que está mais perto do push. Feche o diff e conte a mudança uma vez para alguém. Se a pessoa repetir intenção, área, risco e verificação sem olhar o git, faça o push. Se não, você já tem a sua fala na Daily de amanhã: "ainda estou investigando".