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

28/09/2026

Importante📅 Informações da Entrega
  • Prazo 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 uma interface funcional (Telegram, Discord, Web ou Streamlit) operando de ponta a ponta no fluxo priorizado do MVP. A equipe pode ampliar a cobertura de conteúdos em incrementos posteriores, conforme tempo, risco e evidências de uso.

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 verifica regressões de comportamento do prompt a cada Merge Request?
  4. Colaboração Rastreável: A equipe consegue explicar a distribuição de trabalho considerando complexidade, disponibilidade, revisão e colaboração, com evidências além da contagem 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
│   └── RISCOS_E_COMUNICACAO.md         # Riscos atualizados e acompanhamento
├── CHANGELOG.md (ou ADR/seção equivalente) # Mudanças relevantes rastreáveis
├── 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) para o fluxo priorizado do MVP.
    • O usuário deve conseguir iniciar a sessão de mentoria com o recorte de entrada e conteúdo definido pela equipe; enunciados ou links de problemas são exemplos possíveis.
  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).
    • Validem o prompt como teste de regressão: cada caso define o comportamento esperado e verifica que uma alteração não o descaracterizou. Incluam ao menos um pedido de solução completa e o comportamento esperado definido pela equipe.
    • Quando mocks ou fixtures forem adequados, o pipeline não deve fazer chamadas reais pagas à LLM. Isolem as integrações externas e usem respostas controladas para tornar os testes reproduzíveis.
  3. Uso Correto de Segredos (CI/CD Variables):
    • As chaves de API da LLM nunca devem estar no código-fonte nem nos testes, fixtures, logs ou artefatos. Quando necessárias fora da suíte automatizada, usem GitLab CI/CD Settings -> Variables (marcadas como Masked e Protected).
  4. Selo de Pipeline Passando:
    • Antes de integrar uma entrega relevante, verifiquem que os jobs aplicáveis estão passando. Se a equipe usar uma branch padrão protegida, mantenham nela o último pipeline aplicável verde ou documentem impedimentos e a ação corretiva.

🎯 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.
    • A equipe deve registrar mudanças significativas por meio de feature branches e Merge Requests quando compatível com seu fluxo. Os MRs devem descrever a entrega e vincular issues ou evidências equivalentes; não é necessária uma issue para cada ajuste trivial.
  3. Distribuição e colaboração:
    • Avaliem a distribuição com issues, MRs e revisões, ADRs, testes, demonstrações e retrospectivas. O gráfico de contribuidores é apenas um indício; considerem complexidade, disponibilidade comunicada e colaboração.
  4. Mudanças e riscos atualizados:
    • Para mudanças relevantes do MVP, registrem em CHANGELOG.md, ADR ou seção equivalente a mudança, motivo, impacto, responsável e vínculo para Issue/MR.
    • Atualizem RISCOS_E_COMUNICACAO.md com o estado, dono, gatilho, mitigação, contingência e data de revisão dos riscos que evoluíram durante a execução.

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

Critério Excelente (100%) Bom (70%) Insuficiente (0%)
Interface e Integração Funcional Bot/interface opera de ponta a ponta no fluxo priorizado, integra o Professor Agente e mantém o contexto da sessão de forma coerente. (3,5 pts) Interface funciona parcialmente, com limitações de integração, contexto ou tratamento de erros documentadas. (2,5 pts) Interface não funcional ou sem integração demonstrável. (0 pt)
Pipeline de CI/CD (.gitlab-ci.yml) Pipeline tem lint e testes automatizados, incluindo regressão de comportamento esperado do prompt; usa mocks/fixtures quando adequados e não expõe segredos. Jobs aplicáveis passam antes da integração. (3,0 pts) CI/CD configurado, mas com cobertura limitada de regressão, isolamento de LLM ou segurança de segredos. (2,0 pts) Sem CI/CD ou com segredo exposto no repositório, teste, fixture, log ou artefato. (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 e colaboração Mudanças significativas e riscos atualizados têm evidência controlada (Issue/MR, CHANGELOG, ADR ou equivalente), com conjunto consistente de revisão, decisões, testes e colaboração. (2,0 pts) Evidências parciais ou insuficientes para explicar mudanças, riscos, colaboração e distribuição do trabalho. (1,2 pt) Não há evidências suficientes de contribuição ou acompanhamento. (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