Módulo 3: Execução Ágil, Sprints e Automação CI/CD

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

31/08/2026

Aviso⚠️ Proposta Não Revisada

Este documento é um rascunho preliminar de proposta para o Módulo 3 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 3: 16/11/2026 (Segunda-feira, às 23:59)
  • 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 3

O Módulo 3 é a fase mais densa de execução e desenvolvimento ágil do Trabalho Prático. Aqui, a equipe coloca em prática os conceitos de agilidade (Scrum/Kanban), maturidade de engenharia de software e automação DevOps através do GitLab CI/CD.

Neste módulo, o Professor Agente deixa de ser apenas um script de terminal e passa a ter sua interface funcional (Telegram, Discord, Web ou Streamlit) operando de ponta a ponta com o motor pedagógico socrático desenvolvido nos módulos anteriores (atendendo tanto a dúvidas de programação elementar quanto a desafios de estruturas e grafos).

A equipe deve evidenciar:

  1. Ritmo Ágil Sustentável: O time está utilizando os GitLab Issue Boards, estimativas de tempo e limites de WIP para gerenciar o fluxo de desenvolvimento?
  2. Integração Completa: A interface de usuário (UI) está conectada com o backend e com o provedor de LLM?
  3. Automação com CI/CD: O repositório possui um pipeline no .gitlab-ci.yml que roda testes automatizados, valida formatação (lint) e testa chamadas de prompt a cada Merge Request?
  4. Colaboração Rastreável: As entregas são distribuídas de forma homogênea entre os membros do time, sem centralização de commits?

2. Checklist de Entregáveis Obrigatórios

seu-repositorio/
├── .gitlab-ci.yml                     # Pipeline com estágios de Lint, Test e Build/Deploy
├── README.md                          # Instruções completas de setup, variáveis de ambiente e uso
├── docs/
│   ├── ARQUITETURA.md                 # Diagrama de blocos e fluxo de dados (Mermaid)
│   ├── GUIA_USUARIO.md                # Como interagir com o bot (comandos e fluxo socrático)
│   └── SPRINT_REVIEW_M3.md            # Registro das entregas da Sprint e métricas de esforço
├── src/
│   ├── ui/ (ou bot/)                  # Interface do usuário (Telegram/Discord/Streamlit/Web)
│   ├── core/                          # Orquestração do diálogo, System Prompt e chamadas de API
│   └── utils/                         # Formatação de código, logging e sanitização de inputs
└── tests/
    ├── test_prompts.py                # Testes de regressão de comportamento da IA
    └── test_integration.py            # Testes de integração da interface com o backend

📂 Frente 1: Interface Funcional e Integração de Ponta a Ponta

  1. Interface do Usuário Operante:
    • O bot/app deve estar funcional em sua interface escolhida (ex: Bot no Telegram/Discord ou interface Web/Streamlit).
    • O usuário deve conseguir colar enunciados de problemas de maratona (ou links de problemas) e iniciar a sessão de mentoria socrática.
  2. Robustez e Usabilidade:
    • Tratamento amigável de erros (ex: timeout da API de IA, entradas muito longas, caracteres especiais).
    • Manutenção de contexto consistente durante toda a sessão de resolução de um problema.

⚙️ Frente 2: Automação CI/CD no GitLab (.gitlab-ci.yml)

A maturidade do projeto será avaliada pela qualidade do pipeline de integração contínua:

  1. Estágio de Lint/Qualidade (lint):
    • Verificação estática de código e boas práticas (ex: flake8/black/ruff para Python, eslint para JS/TS, checkstyle para Java).
  2. Estágio de Testes Automatizados (test):
    • Execução automática da suíte de testes unitários e de integração (pytest, jest, junit).
    • Pelo menos um teste que valida o comportamento básico de recusa à resposta pronta (prompt regression test).
  3. Uso Correto de Segredos (CI/CD Variables):
    • As chaves de API da LLM nunca devem estar no código-fonte. Devem ser injetadas via GitLab CI/CD Settings -> Variables (marcadas como Masked e Protected).
  4. Selo de Pipeline Passando:
    • O branch main deve estar verde (todos os jobs do CI/CD com status Passed).

🎯 Frente 3: Rastreabilidade e Gestão Ágil no GitLab

  1. Gestão Visual com Boards:
    • Uso de colunas no GitLab Boards (Backlog, To Do, In Progress / Doing, Review, Done).
    • Aplicação de labels temáticas (frontend, backend, prompt, ci/cd, bug, documentation).
  2. Merge Requests e Branch Protection:
    • A branch main deve ser protegida contra commits diretos.
    • Todo o código deve ser submetido via feature branches e aprovado por meio de Merge Requests contendo descrição da entrega e vínculo com as issues (Closes #ID).
  3. Distribuição Equitativa de Contribuição:
    • Análise do gráfico de Contributors no GitLab: todos os membros devem apresentar commits frequentes e participações ativas em revisões de código.

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

Critério Excelente (100%) Bom (70%) Insuficiente (0%)
Interface e Integração Funcional Bot/interface opera sem falhas de ponta a ponta, conecta com a API e guia o aluno com diálogo socrático fluido. (3,5 pts) Interface funciona mas trava frequentemente, tem alta latência ou perde o contexto da conversa. (2,5 pts) Interface não funcional ou não integrada com a API. (0 pt)
Pipeline de CI/CD (.gitlab-ci.yml) Pipeline completo com estágios de lint e testes automatizados passando na main, com chaves em variáveis mascaradas. (3,0 pts) CI/CD configurado mas incompleto (apenas 1 job básico) ou falhando com frequência. (2,0 pts) Sem CI/CD ou com chaves de API commitadas no código aberto. (0 pt)
Gestão Ágil e Boards no GitLab Boards organizados, issues detalhadas com estimativas atualizadas e fechamento formal da Milestone 3. (1,5 pt) Boards pouco atualizados ou issues fechadas em lote no final do prazo sem histórico ágil. (1,0 pt) Sem uso de boards ou issues vazias. (0 pt)
Rastreabilidade de Autoria e MRs Todos os membros com contribuições homogêneas no Git, com branch protection e Merge Requests revisados por pares. (2,0 pts) Concentração de mais de 70% dos commits em um único integrante ou merges sem revisão. (1,2 pt) Membros sem contribuição registrada no repositório. (0 pt)
Dica💡 Dica do Professor

Não deixem a configuração do .gitlab-ci.yml para a última semana. Configurem o pipeline logo no início do Módulo 3 para que ele ajude a equipe a identificar quebras de código a cada Merge Request!

De volta ao topo