Relatório de Avaliação - L03

Gerado em 26/08/2026 10:32:57

📊 Resumo de Entregas

Aluno	Q1	Q2	Q3	Q4	Q5	Total
ARTHUR BALTAR ELE.	✅	❌	❌	❌	❌	1/5
CARLOS MATHEUS	✅	✅	✅	✅	✅	5/5
ANDERSON DE LIMA.	❌	❌	❌	❌	❌	0/5
ANDRÉ GUILHERME R.	❌	❌	❌	❌	❌	0/5
BIANCA DA SILVA B.	❌	❌	❌	❌	❌	0/5
CARLOS EDUARDO	❌	❌	❌	❌	❌	0/5
CARLOS ESTEVÃO	❌	❌	❌	❌	❌	0/5
DANYEL MARTINS ZI.	❌	❌	❌	❌	❌	0/5
DAVI JOSÉ DO NASC.	❌	❌	❌	❌	❌	0/5
EMMANUEL DINIZ CH.	❌	❌	❌	❌	❌	0/5
EVELYZE PINHEIRO.	❌	❌	❌	❌	❌	0/5
FILLIPE TOMAZ CAR.	❌	❌	❌	❌	❌	0/5
FLÁVIO CORCINI DE.	❌	❌	❌	❌	❌	0/5
GABRIEL ALVARENGA.	❌	❌	❌	❌	❌	0/5
GABRIEL CAMPOS MA.	❌	❌	❌	❌	❌	0/5
GABRIEL PINHEIRO.	❌	❌	❌	❌	❌	0/5
GABRIEL SILVA GON.	❌	❌	❌	❌	❌	0/5
GABRYEL FERREIRA.	❌	❌	❌	❌	❌	0/5
HUGO VICENTE COEL.	❌	❌	❌	❌	❌	0/5
ISAÍAS CÉSAR SAMP.	❌	❌	❌	❌	❌	0/5
JOÃO CARLOS FERRE.	❌	❌	❌	❌	❌	0/5
JOÃO VÍTOR MARQUE.	❌	❌	❌	❌	❌	0/5
LETICIA MAURICIO.	❌	❌	❌	❌	❌	0/5
MATEUS SILVA LOPE.	❌	❌	❌	❌	❌	0/5
MATHEUS MATOS BOT.	❌	❌	❌	❌	❌	0/5
NATHAN BALMANT DE.	❌	❌	❌	❌	❌	0/5
PEDRO CLAUDIO JAC.	❌	❌	❌	❌	❌	0/5
RAFAEL DE OLIVEIR.	❌	❌	❌	❌	❌	0/5
RONALD RODRIGUES.	❌	❌	❌	❌	❌	0/5
SABRINA EVELYN SI.	❌	❌	❌	❌	❌	0/5
SAMUEL BRUM LELLE.	❌	❌	❌	❌	❌	0/5
SAULO DIAS DE OLI.	❌	❌	❌	❌	❌	0/5
THALLES VINÍCIUS.	❌	❌	❌	❌	❌	0/5
VICTOR GABRIEL MA.	❌	❌	❌	❌	❌	0/5
VICTOR OTAVIO SOU.	❌	❌	❌	❌	❌	0/5
VITOR EMANUEL VEN.	❌	❌	❌	❌	❌	0/5
VITOR OLIVEIRA CA.	❌	❌	❌	❌	❌	0/5
WELLINGTON JHONNEY	❌	❌	❌	❌	❌	0/5

🟡 ARTHUR BALTAR ELE. (Matrícula: 20223004240, Login: @ArchieBaltar)

Progresso: 1 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 1: A Bússola do Projeto (Project Charter)

Sem um Project Charter, a equipe fica sem “bússola” — não existe um documento formal pra consultar quando surge dúvida sobre o que fazer, o que não fazer, ou quem decide. Isso gera vários riscos concretos ao longo do período de desenvolvimento:

Sem Requisitos de Alto Nível e Restrições documentadas, qualquer pedido novo vira “mais uma coisinha” que a equipe aceita sem perceber que está estourando prazo e esforço.

Se os objetivos não foram definidos, cada integrante do time pode ter uma ideia diferente do que é “sucesso” pro projeto.

Sem Business Case e escopo definidos no Charter, as Issues do repositório tendem a nascer vagas também.

O Charter é o que dá autoridade ao Gerente de Projetos pra aplicar recursos e tomar decisões.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

❌ Questões Faltantes

Questão 2: O Dilema dos Repositórios
Questão 3: A Armadilha da Issue Épica e o WIP
Questão 4: Escopo vs. Tempo (Issues e Milestones)
Questão 5: A Mágica do CI/CD

🟢 CARLOS MATHEUS (Matrícula: 20233007620, Login: @Carlos_Matheus_2005)

Progresso: 5 questões respondidas. Avaliação Geral: [ ] Excelente (10) | [ ] Bom (7) | [ ] Insuficiente (0)

📝 Questão 5: A Mágica do CI/CD

A Integração Contínua (CI) garante que, a cada commit, um robô cria um ambiente limpo, compila o sistema, baixa as dependências (como os pacotes Python no requirements.txt) e roda testes automatizados. Se algo falhar, o Merge, que é a junção de um código de uma ramificação (branch) em outra, é bloqueado. Com isso, a Entrega Contínua (CD) entra logo após: se os testes passam, o robô empacota o software e o implanta automaticamente na nuvem, colocando-o em produção em segundos.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 4: Escopo vs. Tempo (Issues e Milestones)

As Issues gerenciam e fracionam o Escopo. No projeto, elas descrevem o que precisa ser feito, quem é o responsável, a prioridade e a estimativa de esforço.

Os Milestones gerenciam o Tempo, eles são a representação técnica de uma Sprint, que é um marco temporal fixo (geralmente de duas semanas), que agrupa um pacote de issues sobre um objetivo estratégico. Assim, funcionando como marcos/eventos-chave no projeto e servindo como verificação para avaliar o progresso e tomar decisões.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 3: A Armadilha da Issue Épica e o WIP

A Issue “Fazer todo o backend do sistema de IA” é considerado tanto uma aberração gerencial quanto um Épico porque, no geral, não apresenta um critério de aceitação, não consegue ser testada objetivamente e ela levaria mais de 2 dias de código para ser uma tarefa completada. Por isso, ela precisa ser fatiada para apresentar uma melhor forma de realizar o serviço, garantindo que pequenas funções do projeto ao todo sejam realizadas aos poucos. Com isso, a equipe terá as suas várias issues para completarem e é necessário que as coisas sejam feitas de forma organizada, passando para outra issue apenas quando a iniciada anteriormente for completada, causando, assim, uma redução da troca de contexto e evitando que a produtividade seja destruída (Não podemos ter 10 tarefas in progress em um equipe de 3 pessoas, pois isso gera dispersão, aumento do tempo de entrega).

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 2: O Dilema dos Repositórios

A principal vantagem do Monorepo é que ele centraliza o código-fonte do back-end, a interface, os testes, a documentação e os scripts em um único repositório, o que acaba facilitando a rastreabilidade transversal, pois é possível saber exatamente qual issue gerou determinada alteração em todo o sistema. Diferentemente da abordagem Polyrepo, que é a mais requerida por corporações gigantes, já que ela apresenta múltiplos repositórios e uma independência total de cada projeto ou microsserviço, mas isso acaba gerando uma sobrecarga maior de gestão e, como consequência, é necessário um trabalho mais aperfeiçoado e uma equipe maior para conseguir extrair com excelência esse método. Por isso, projetos com equipes enxutas buscam utilizar-se da Monorepo.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

📝 Questão 1: A Bússola do Projeto (Project Charter)

Não ter definido o Project Charter desde o início pode gerar diversas complicações ao longo de todo o projeto, principalmente com os programadores desenvolvendo todo o esquema “às cegas”. Entre elas, podemos dizer que a comunicação entre os desejos do cliente e o que a equipe está realizando podem não ter ficado muito bem esclarecidas e, com isso, o projeto pode acabar tomando rumos indesejáveis para o cliente (já que não existe um documento que apresente a proposta e o que deve ser feito, basicamente a própria equipe não entende a existência do projeto); também, a equipe não terá uma boa noção do que o sistema deve fazer e os custos que não podem ser ultrapassados, podendo gerar transtornos financeiros para o andamento do projeto (caso acabem buscando por rotas mais caras para a realização de determinada tarefa) e, consequentemente, para o cliente; além disso, os desenvolvedores não possuem uma métrica para saberem se os testes foram positivos ou negativos, já que não é apresentado um critério de sucesso.

Correção: [ ] Boa | [ ] Parcial | [ ] Ruim

🔴 Alunos que não entregaram (0 questões)

ANDERSON DE LIMA. (@limaanderson)
ANDRÉ GUILHERME R. (@andreguilherme)
BIANCA DA SILVA B. (@biancaB)
CARLOS EDUARDO (@CarlosEduardo)
CARLOS ESTEVÃO (@carlos-e-araujo)
DANYEL MARTINS ZI. (@DanyelZini)
DAVI JOSÉ DO NASC. (@DaviJ)
EMMANUEL DINIZ CH. (@EmmanuelD1)
EVELYZE PINHEIRO. (@evelyze)
FILLIPE TOMAZ CAR. (@Fillipe)
FLÁVIO CORCINI DE. (@FlavioCorcini)
GABRIEL ALVARENGA. (@gLx)
GABRIEL CAMPOS MA. (@gabrielcm)
GABRIEL PINHEIRO. (@gabriel_pinheiro067)
GABRIEL SILVA GON. (@mewndigo)
GABRYEL FERREIRA. (@Gabryel)
HUGO VICENTE COEL. (@hugovicente)
ISAÍAS CÉSAR SAMP. (@isaiascsl)
JOÃO CARLOS FERRE. (@joaocarlos.fm)
JOÃO VÍTOR MARQUE. (@joao)
LETICIA MAURICIO. (@leticia)
MATEUS SILVA LOPE. (@MateusLopes15)
MATHEUS MATOS BOT. (@matheusmb10)
NATHAN BALMANT DE. (@NathanBalmant)
PEDRO CLAUDIO JAC. (@pejacome)
RAFAEL DE OLIVEIR. (—)
RONALD RODRIGUES. (@ronaldrodriguesvitorino)
SABRINA EVELYN SI. (@SabEvelyn)
SAMUEL BRUM LELLE. (@Sam)
SAULO DIAS DE OLI. (@Saulo)
THALLES VINÍCIUS. (@Thalles_cruz)
VICTOR GABRIEL MA. (@vicmagione)
VICTOR OTAVIO SOU. (@vsouza)
VITOR EMANUEL VEN. (@VitorEmanuelVS)
VITOR OLIVEIRA CA. (@Vitor)
WELLINGTON JHONNEY (—)