Módulo 4: Conclusão, Demonstração ao Vivo e Retrospectiva

Trabalho Prático Integrador — Gestão de Projetos de Software (2026-2)

Autor

Prof. Aléssio Miranda Júnior

Data de Publicação

31/08/2026

Data de Modificação

20/09/2026

Aviso⚠️ Proposta Não Revisada

Este documento é um rascunho preliminar de proposta para o Módulo 4 do Trabalho Prático Integrador. Os prazos, critérios e entregáveis detalhados abaixo representam o planejamento inicial e estão sujeitos a refinamentos e homologação pelo professor.

Importante📅 Informações da Entrega (Previsão)
  • Prazo Previsto do Módulo 4: 07/12/2026 (Segunda-feira, às 23:59)
  • Apresentações / Pitch: Em sala de aula na data agendada pelo professor.
  • Valor: 10,0 pontos (do total de 30 pontos do Trabalho Prático)
  • Onde entregar: Repositório oficial da equipe no subgrupo gps-projetos-integradores no GitLab (git.juninho.com.br).

1. Visão Geral e Propósito do Módulo 4

O Módulo 4 encerra o ciclo de vida do Trabalho Prático Integrador. O objetivo não é apenas entregar um software pronto, mas apresentar os resultados do produto, refletir criticamente sobre o processo de gestão e reunir evidências contextualizadas de colaboração.

A equipe deverá apresentar a história completa do projeto: como o escopo planejado no Módulo 1 evoluiu nas Sprints, como os riscos foram gerenciados, quais foram as maiores dificuldades e como a metodologia de gestão contribuiu para o resultado final.

A avaliação final é composta por três dimensões:

  1. Qualidade do Produto Final: O Professor Agente está estável, bem documentado e pronto para uso?
  2. Pitch e Demonstração ao Vivo: A equipe consegue comunicar com clareza o valor do produto e demonstrar sua eficácia em tempo real?
  3. Retrospectiva e Lições Aprendidas: A equipe demonstra maturidade reflexiva ao analisar seus acertos, gargalos e aprendizados de gestão?

2. Checklist de Entregáveis Obrigatórios

seu-repositorio/
├── README.md                          # Portfólio final do projeto (badges, demo, arquitetura e equipe)
├── docs/
│   ├── RETROSPECTIVA.md               # Análise crítica pós-morte do projeto e lições aprendidas
│   ├── RELATORIO_FINAL_GESTAO.md      # Métricas de esforço (estimado vs. realizado) e encerramento
│   └── slides/
│       └── apresentacao_pitch.pdf     # Slides utilizados na apresentação final
├── src/                               # Código-fonte final (Release v1.0.0 marcada com Git Tag)
└── .gitlab-ci.yml                     # Pipeline verde e operante

📂 Frente 1: Encerramento do Repositório e Release Final

  1. Tag de Release (v1.0.0):
    • Criar uma Git Tag formal marcando a versão final do software entregue (git tag -a v1.0.0 -m "Release Final").
  2. README no Padrão Portfólio:
    • O README.md principal do repositório deve funcionar como a vitrine do produto:
      • Badges de CI/CD e status do projeto;
      • GIF animado ou capturas de tela demonstrando o bot em ação;
      • Guia rápido de instalação e uso;
      • Tabela final de autores e links de contato.
  3. Fechamento de Backlog:
    • Milestones e mudanças significativas encerradas, adiadas ou replanejadas com justificativa no GitLab. Itens fora do MVP não precisam ser concluídos se a decisão de escopo estiver registrada.

🎤 Frente 2: Apresentação Final (Pitch Dinâmico de 5 Minutos & Demonstração ao Vivo)

Cada equipe terá um tempo cronometrado e objetivo em sala de aula (Pitch de exatamente 5 minutos) para apresentar seu projeto:

  1. Estrutura da Apresentação (Slides):
    • O Problema e a Proposta de Valor: Apresentação do Professor Agente (visão WokDex) e da Ideologia Pedagógica adotada;
    • Gestão do Escopo e Cronograma: Comparação entre o que foi planejado na EAP (M1) e o que foi efetivamente entregue (M4);
    • Desafios e Engenharia: Como calibraram o prompt socrático (da programação básica a grafos) e automatizaram o CI/CD;
    • Métricas de Gestão: Estimado \(\times\) Realizado nas issues do GitLab.
  2. Live Demo (Demonstração Prática ao Vivo):
    • Demonstração do assistente em uma dúvida ou problema, explicando a política de ajuda graduada, os limites observados e as evidências usadas para avaliar seu comportamento.
  3. Participação Coletiva:
    • Todos os integrantes da equipe devem falar e apresentar suas respectivas áreas de contribuição.

📝 Frente 3: Retrospectiva Ágil e Lições Aprendidas (docs/RETROSPECTIVA.md)

A equipe deve realizar uma reunião formal de retrospectiva e registrar: - O que funcionou muito bem? (Práticas de gestão, ferramentas ou dinâmicas que geraram alto rendimento). - O que falhou ou gerou atrito? (Gargalos de comunicação, subestimação de prazos, refações de prompt). - O que faríamos diferente se começássemos hoje? (Plano de ação corretivo e aprendizado para projetos futuros). - Autoavaliação da Equipe: Breve comentário sobre a colaboração e maturidade do time.


3. Rubrica de Avaliação Preliminar (10,0 Pontos)

Critério Excelente (100%) Bom (70%) Insuficiente (0%)
Apresentação Pitch & Live Demo Apresentação clara e pontual, demo ou contingência preparada, política de ajuda graduada e limites comunicados, com participação da equipe. (3,5 pts) Apresentação confusa, estouro de tempo ou demonstração sem explicação de limites e contingência. (2,3 pts) Não apresentou ou apresentação totalmente despreparada. (0 pt)
Qualidade e Estabilidade do Produto Final Software funcional, interface polida, release v1.0.0 tagueada, documentação completa e pipeline CI/CD verde. (3,0 pts) Software funciona com ressalvas ou documentação do README incompleta. (2,0 pts) Produto não compila ou não executa. (0 pt)
Retrospectiva e Relatório de Gestão Documento RETROSPECTIVA.md profundo, honesto e reflexivo, com análise de métricas de esforço e lições aprendidas. (2,0 pts) Retrospectiva genérica ou superficial sem análise crítica real do processo de trabalho. (1,3 pt) Ausente. (0 pt)
Evidências finais de colaboração Conjunto consistente de issues, MRs e revisões, ADRs, testes, demos, retrospectivas e defesa técnica, interpretado com complexidade, disponibilidade e colaboração. (1,5 pt) Evidências parciais ou sem contexto suficiente para explicar decisões e contribuições. (0,9 pt) Não há evidências suficientes para avaliar a participação. (0 pt)

Dica💡 Dica do Professor

A apresentação não é um exame de código linha a linha. É a oportunidade da equipe vender a história de sucesso da gestão do projeto: mostrem como o time superou obstáculos e entregou um produto com valor real!

De volta ao topo