Skip to main content

🚀 Processo no desenvolvimento de produtos digitais

⏱️ Apontamento de Horas para tarefas: Estimado e Realizado​

🎯 Objetivo​

Garantir o controle e a rastreabilidade do tempo investido nas atividades, comparando o planejado com o executado.

📋 Processo​

Estimativa: Deve ser registrada no início de cada sprint (no rito de planning) ou do desenvolvimento da tarefa, com base em planning poker, histórico ou benchmark.

📢 Regras para tasks
  • Uma task não pode ser estimada com mais de 8 horas;
  • Tasks devem ser criadas para tratar de uma única responsabilidade;

Apontamento Realizado: Deve ser feito diariamente pelos colaboradores, utilizando a ferramenta oficial (Board do produto no Azure DevOps).

Horas restantes: Devem ser atualizadas junto ao realizado, e devem estar sempre zeradas ao mover o card para ‘Done’.

Revisão: O time de gestão revisa diariamente o dashboard do produto, para identificar os desvios entre estimado e realizado.

Responsáveis: Desenvolvedores, Tech Lead, PDO.

🔄 Envio de PRs (Pull Requests) e MRs (Merge Requests)​

🎯 Objetivo: Garantir qualidade e rastreabilidade nas alterações de código.

📋 Processo​

Todo código deve ser submetido via PR/MR.

O PR/MR deve conter:

  • Descrição clara da alteração.
  • Referência ao item de backlog.
  • Checklist de revisão (testes, documentação, etc.).
  • Revisão de código obrigatória por pelo menos 1 membro do time, preferencialmente o Tech Lead.
  • Aprovação e merge somente após validação dos testes automatizados.

Ferramentas: GitLab GAB

📊 Uso do Azure DevOps​

🎯 Objetivo: Centralizar a gestão de projetos, versionamento de código, CI/CD e acompanhamento de métricas.

Processo​

Boards: Utilizados para planejamento e acompanhamento de sprints. Saiba mais sobre o uso do board neste link

Dashboards: Visualização das métricas da sprint e progresso.

Boas práticas: Atualizar tarefas diariamente.

Informe

Os cards devem ser movidos em tempo, pois há contabilização automática das horas executadas;

📢 Encerramento de tarefas na sprint
  • Ao final da sprint, todas as tasks devem estar marcadas com status DONE, e as histórias de usuário (que tenham todas as tasks com status DONE) devem ser marcadas com status CLOSED
  • Idealmente, uma história de usuário deve ser entregue dentro do tempo de uma SPRINT.
  • Caso não seja possível, a entrega deve ser registrada como uma FEATURE.

Regras de preenchimento e manutenção dos cards​

  • Descrição clara e objetiva: Toda task deve conter uma descrição compreensível por qualquer membro do time.
  • Checklist de subtarefas: Utilize checklists para dividir entregas maiores em etapas menores.
  • Responsável atribuído: Toda task deve ter um responsável definido.
  • Labels e tags: Use etiquetas padronizadas para facilitar a categorização (ex: bug, ajuste, refatoração, design, backend).
  • Comentários e atualizações: Registre decisões, dúvidas ou atualizações relevantes nos comentários do card.

📌 Task de GMUD por Sprint​

🎯 Objetivo: Garantir que cada sprint tenha visibilidade e planejamento adequado para a subida de itens em produção.

Orientação​

  • Deve ser adicionada uma task com o nome padrão:
    "Para a GMUD - Sprint [Nº da sprint]"

  • Essa task deve conter:

    • Checklist dos itens que serão incluídos na GMUD.
    • Referência aos PRs/MRs relacionados.
    • Plano de rollback (se aplicável).
    • Responsáveis pela execução.
    • Data e horário previstos para a execução.

  • A task deve ser criada no início da sprint e atualizada conforme os itens forem concluídos.

Importante

Essa task não substitui o processo formal de solicitação de GMUD, mas serve como apoio para organização e rastreabilidade dentro do board da squad.

🚧 Gestão de Riscos e Impedimentos​

🎯 Objetivo: Antecipar e mitigar riscos que possam comprometer entregas.

Processo:

  • Impedimentos devem ser registrados no board. As tasks afetadas devem ser marcadas com status pause até que o impedimento seja resolvido.
  • O Tech Lead ou PDO deve ser acionado imediatamente.
  • Riscos identificados devem ser discutidos em ritos de planning ou retrospectiva.

Revisão e QA​

Antes de marcar uma task como DONE, verifique:

  • Os critérios de aceite foram atendidos;
  • O código foi revisado (quando aplicável);
  • A funcionalidade foi testada;
  • A documentação (se necessária) foi atualizada.

📈 Indicadores de Saúde da Sprint​

🎯 Objetivo: Medir a eficiência, qualidade e previsibilidade do time.

Indicadores adotados:

  • Velocidade da Sprint.
  • Assertividade em Produção
  • Taxa de Retrabalho.
  • Cobertura de Testes Automatizados.
  • Satisfação do Cliente (NPS interno).
  • Frequência de análise: Por sprint, em reuniões de retrospectiva e análise crítica.

🤝 Estimado e Realizado: Co-responsabilidade​

🎯 Objetivo: Promover a responsabilidade compartilhada entre time técnico e gestão sobre prazos e entregas.

Princípios:

  • Estimativas devem ser sempre feitas em conjunto (devs +Tech Lead).
  • O cada desenvolvedor será responsável por documentar quando houver desvios do planejado, relatando ao PDO.
  • Ferramentas de apoio: Azure DevOps, planilhas de controle, reuniões de checkpoint.

🔨 Processos de GMUD (Gestão de Mudanças em Ambiente de Produção)​

🎯 Objetivo: Garantir que mudanças em produção sejam seguras, rastreáveis e aprovadas.

Processo​

Solicitação de GMUD: Criada com antecedência mínima de 24h e até o horário máximo de 17h;

Conteúdo obrigatório: Lista de itens para PR, scripts, plano de rollback, responsáveis.

Aprovação: E-mail de com evidências de validação enviado pelo P.O. (cliente).

Execução: Em janela definida, com acompanhamento. Deverá ser alinhado com o Tech Lead responsável.

Pós-implementação: Verificação de sucesso pelo time de sucesso do cliente.

Ferramentas: Documento padrão, Board do Azure DevOps

Boas práticas​

Tratativa de erros em requisições realizar no frontend​

Contexto Casos onde a API retorna erro, mas o frontend não exibe nada ao usuário, geram a percepção de “aplicação quebrada”. Isso é um falso negativo de UX por falta de comunicação. Para evitar que tal caso aconteça, devemos tratar e, se possível, padronizar a tratativa para que todo erro relevante seja mostrado em um local visível (ex.: toast), sem depender de cada chamada manualmente.

Diretrizes rápidas

  • Sempre informe o usuário com uma mensagem clara e, quando possível, ação sugerida.
  • Mensagens curtas e orientadas à ação (ex.: “Preencha o campo E‑mail”).
  • Centralize a tratativa de erros (interceptor do Axios + utilitário de normalização).

No exemplo mínimo abaixo, o toast é exibido apenas quando a resposta HTTP for 400, comportamento que deve ser obrigatório garantindo a exibição de informação para o cliente devido à natureza do erro.

import axios from "axios";
import { toast } from "react-toastify";

export const api = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
});

api.interceptors.response.use(
  (res) => res,
  (error) => {
    const status = error?.response?.status;
    if (status === 400) {
      const msg = error?.response?.data?.message ?? error?.message ?? "Erro desconhecido.";
      toast.error(`Ocorreu um erro na operação: ${msg}`);
    }
    return Promise.reject(error);
  }
);

O template angular18-templates, disponível no GitLab, trata as respostas 400 automaticamente, exibindo um toast com as informações retornadas pela API:

protected handleError(error: any): Observable<never> {
    let errorMessage = '';
    if (error.error instanceof ErrorEvent) {
      // Get client-side error
      errorMessage = error.error.message;
    } else if (error instanceof HttpErrorResponse && error.error.Message) {
      // Get server-side error
      errorMessage = error.error.Message;
      if (error.status === 400)
      {
        this.openSnackBar(errorMessage);
      }
    } else {
      errorMessage = `Error Code: ${error.status}\nMessage: ${error.message}`;
    }
    return throwError(errorMessage);
  }

  protected openSnackBar(message: string) {
    this.snackBar.open(message, 'Fechar');
  }

Utilização de data e hora​

Contexto Por padrão, o template interno trabalha com informações e registros salvos em UTC no backend. Isso garante consistência nas datas porque padroniza o armazenamento e evita disparidades de fuso em comparações, ordenações e auditorias.

Diante disso, toda informação enviada do frontend para o backend que envolva data e/ou hora deve ser convertida para UTC antes (ou no momento) do envio. O fuso local é exclusivamente para a exibição ao usuário e não deve ser transportado junto com o registro.

Essa prática simples assegura que os dados permaneçam consistentes no contexto da aplicação. Ao frontend cabe apenas converter de UTC para o fuso do usuário durante a exibição e a interação na tela.

Por fim, adote a ISO-8601 como padrão de serialização de data e hora, incluindo o offset; prefira o sufixo Z para indicar UTC. Isso elimina ambiguidades e mantém a compatibilidade entre sistemas.