Processo

Processo de Desenvolvimento

Última atualização: 19 de Outubro 2025

Metodologia

O projeto Pró-Mata utiliza Scrum adaptado ao contexto acadêmico com sprints de ~3 semanas (variando conforme calendário acadêmico da PUCRS).

Cerimônias Scrum

Sprint Planning

• Quando: Início de cada sprint
• Duração: 2h
• Horário: 17:30
• Participantes: Toda a equipe (AGES I-IV)
• Responsável: AGES IV

Agenda:

1. Revisão do backlog
2. Seleção de user stories para a sprint
3. Estimativas e capacity planning
4. Definição de critérios de aceitação
5. Divisão de tarefas entre AGES I/II

Daily Standup

• Quando: 2ª-feira, 4ª-feira e Sábado
• Duração: ~10min
• Horário: 17:40 (2ª/4ª presencial após aula)
• Participantes: Equipe de desenvolvimento
• Responsável: AGES IV

3 Perguntas:

1. O que fiz desde a última daily?
2. O que farei até a próxima?
3. Há impedimentos?

Observações:

• Dailys presenciais ocorrem em aulas (2ª e 4ª-feira)
• Dailys de sábado via Discord por texto (organizadas via eventos Discord em canal específico)
• Não são diárias como em Scrum tradicional (adaptação ao calendário acadêmico)

Sprint Review

• Quando: Fim de cada sprint
• Duração: 1h
• Horário: 17:30
• Participantes: Toda equipe + Stakeholder (Prof. Augusto Mussi Alvim)
• Responsável: AGES IV

Agenda:

1. Demo das funcionalidades implementadas
2. Feedback do stakeholder
3. Validação dos critérios de aceitação
4. Discussão de próximos passos

Sprint Retrospective

• Quando: Após Sprint Review
• Duração: 1h
• Participantes: Toda a equipe (AGES I-IV)
• Responsável: AGES IV

Formato:

• O que funcionou bem?
• O que pode melhorar?
• Ações de melhoria para próxima sprint
• Documentação de aprendizados

Code Review Meeting

• Quando: Sexta-feira pré-entrega
• Duração: 1-1.5h
• Participantes: AGES I, II e III
• Responsável: AGES III

Propósito:

• Revisão final de PRs críticos
• Validação de padrões de código
• Preparação para deploy

Workflow de Desenvolvimento

1. Planejamento (AGES IV)

• Refinamento de backlog
• Priorização de user stories
• Preparação de Sprint Planning

2. Análise de Requisitos (AGES II)

• Detalhamento de user stories
• Validação de regras de negócio
• Modelagem de dados (se necessário)

3. Desenvolvimento (AGES I)

graph LR
    A[Criar Branch] --> B[Desenvolver]
    B --> C[Commits Semânticos]
    C --> D[Testes Locais]
    D --> E[Push]
    E --> F[Abrir PR]
    F --> G[Code Review]
    G --> H{CI Passou?}
    H -->|Sim| I[Merge]
    H -->|Não| B
    I --> J[Deploy Automático]

Passos Detalhados:

1. Criar branch a partir de develop:

   git checkout develop
   git pull origin develop
   git checkout -b feature/42-login-jwt

2. Desenvolver seguindo padrões:

   • TypeScript strict mode
   • Validação com Zod
   • Testes unitários (Vitest/Jest)
   • ESLint + Prettier

3. Commits semânticos (Conventional Commits):

   git commit -m "feat: adiciona autenticação JWT no backend"
   git commit -m "fix: corrige validação de datas em reservas"
   git commit -m "docs: atualiza README com instruções de setup"

4. Push para GitHub:

   git push origin feature/42-login-jwt

5. Abrir Pull Request para develop:

   • Título claro e descritivo
   • Descrição do que foi implementado
   • Link para issue relacionada (se houver)
   • Screenshots (se UI)

4. Code Review (AGES III + AGES IV)

Checklist do Revisor:

• Código limpo e legível
• Testes adequados (cobertura mantida/aumentada ≥70%)
• Documentação necessária (README, JSDoc para funções complexas)
• Segue padrões do projeto (ESLint, Prettier)
• Tratamento de erros adequado
• Validações de entrada (Zod)
• Concordância com critérios de aceitação
• Documentação Swagger atualizada (endpoints de API)
• Acessibilidade verificada (frontend)

SLA: PRs abertos até 2 dias antes da entrega serão revisados a tempo.

Aprovações Necessárias: Mínimo 2 (AGES III/IV)

5. CI/CD (AGES III)

Pipeline de CI (GitHub Actions):

• Trigger: Push em qualquer branch, PR para develop ou main
• Jobs:
  • Lint (ESLint + Prettier)
  • Test (Jest/Vitest - unit + integration)
  • Build (Compilação TypeScript)
• Requisito: Pipeline deve passar (green) para merge

Pipeline de CD:

• Trigger: Merge em main
• Deploy:
  • Frontend → AWS S3 static hosting
  • Backend → AWS EC2 (Docker containers)
  • Publicação imagens → Docker Hub

6. Sincronização (Automática)

• GitHub → GitLab: Código, branches, commits, tags
• GitHub Issues → GitLab Issues: Sincronização simplificada
• Frequência: A cada push/issue criada

Estrutura de Branches

main (produção)
  ↑
develop (integração)
  ↑
feature/[id]-[descricao]

Convenções:

• feature/[numero-issue]-[descricao-curta]
• Exemplo: feature/42-login-jwt

Não usamos: hotfix/* (ajustes vão na próxima sprint)

Gestão de Issues

Criação de Issues (GitHub)

Template:

## Descrição
[Descrição clara do que precisa ser feito]

## Critérios de Aceitação
- [ ] Critério 1
- [ ] Critério 2
- [ ] Critério 3

## Tarefas Técnicas
- [ ] Tarefa 1
- [ ] Tarefa 2

## Notas Adicionais
[Contexto relevante, links, referências]

Labels:

• bug: Correção de erro
• feature: Nova funcionalidade
• enhancement: Melhoria de funcionalidade existente
• documentation: Documentação
• test: Testes
• frontend: Frontend (React)
• backend: Backend (NestJS)
• database: Banco de dados
• infrastructure: Infraestrutura/deploy
• priority:high/medium/low: Prioridade

Kanban Board (GitHub Projects)

Colunas:

Backlog → To Do → In Progress → Review → Done

Regras:

• Apenas 1 issue por pessoa em "In Progress" (WIP limit)
• Issue só vai para "Done" quando PR está merged
• Revisão semanal do backlog (durante Planning)

Definition of Done (DoD)

Uma tarefa só está DONE quando:

• Código implementado e funcional
• Testes unitários/integração escritos e passando
• Cobertura de testes mantida ou aumentada (≥70%)
• Code review aprovado (mínimo 2 aprovações)
• CI pipeline passando (green)
• Documentação Swagger atualizada (endpoints de API)
• Acessibilidade verificada (frontend - WCAG 2.1 AA quando aplicável)
• Merge realizado em develop
• Issue/PR fechada no GitHub
• Sincronização confirmada no GitLab (mirror)

Padrões de Código

TypeScript

• Strict mode habilitado
• Evitar any (usar unknown quando necessário)
• Interfaces para tipos complexos
• JSDoc para funções públicas complexas

Validação

• Todas as entradas validadas com Zod
• DTOs tipados com createZodDto
• Mensagens de erro claras e consistentes

Testes

• Nomear testes claramente: describe('Component/Function', () => { it('should...') })
• Arrange-Act-Assert pattern
• Mocks para dependências externas
• Cobertura ≥70% (linhas/funções), ≥60% (branches)

Commits

• Conventional Commits obrigatório
• Mensagens em inglês
• Imperativo: "add", "fix", "update" (não "added", "fixed")
• Referência a issues: feat: adiciona login JWT (#42)

Comunicação

Canais

Reuniões Recorrentes

Métricas e Monitoramento

Métricas de Sprint

• Velocity: Story points completados por sprint
• Burndown: Progresso diário da sprint
• Lead Time: Tempo de "To Do" → "Done" (meta: ≤7 dias)

Métricas de Qualidade

• Cobertura de Testes: ≥70% linhas/funções, ≥60% branches
• Taxa de Aprovação Code Review: ≥90% PRs aprovados na 1ª revisão
• Tempo de Code Review: ≤2 dias úteis

Métricas de Deploy

• Frequência de Deploy: 1-2 deploys por sprint
• Taxa de Sucesso Deploy: ≥95% sem rollback
• MTTR: ≤4h (infraestrutura backup disponível)

Gestão de Riscos

Ver Gerencia para matriz completa de riscos e plano de respostas.

Principais Riscos do Processo:

Ferramentas

Desenvolvimento

• IDE: VSCode (recomendado)
• Versionamento: Git + GitHub (desenvolvimento) + GitLab (oficial)
• Board: GitHub Projects (Kanban privado)
• CI/CD: GitHub Actions
• Testes: Vitest (frontend), Jest (backend), Playwright (E2E)

Comunicação da Equipe

• Chat: Discord (canal Pro-Mata)
• Reuniões: Discord Voice + Presencial
• Documentação: GitLab Wiki (Markdown)

Infraestrutura

• Hospedagem: AWS (S3 + EC2)
• Containers: Docker + Docker Hub
• Monitoramento: Umami Analytics

Referências

• Metodologia Completa: Gerencia
• Git Flow: Gerencia
• Stack Tecnológico: Arquitetura
• Convenções Código: Gerencia
• Sprints Detalhadas: Sprints

Última Revisão: 19 de Outubro 2025 Responsável: AGES IV (Gerenciamento de Projeto)