Revisão integrada A2 para software engineers

Nível: A2

Objetivo

Integrar as estruturas do A2 em uma sprint completa de software: planejar e atualizar tarefas no passado (past simple), falar do que vai acontecer (will, going to), expressar obrigação e recomendação (must, have to, should), fazer perguntas em stand-up e propor melhorias na retrospectiva com first conditional.

Explicação

Esta revisão atravessa uma sprint inteira de engenharia, do planejamento à retrospectiva. Em cada momento da sprint, um tempo verbal ou modal diferente é mais natural.

Planejamento e atualizações (past simple): durante a daily e nas atualizações de ticket, descreva o que já foi feito e o que não foi feito.

• `Yesterday I finished the migration.`
• `I didn't update the ticket yet.`
• `Did you push the fix?`

Compromissos com a equipe (will e going to): ao pegar uma tarefa ou prometer um prazo, distinga decisão de momento (`I'll...`) de plano já combinado (`I'm going to...`).

• `I'll open a PR for this today.` (decisão de momento)
• `We're going to deploy on Friday.` (plano já combinado no planning)

Obrigação e recomendação (must, have to, should): para a produção use `must` ou `have to`; para uma sugestão use `should`.

• `We must ship a hotfix today.` (obrigação forte)
• `You don't have to attend the retrospective.` (ausência de obrigação)
• `You should add a test for this case.` (recomendação)

Hipóteses e propostas (first conditional): na retrospectiva e em mensagens de follow-up, use `if + present, will + base` para propor mudanças.

• `If we add more tests, we will catch more bugs early.`
• `If this happens again, we will roll back automatically.`

Perguntas típicas de stand-up: três perguntas curtas guiam a daily.

• `What did you do yesterday?`
• `What are you going to do today?`
• `Do you have any blockers?`

Em uma sprint real, todas essas estruturas aparecem misturadas: alguém fala do que fez ontem (past simple), alguém promete entregar algo (will), o líder lembra de uma obrigação (must), outro sugere uma melhoria (should) e a equipe fecha com uma hipótese para a próxima sprint (first conditional).

Exemplos

Erros comuns

• Confundir must e have to: use `must` para obrigação forte da equipe e `have to` para obrigações definidas por processo, nunca `must not` para algo não-obrigatório (prefira `don't have to`).
• Trocar will e going to: `I'll deploy tomorrow` é uma decisão de momento; `I'm going to deploy tomorrow` é um plano combinado.
• Esquecer o verbo base após will: `I will deploying` deve ser `I will deploy`.
• Usar will no if-clause: `If we will add tests, ...` está errado; o correto é `If we add tests, ...`.
• Marcar passado em perguntas com will em vez de did: `Did you deployed?` deve ser `Did you deploy?`.
• Dizer `we must not deploy` quando quer dizer que ninguém é obrigado: prefira `we don't have to deploy`.

Prática guiada

Monte a fala de uma stand-up curta usando todas as estruturas:

• Abertura no passado: `Yesterday I finished the migration.`
• Confirmação com going to: `Today I'm going to deploy the hotfix.`
• Recomendação: `We should add a test for the new endpoint.`
• Obrigação: `We must update the changelog before the release.`
• Hipótese para a próxima sprint: `If we automate the rollback, we will reduce downtime.`

Lendo em sequência, a stand-up soa natural porque cada frase corresponde a um momento diferente do trabalho: passado concluído, plano atual, recomendação, obrigação forte e proposta futura. Tente variar os verbos: use `merge`, `push`, `review`, `ship` em vez de repetir `deploy`.

Resumo

A2 revisado em contexto de sprint: past simple para ações concluídas e perguntas investigativas, will para decisões de momento, going to para planos combinados, must/have to para obrigação, should para recomendação e first conditional para propostas de melhoria na retrospectiva. A daily e a retro juntam todas essas peças em uma narrativa só.

História: Revisão integrada A2 para software engineers

Nível: A2

História em inglês

Sprint planning on Monday

On Monday morning, the team had the sprint planning meeting. The product owner said, "We are going to ship a small dashboard update this week." Anna picked up the dashboard ticket, and Lucas picked up the documentation ticket. They estimated the tickets together and committed to six story points for the week. The team agreed, "If we finish early, we will start the refactor ticket from the backlog."

Daily stand-ups

On Tuesday, Anna said at the stand-up, "Yesterday I finished the dashboard layout, and today I'm going to wire up the API." Lucas answered, "Yesterday I didn't update the README yet, but I'm going to do it this morning." The team lead asked, "Any blockers?" Lucas said, "I have a blocker on the staging environment; I can't deploy my branch." The team lead offered, "I'll open a ticket for the platform team right now."

Code review and deploy

On Wednesday, Anna opened a pull request for the new dashboard. Her teammate reviewed it and said, "Could you add a test for the empty case? You should cover this edge." Anna added the test, pushed her changes, and the reviewer approved the PR. On Thursday, the team deployed the dashboard to production. Right after the deploy, the on-call engineer noticed an error on the login screen.

Hotfix and retrospective

The team lead said, "We must ship a hotfix today. We cannot leave this bug in production." Anna fixed the bug, pushed a new commit, and asked Lucas to review it quickly. Lucas approved it, the on-call engineer merged it, and the team deployed the hotfix. On Friday afternoon, the team had the retrospective. Anna said, "If we add a smoke test for the login flow, we will catch this kind of bug before deploy." The team agreed to add the smoke test in the next sprint and wrote the action item in the changelog.

Tradução linha por linha

Notas de vocabulário

• sprint planning = reunião de planejamento da sprint, geralmente no início do ciclo
• We're going to ship = plano combinado de lançar algo; going to + base
• story points = unidade de estimativa de esforço usada em Scrum
• stand-up = reunião diária curta, normalmente em pé
• blocker = algo que impede o time de progredir; deve ser reportado na stand-up
• pull request (PR) = pedido formal de revisão e merge de um branch
• Could you add a test? = pedido educado em code review
• on-call engineer = engenheiro de plantão; responsável por responder a incidentes
• hotfix = correção urgente feita diretamente em produção
• smoke test = teste rápido que verifica as funções principais após o deploy
• If we add... , we will catch... = first conditional: hipótese (if + present) e consequência (will + base)
• changelog = registro de alterações; também usado para anotar itens de ação

Perguntas de compreensão

1. What did the team plan to ship during the sprint?
2. Which ticket did Lucas pick up?
3. What was Lucas's blocker?
4. What did Anna add after the code review feedback?
5. What went wrong right after the Thursday deploy?
6. What did the team decide about the hotfix?
7. Who reviewed Anna's hotfix before the merge?
8. What did Anna propose in the retrospective?
9. Why did the team agree to add the smoke test?
10. Where did the team record the action item from the retrospective?

Prática com a história

1. Transforme em pergunta: Anna picked up the dashboard ticket.
2. Passe para a negativa: The team deployed the hotfix.
3. Faça uma proposta em first conditional: se adicionarmos retry, reduzimos erros.
4. Reescreva com going to: We will demo on Friday.
5. Dê uma recomendação educada: precisamos testar o caso vazio.
6. Responda negativamente: Did the on-call merge the hotfix?