Retro - 26/05/25 - Presencial

Membros presentes: Gabriel Brumer, Hélio Júnior, Luiz Paulo, Pedro Souza, Rafael Rodrigues, Ruver Clacyus

-----------------

5. Política de Comentários

Fica definido que, durante a execução de um card, deve-se manter o histórico de andamento por meio de comentários obrigatórios em situações específicas. Essa prática busca garantir transparência, rastreabilidade e continuidade, especialmente em cenários de troca de responsável, interrupções ou investigações futuras.

São obrigatórios comentários nos seguintes casos:

• Fim de expediente
  Quando a execução de um card em andamento for interrompida pelo encerramento do horário de trabalho, deve ser realizado um comentário com a parcial atual, indicando o que já foi feito, pendências e próximos passos.

• Estouro de SLE*
  Caso o SLE da coluna seja ultrapassado, é obrigatório o comentário com as possíveis causas do estouro, status atual e, se possível, previsão de retomada ou conclusão.

• Checkpoints (marcos relevantes)
  Sempre que houver conclusão de etapa significativa, merges parciais, identificação de dependências, criação de cards derivados, surgimento de problemas externos ou quaisquer situações relevantes no andamento do card, deve ser registrado comentário com o contexto da situação.

• Ausências, interrupções e bloqueios
  Quando o responsável pela execução precisar se ausentar ou for interrompido por qualquer motivo que comprometa a previsibilidade da entrega, ou se o card estiver bloqueado por algum fator externo, deve-se registrar um comentário detalhado com a justificativa da interrupção.

6. Política de Tipagem dos Cards

Fica definido que, para que um card entre no backlog, ele deve obrigatoriamente conter a tipagem correta, com base em sua natureza. Essa prática garante clareza no entendimento, melhor análise de métricas e tratamento adequado das demandas.

São permitidas as seguintes tipagens no fluxos "cards workflow":

• Suporte
  Quando a demanda for uma solicitação pontual, geralmente de ação técnica rápida, como: extração de dados, reprocessamentos manuais, inserções diretas no banco de dados, desbloqueios, correções pontuais sem alteração de lógica do produto.

• Bug
  Quando o card corresponder à correção de um erro ou falha detectada em rotinas existentes, impactando o funcionamento do sistema ou a experiência do usuário. Envolve análise de causa e ajuste de lógica previamente implementada.

• Melhoria
  Quando a demanda tiver como objetivo o desenvolvimento de uma nova funcionalidade, ajuste de comportamento ou evolução do sistema. Representa uma entrega de valor incremental, seja funcional ou técnica.

7. Política de Criticidade das Demandas

Fica definido que toda demanda, ao ser abastecida no ponto de compromisso, deve conter a criticidade definida, com base na urgência e impacto relativo à fila atual de trabalho. Essa definição orienta a priorização, a condução das dailys e a gestão de expectativas com solicitantes.

As classificações possíveis são:

• Baixa
  Demanda que, apesar de relevante, pode aguardar execução em função de outras prioridades mais urgentes. Não há impacto direto imediato na operação ou nos fluxos críticos.

• Média
  Demanda importante, que possui certa prioridade, mas que ainda permite certo grau de flexibilidade na execução. Idealmente deve ser tratada nas próximas sprints.

• Alta
  Demanda com prioridade clara, que exige atenção nas próximas movimentações de cards. Seu atraso pode comprometer fluxos relevantes ou gerar insatisfação perceptível.

• Crítica
  Demanda de altíssimo impacto. Pode representar parada de sistema, risco de perda de dados, exigência legal ou alto impacto comercial. Justifica a reorganização da fila e a suspensão de outras execuções em curso, quase sempre, estará na raia urgente.

Maturidade dos acordos: