Módulo 4: Conclusão, Demonstração ao Vivo e Retrospectiva
Trabalho Prático Integrador — Gestão de Projetos de Software (2026-2)
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.
- 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-integradoresno 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 auditar as contribuições individuais.
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:
- Qualidade do Produto Final: O Professor Agente está estável, bem documentado e pronto para uso?
- Pitch e Demonstração ao Vivo: A equipe consegue comunicar com clareza o valor do produto e demonstrar sua eficácia em tempo real?
- 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
- 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").
- Criar uma Git Tag formal marcando a versão final do software entregue (
- README no Padrão Portfólio:
- O
README.mdprincipal 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.
- O
- Fechamento de Backlog:
- 100% das Milestones e Issues concluídas e formalmente encerradas no GitLab.
🎤 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:
- 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.
- Live Demo (Demonstração Prática ao Vivo):
- Demonstração real do assistente interagindo com uma dúvida ou problema ao vivo, provando que ele conduz o aluno passo a passo sem fornecer código pronto.
- 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 dinâmica, segura e pontual (respeitando o teto de 5 minutos). Live demo bem-sucedida demonstrando a filosofia socrática com participação de todos os membros. (3,5 pts) | Apresentação confusa, estouro de tempo ou demo com falhas/instabilidade técnica. Nem todos os membros participaram. (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) |
| Auditoria Final de Autoria Git | Histórico consistente do início ao fim do semestre, comprovando trabalho contínuo e equilibrado de todos os integrantes. (1,5 pt) | Contribuições de última hora na reta final para tentar compensar inatividade nos módulos anteriores. (0,9 pt) | Membros sem evidência de autoria (nota individual zerada). (0 pt) |
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!