Data de Publicação

12/09/2026

Data de Modificação

04/09/2026

Relatório de Avaliação - L03

Gerado em 04/09/2026 08:44:18

📊 Resumo de Entregas

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

🟢 ANDERSON DE LIMA. (Matrícula: 20213005825, Login: @limaanderson)

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

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

O CI/CD remove totalmente o fator humano e a desculpa do ambiente local de desenvolvimento. Com a etapa de CI (Integração Contínua) configurada no arquivo .gitlab-ci.yml, toda vez que alguém der um commit, um robô na nuvem vai baixar o código, compilar e rodar os testes automaticamente. Se o código novo quebrar algo, o robô bloqueia o Merge Request na mesma hora, impedindo que o erro entre na branch principal (main). Caso os testes passem com 100% de sucesso, o CD (Entrega Contínua) pega esse pacote e joga direto para o servidor de produção em segundos.

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

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

De maneira prática, as Issues são usadas para mapear e fatiar o Escopo do projeto, detalhando o que será construído pela equipe (como os pacotes de trabalho de funcionalidades e correções de bugs). Já os Milestones são responsáveis por gerenciar o Tempo, funcionando de forma idêntica a uma Sprint, pois eles agrupam um conjunto dessas Issues sob um objetivo temporal com uma data final fixa para entrega.

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

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

Essa Issue é um “Épico” porque não possui critérios de aceitação claros e demoraria semanas para ser concluída, o que a torna uma aberração gerencial impossível de medir. Como regra, qualquer tarefa que leve mais de 2 ou 3 dias intensos de codificação precisa ser fatiada em incrementos menores e de valor claro, como “Tratar erro de limite de tokens da API”. Além disso, ter 10 issues na coluna “Doing” para 3 pessoas ignora totalmente os limites de WIP (Work in Progress), já que o ideal é terminar o que foi começado antes de puxar uma tarefa nova. Esse excesso de paralelismo força a equipe a ficar trocando de contexto o tempo todo (context switching), o que destrói a produtividade técnica.

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

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

A grande vantagem do Monorepo é centralizar absolutamente tudo em um único ambiente, unindo nosso código backend, interface, testes, configuração dos prompts e a documentação na Wiki. Para o nosso Assistente de IA, isso garante uma rastreabilidade transversal perfeita: com apenas um commit ou Merge Request (MR), a gente consegue alterar uma regra de negócio, ajustar o teste automatizado que valida essa regra e atualizar a documentação do projeto de forma atômica, tudo na mesma tacada.

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

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

Sem um Project Charter bem definido, o maior risco é a equipe focar apenas no código e construir um sistema tecnicamente brilhante, mas que falha em resolver o problema real do usuário final, desperdiçando todo o esforço. A maioria dos projetos de software não fracassa por falta de tecnologia, mas sim por causa de escopos mal definidos, expectativas irreais e falhas graves de comunicação. Na comunicação com o professor (ou cliente), isso vira um desastre: a gente pode acabar inventando moda e entregando uma interface cheia de firulas que não foram pedidas (o famoso Gold Plating), esquecendo a regra inegociável de que a IA deve atuar como um tutor socrático. Tudo isso gera um retrabalho enorme no fim do semestre porque os critérios de sucesso e os objetivos SMART nunca foram formalizados no início.

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

🟢 ANDRÉ GUILHERME R. (Matrícula: 20243000982, Login: @andreguilherme)

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

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

A parte do CI (continuous integration) trata da integração contínua, com testes automatizados que compilam e rodam o codigo e vem se o codigo comitado funciona nos casos de teste, se falhar, o merge é bloqueado, e esse teste é feito em um ambiente limpo

Ja o CD (continuous delivery) é a segunda parte desse processo, onde se o codigo passar por todos os testes ele é enviado direto para produção para os usuários usarem a nova feature ou correção do bug, tudo sendo orquestrado pelo .gitlab-ci-yml

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

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

Um milestone gerencia um pacote de issues que devem ser entregadas até certo dia, como por exemplo uma sprint semanal, ja uma issue é um problema ou parte do escopo que deve ser pronto

Issues gerenciam escopo e milestones fracionam o tempo

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

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

Uma issue épica tem uma chance mais grande de ninguem querer pegar e de quem pegar não conseguir fazer ela de forma utilizável e documentada, e ter 10 issues na aba doing significa que alguem está fazendo mais de 3 issues de uma vez o que leva ao problema de alguem ter feito algo mal feito ou estar fazendo issues sem ter a documentação apropriada, o limite de WIP de uma equipe de 3 pessoas tinha que ser 3 tasks no doing porque fazer 2 issues ao mesmo tempo não é recomendavel

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

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

A principal vantagem é a organização melhor, sendo possivel relacionar partes da documentação com algo que está dentro do próprio repositorio, e na rastreabilidade os commits de cada parte são pra todo o reposítorio então rastrear a quantidade de coisas que alguem fez se torna mais fácil, além de ter uma cópia do projeto em cada máquina para manter a sincronia em todas as partes do projeto (back end front end documentação etc)

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

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

Caso o projeto não tenha um project charter, ao longo das semanas pode não ser desenvolvido alguma coisa que o cliente pediu, o escopo pode aumentar de forma drástica, os objetivos podem alterar totalmente do que o cliente pediu e o projeto pode se tornar impossível de trabalhar por não ter uma documentação apropriada, tudo por não ter um project charter definindo o projeto corretamente

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

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

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

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

No CI/CD, a cada commit, uma automação cria um ambiente limpo do zero, instala as dependências do projeto e roda os testes. Se detectar alguma falha, o merge é bloqueado, e o código defeituoso não chega a interferir na main (que é a parte que funciona).

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

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

Issues gerenciam o Escopo do projeto: cada uma delas é um pedaço de trabalho com início, meio e fim definidos, e testável.

Milestones gerenciam o Tempo: elas agrupam issues em sprints que devem ser realizadas dentro de um prazo.

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

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

Ela é um “épico” porque é muito genérica, vaga e, portanto, demorada de ser executada, e por isso deve ser fatiada em partes menores.

Já ter várias issues (dez) em “doing” para uma equipe pequena, de três pessoas, implica falta de foco, muita alternação entre tarefas e, por isso, é contraprodutivo.

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

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

A principal vantagem é que centraliza todo o projeto num único lugar, o que facilita o trabalho para equipes pequenas, melhora a rastreabilidade e dá pra ter uma visão macro, com o histórico de commits todo ali. Separar só faz sentido pra equipes grandes, que dispõem de várias cabeças focadas em várias tarefas diferentes.

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

📝 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

🟡 CARLOS ESTEVÃO (Matrícula: 20243001658, Login: @carlos-e-araujo)

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

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

A principal vantagem é a centralização do projeto em uma única fonte, o que facilita o gerenciamento de dependências e facilita a colaboração entre os membros da equipe. O monorepo também permite que a documentação, backend e front sejam vinculados a um único commit, branch ou merge, garantindo um histórico atômico, claro e auditável.

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

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

O maior risco é o desperdício de tempo e esforço com o escopo fantasma, em que cada membro da equipe programa o que acha certo sem uma meta em comum, gerando atrasos e retrabalhos. Na comunicação com o cliente ou professor, isso iria gerar um desalinhamento nas expectativas, seja entregando algo que não era o que o cliente desejava, seja o cliente solicitando algo fora do escopo original.

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

❌ Questões Faltantes

  • 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

🟢 DANYEL MARTINS ZI. (Matrícula: 20243014020, Login: @DanyelZini)

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

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

O pipeline é uma automatização que permite interceptar o código defeituoso, aquele como falado no enunciado, que somente roda em uma máquina, ele cria de forma automática um ambiente isolado para testar o código e validar se realmente funciona no sistema principal.

A principal vantagem de bloquear um código defeituoso antes de chegar no servido de produção é garantir a estabilidade do sistema que está no ar, impedindo bugs ou quebra de dependências que afetariam os usuários.

—

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

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

O Issue é o Escopo, já que é nele que descreve o trabalho técnico a ser feito no código e repassado a um desenvolvedor.

O Milestone é o Tempo, onde define o prazo final de entrega das Issues e que seja permitido a entrega do projeto na data prevista.

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

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

A tarefa é considerada Épico porque ela é ampla demais, complexa e engloba múltiplos componentes que exigem um conhecimento aprofundado e funcionalidades já existentes, em um ecossistema backend é composto por diversos componentes, como a definição de rotas, banco usados, integração com APIs externas, são tantos componentes que é necessário uma organização de tasks para cada membro.

O conceito WIP define um número máximo de itens de trabalho que podem esta ativos em um determinado estágio de tempo, ter 10 issues em “Doing” simultaneamente para uma equipe de três pessoas demonstra uma falta de organização, visando que cada membro esta tentando focar em 3 ou 4 tarefas diferentes ao mesmo tempo, podendo trazer gargalos no desenvolvimento e um falso sentimento de progresso.

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

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

Utilizando o Monorepo para o desenvolvimento do projeto de assistente, é possível trazer diversos benefícios, desde que tudo esta conectado e organizado em apenas um repositório, permitindo com que a organização seja seu ponto principal. Suas principais vantagens vem da simplicidade de integração do sistema e testes, já que não seria necessário a integração de múltiplos repositórios ao projeto, além precisar gerenciar somente um versionamento, eliminado dependências externas e complexas, facilitando testes como um todo.

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

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

Sem alguém para garantir a estrutura do projeto e da equipe pode trazer diversos prejuízosos no desenvolvimento do projeto, inicialmente poderia ocorrer um desvio de escopo, na qual os programadores poderiam criar funcionalidades inúteis ou complexas demais para algo banal, além de não desenvolver funcionalidades fundamentais para o projeto. Também, poderia haver um gargalo no desenvolvimento do projeto, já que não haveria a definição de tarefas para os membros da equipe, onde poderia gerar uma incompatibilidade com as funcionalidades e que seriam descobertas tarde demais.

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

🟢 DAVI JOSÉ DO NASC. (Matrícula: 20243001685, Login: @DaviJ)

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

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

O sistema de Pipeline de CI/CD (Integração e Entrega Contínuas) do gitlab consegue fazer uma espécie de verificação no deploy, garantindo que o que foi enviado realmente funciona, dessa forma se algum programador enviar uma funcionalidade que não funciona nesse ambiente ele nem mesmo autoriza o deploy e impede esse código falho de contaminar o ambiente final das entregas.

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

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

Issue gerencia o escopo, ela define o que deverá ser feito e como deve ser feito, pode ser desde uma funcionalidade nova a ser implementada até uma atividade de revisão. As milestones gerenciam o tempo, elas definem o prazo em que algo deve ser entregue.

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

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

Uma Issue como “Fazer todo o backend do Assistente de IA” acaba guardando uma quantidade enorme de outras Issues menores, o que pode ser um problema pois apesar de parecer como só um problema ela esconde dezenas de outros problemas que por si só poderiam ser uma issue separada com seus próprios prazos e responsáveis. O conceito de WIP indica a quantidade de funcionalidades que uma mesma pessoa pode estar trabalhando ao mesmo tempo em um projeto, quanto maior é esse valor maior a chance do projeto se desorganizar e uma funcionalidade ser iniciada e não finalizada a tempo por excesso de trabalho para o mesmo colaborador.

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

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

O Monorepo pode não ser recomendado para projetos grandes ou com vários segmentos diferentes, mas no caso do nosso projeto que é algo menor e mais direto ele performa bem. Por reunir a documentação, o front-end e o back-end em um só lugar fica mais fácil de averiguar como o projeto está se desenvolvendo com o tempo e o que cada colaborador está entregando, sem risco de uma pessoa trabalhar em algo e não ser “vista”.

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

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

O Project Charter serve como um guia para o projeto, sem ele fica difícil de se localizar e entender o quanto tempo pode ser investido em uma funcionalidade e as influencias delas no futuro do projeto, assim uma função pode ter que sofrer retrabalho e ser readaptada ou completamente reformulada por falta de entendimento. O Project Charter é uma forma efetiva de aumentar as chances do cliente e programador estarem na mesma pagina em relação ao projeto.

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

🟢 EMMANUEL DINIZ CH. (Matrícula: 20213005843, Login: @EmmanuelD1)

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

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

No CI, a cada commit o GitLab baixa o código, compila e executa os testes. Se algo falhar, o merge é bloqueado. Quando tudo passa, o CD pode empacotar e publicar a aplicação em produção automaticamente. Assim, o código não depende apenas de “funcionar na máquina” de quem desenvolveu.

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

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

As Issues gerenciam o escopo, pois representam as tarefas ou entregas que precisam ser feitas. As Milestones gerenciam o tempo, agrupando Issues em uma etapa com prazo definido, funcionando como um Sprint.

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

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

“Fazer todo o backend” é um Épico porque é grande demais, não possui critérios de aceitação claros e provavelmente levaria vários dias. O correto é dividir em Issues menores, como criar um endpoint ou tratar um erro da API.

Ter dez Issues em “Doing” para três pessoas também é errado. O limite de WIP evita muitas tarefas em andamento, força a equipe a terminar o que começou e reduz a troca de contexto.

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

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

No Monorepo, código, interface, testes, documentação e prompts ficam centralizados. Isso é melhor para uma equipe pequena, pois reduz a gestão de vários repositórios e pipelines. A principal vantagem é a rastreabilidade transversal: uma única Merge Request pode atualizar a lógica, os testes e a Wiki de forma atômica.

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

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

No meu estágio, uma migração de relatório do Power BI para novas fontes de dados é um projeto, pois tem objetivo, prazo e entrega final. Já acompanhar atualizações de jobs, corrigir falhas e manter relatórios funcionando são operações, porque são atividades contínuas. Projeto cria ou transforma algo; operação mantém o que já existe.

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

🟢 EVELYZE PINHEIRO. (Matrícula: 20213012374, Login: @evelyze)

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 é bloqueado. 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. Para que o GitLab assuma esse papel, utilizamos o arquivo .gitlab-ci.yml.

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

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

Uma Issue representa uma unidade de trabalho: uma funcionalidade, um bug, uma tarefa técnica, uma melhoria. É onde descrevemos o que precisa ser feito, com detalhes, critérios de aceite, discussão, checklist, responsável etc. Na prática, o conjunto de todas as Issues abertas + fechadas do projeto é o escopo do projeto. Se uma funcionalidade não virou Issue, ela formalmente não existe pro projeto, e é por isso que, voltando à conversa sobre o Project Charter, é importante que todo escopo combinado com o cliente/professor seja traduzido em Issues.

Um Milestone é um marco temporal, geralmente vinculado a uma data ou período (ex: “Sprint 1”, “Entrega Parcial 1”, “Semana 5-6”), que agrupa um conjunto de Issues que devem ser concluídas até aquele momento. O Milestone não descreve trabalho, ele organiza issues no calendário. Sozinho, um Milestone é vazio; ele só ganha sentido quando se associa Issues a ele.

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

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

Uma issue bem escrita precisa ser pequena, testável e estimável, normalmente algo que uma pessoa consegue concluir em algumas horas ou 1-2 dias. Por isso isso é chamado de Épico: um agrupamento grande de trabalho que precisa ser fatiado (decomposto) em issues menores e independentes.

10 issues no Doing com 3 pessoas é um erro grave, pois viola diretamente o conceito de limite de WIP (work in progress). Com 3 pessoas, o máximo teoricamente produtivo de itens em progresso simultaneamente é 3, uma por pessoa. Ter 10 no Doing significa uma de duas coisas:

  • As pessoas estão fazendo multitarefas excessiva, pulando entre várias tarefas sem terminar nenhuma, o que na prática é mais lento que fazer uma de cada vez, por causa do custo de troca de contexto.
  • Ou várias issues foram movidas pra “Doing” e abandonadas, sem ninguém realmente trabalhando nelas, o que quebra a própria função do quadro Kanban, que é dar visibilidade real do que está de fato em andamento.

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

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

Como documentação, front-end e back-end vivem no mesmo repositório, uma única mudança que afeta múltiplas partes do sistema pode (e deve) ser feita em um único commit ou merge request.

A rastreabilidade está relacionada a todo histórico de commits ficando em uma linha de tempo só, é um único git log. Além disso, um merge request/commit conta a história completa. Em um merge request, uma feature exige mudança no backend, ajuste no front e atualização na doc, um único Merge Request pode conter as três coisas vinculadas. Tanto código quanto documentação evoluem junto, versionando junto.

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

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

Sem objetivos e escopo documentados, qualquer pedido novo do cliente vira mais uma funcionalidade que a equipe aceita sem perceber o acúmulo. Depois de algumas semanas, o time está trabalhando o dobro do previsto sem prazo ou orçamento extra, porque nunca houve uma linha de base pra comparar o que está dentro ou fora do combinado.

Como exemplos do que pode dar errado na comunicação com o cliente/professor está a entrega de um sistema de cadastro completo para o professor, mas ele só queria um protótipo de tela. O cliente pode pedir mais um campo no formulário, mas isso exigiria reestruturar o banco de dados e aumento do prazo de entrega. O cliente pode ter definido que o prazo de entrega é a semana 8, mas a equipe pode ter entendido que era pra semana 10, sem data formal no Charter, ambos teriam razão.

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

🟠 GABRIEL ALVARENGA. (Matrícula: 20243001694, Login: @gLx)

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

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

quando criamos um ambiente neutro na nuvem, sempre que alguém enviar um codigo, o sistema roda uma serie de testes (Ci) nesse ambiente, e se tiver erro, o pipeline bloqueia a integração

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

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

issues gerenciam escopo, pois representam tarefas, funcionalidades, etc. E os milestones gerenciam o tempo para cada atividade, como sprints com data de entrega para realizar as Issues mais urgentes daquele momento.

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

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

a nivel de organizacao e gerenciamento do codigo, monorepo eh muito melhor, e a rastreabilidade pode ser entregue com um unico commit (ou merge request)

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

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

sem um project charter é um perigo, porque se faltar alinhar os objetivos do projeto e o escopo, o cliente ou o professor pode mudar de ideia toda semana pedindo funcionalidades novas

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

❌ Questões Faltantes

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

🟢 GABRIEL CAMPOS MA. (Matrícula: 20243008185, Login: @gabrielcm)

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

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

O Pipeline de CI/CD serve como forma de automatizar e otimizar o desenvolvimento de software, realizando testes automáticos para não permitir código defeituoso para evitar uma entrega defeituosa, dessa forma, permitindo uma integração e entrega contínua do software.

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

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

A diferença entre eles está como cada um representa uma parte do projeto. Os issues, que gerenciam o escopo, são apenas tarefas individuas realizadas durante o desenvolvimento do projeto (implementação de funcionalidades, melhorias e correção de bugs), enquanto as milestones, que gerenciam o tempo, são marcos temporais e os objetivos das entregas.

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

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

É considerado “Épico” uma issue com esse título, pois é necessário separar as partes principais do backend de uma aplicação, ao fazer uma issue que abrange várias camadas em apenas uma, perde-se a referência das partes importantes e detalhes técnicos.

Ter 10 issues para uma equipe de 3 pessoa fere o conceito/procedimneto de limites de WIP, em que, existe um número limite de issues a serem resolvidos ao mesmo tempo. O que pode causa sobrecarregamento das pessoas que trabalham na equipe

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

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

Utilizando a abordagem do Monorepo, não precisa-se ficar atualizando três repositórios diferentes para cada versão nova. Ao utilizar apenas um repositório para guardar as três partes do projeto, ao atualizar uma das partes,é possível atualizar a nova versão do projeto de uma só vez.

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

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

Ao não formalizar os objetivos logo no início do projeto, ocorre-se o risco de cada equipe escolher aleatoriamente um objetivo e segui-lo, porém, com o decorrer do tempo, essa funcionalidade pode não estar alinhada com o desejo do cliente, por problema de design e entre outras coisas, o que causaria retrabalho durante o projeto

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

🟢 GABRIEL PINHEIRO. (Matrícula: 20243000884, Login: @gabriel_pinheiro067)

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

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

O uso do Pipeline CI/CD no GitLab acaba com tais desculpas pois, ao tentar dar Merge com seu código e o código que está salvo e funcionando dentro dele, o sistema primeiro realiza uma bateria de testes definidos pela equipe anteriormente para ver se o que está sendo implantado na nova versão é aceitável. Caso o sistema teste e encontre problemas, ele bloqueia a realização do Merge, evitando que o erro quebre o sistema já funcional. Agora, quando o sistema realiza os testes e passa em todos, a nova versão é atualizada diretamente na linha de produção principal garantindo maior estabilidade em todo o desenvolvimento.

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

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

Issue: Encarregada de gerenciar o escopo do projeto, ou seja, o que está e será feito ao longo do desenvolvimento do sistema, separando cada tarefa em pequenos blocos que partirão do estado de aberto até o estado de concluído.

Milestone: Encarregado de gerenciar o tempo do projeto, ou seja, define em quanto tempo cada parte do sistema dividido em pacotes de Issues deve estar pronto, organizando a linha de produção com datas e tempos limites.

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

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

Essa Issue é considerada épica, pois esta é mais um objetivo final do que uma tarefa, visto que realizar todo o backend é algo que demoraria semanas e engloba diversas tarefas menores, que facilmente poderiam ser divididas a fim de permitir uma maior organização do que está sendo feito. Seguindo o mesmo princípio, ter 10 Issues ou mais categorizadas com “Doing” em um projeto que envolve 3 pessoas fere diretamente o conceito de WIP (Work in Progress), que restringe quantas tarefas podem ser realizadas ao mesmo tempo. Como o Board Kanban é usado justamente para organizar o que está em progresso neste exato momento no meio do projeto, logo 3 pessoas conseguiriam, no máximo, progredir com cerca de 3 tarefas em um mesmo instante, o que força cada tarefa que está sendo feita a ser terminada obrigatoriamente antes de partir para outra Issue, melhorando, assim, a produtividade técnica ao evitar trocas constantes de contexto.

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

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

A escolha do Monorepo para o desenvolvimento do projeto de Assistente de IA se deve, principalmente, pelo tamanho pequeno da equipe (3 ou 4 pessoas), onde apenas uma ou duas pessoas no máximo são encarregadas de realizarem a gestão de toda a organização do projeto o que, usando este modelo de repositório, fica melhor visto que sua principal vantagem é a rastreabilidade transversal, ou seja, apenas um único commit ou MR é necessário para atualizar todo o projeto, indo desde sua documentação até o código em si de forma atômica. Tal modelo permite que o projeto fique totalmente sincronizado e que o gestor tenha melhor entendimento do que está sendo modificado e com qual intuito tal ação foi feita.

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

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

Os maiores riscos de uma equipe entrar em um projeto sem um Project Charter é que todo o desenvolvimento está sujeito a ser realizado baseando-se em achismo por nada do projeto ter sido explicado de forma clara, com escopo bem definido e requisitos documentados, tornando todo o projeto em uma única Issue Épica sem divisões de tarefas e objetivos. Um exemplo da falta que o Project Charter faz seria como se no projeto de Assistente de IA não fosse passado mais nenhuma informação sobre como ela deve atuar, permitindo que a equipe desenvolva uma IA que entregue diretamente a resposta do problema e não meios de auxiliar o aluno a chegar na resposta por ele mesmo como foi idealizado inicialmente. Assim, toda a comunicação entre o cliente e equipe de desenvolvimento fica completamente rasa e carente de informações cruciais, correndo o risco do produto final possuir diversas incoerências com seu objetivo idealizado e também permite ao cliente exigir diversas funções nunca antes comentadas na idealização inicial pela carência de uma base estrutural.

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

🟢 GABRYEL FERREIRA. (Matrícula: 20243004954, Login: @Gabryel)

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

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

Basicamente o CI(Integração) faz com que a cada commit, um robô baixa o código, compila e roda testes. Se falhar o merge é bloqueado, se passar nos testes e debugs o CD(Entrega) sobre para a produção fazendo o merge.

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

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

Issue é uma unidade de trabalho enquanto Milestone é um conjunto de trabalhos para atingir uma meta ou um prazo. Dito isso, a issue gerencia o escopo e Milestone o tempo.

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

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

Essa Issue é considerada um “Épico” pois por se tratar de uma operação muito grande e complexa pode acabar gerando erros no futuro em um desenvolvimento de um projeto. Por exemplo se uma regra de négocio for alterada, se uma API parar de funcionar. Esse card também pode travar o desenvolvimento de uma funcionalidade já que o card contempla tudo e não é possível saber o quão completo ele está ou não, o mesmo aconteceria com um card “faça todo o front end”.

Sobre a quantidade excessiva de cards para a quantidade de membros da equipe tem haver com a troca de contexto que pode haver entre as operações tipo o dev esta fazendo um card de backend e sem terminar pula para um do front, essa mudança podem ser apenas de funcionalidades mas da mesma área, assim há uma perca de produtividade e da linha de raciocínio. WIP - Work in Progress é limitar a quantidade de coisas que a equipe começa sem terminar.

“Pare de começar e comece a terminar”

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

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

A escolha do Monorepo é uma escolha de excelência para projetos pequenos e de equipe enxuta pois centraliza tudo em apenas 1 repositório permitindo fazer alterações e tudo ser incluído no mesmo commit representando aquele estado do sistema de maneira consistente. Não precisamos ficar administrando diversos repositórios facilitando o acompanhamento do desenvolvimento do projeto o que foi mexido primeiro o que foi resolvido e etc.

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

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

“O Project Charter é o documento oficial que formaliza a iniciativa e concede autoridade ao Gerente de Projetos.”

Erros entre a equipe de desenvolvimento e falta de entendimento entre cliente e prestadora de serviços é bem provável sem esse documento. Alguns, seriam desperdício de recursos, desalinhamento de equipe, cope creep, problemas de orçamento, má organização, entrega e afins. E mais um erro fatal poderia ser a falta de comunicação com o cliente e ser desenvolvido algo que não atende as necessidades do cliente.

Um último ponto poderia ser atitudes de má fé na relação cliente/empresa.

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

🟢 ISAÍAS CÉSAR SAMP. (Matrícula: 20243006289, Login: @isaiascsl)

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

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

A configuração de um Pipeline de CI/CD ajuda à uniformidade da aplicação no servidor de produção ao fazer uma série de verificações de segurança e integração quando um colaborador envia suas modificações para o servidor remoto através de um git push.

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

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

As issues são tarefas que representam exatamente o que deve ser realizado por um colaborador. Por isso, issues gerenciam escopo por conter descrições dos problemas a ser resolvidos ao detalhar tarefa e colaborador. Milestones são como checkpoints no projeto em que, definidos por termpo, marcam conquistas e um fim de um etapa de um projeto.

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

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

Essa issue pode ser considerada um épico pois trata-se de um tarefa muito grande e pouco especificada. Backend faz parte da estrutura do projeto e não pode ser considerada uma task, as partições dess épico vão ser a task e devem ser bem especificadas. É um erro ter 10 issues em “Doing” ferem o conceito delimites de Work In Progress pois, nele, é delimitado um limite benéfico para o projeto e confortável para o colaborador que varia de 1x a 1.5x, ficando entre 3 e 4 tarefas por pessoa.

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

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

Monorepos para a organização do Projeto Integrador é uma vantagem por simplificar a gestão de dependências, as configurações compartilhadas e orquestração de containers. Se relaciona com a rastreabilidade ao permitir histórico linear integrado em um único lugar

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

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

Ao ser alocado em um projeto onde não há Project Charter e sem formalização clara dos objetivos, escopo inicial e critérios de sucesso, é bem capaz que o projeto que estarei desenvolvendo pode divergir do que o cliente queria. O correto seria definir claramente (por exemplo, usando a metologia smart) para assim ter um norte do que você está desenvolvendo para stakeholders e desenvolvedores caminhem no mesmo caminho buscando um mesmo objetivo para evitar retrabalhado e tempo desperdiçado

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

🟢 JOÃO VÍTOR MARQUE. (Matrícula: 20243003394, Login: @joao)

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

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

Com o Pipeline de CI/CD no GitLab, ele mesmo faz um teste com robô que depois de cada commit ele baixa, copila e faz os testes. Caso der erro, o merge acaba sendo bloqueado e o código com problema não é enviado, isso chamamos de integração contínua. Quando ele passa, o robô junta tudo e envia direto pro servidor que estiver com o projeto, e isso chamamos de entrega contínua. Por isso que essa desculpa agora não funciona mais.

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

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

A diferença entre as Inssues e Milestones é que, na issue temos a divisão em tarefas pra fazermos no nosso projeto. Assim com ela, gerenciamos o escopo do nosso projeto do chatbot. Já os milestones servem pra representar o tempo que queremos cumprir os objetivos, como entregar a primeira parte do chatbot falando “oi” até dia tal. Ou seja, com eles gerenciamos o tempo pra cada escopo ficar pronto.

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

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

Essa issue é épico pois ela tem um escopo grande, não é uma tarefa só e também não é bem definida. O certo é dividir ela em várias issues menores. Com isso, é mais fácil para que o trabalho seja desenvolvido e monitorado com mais organização, por isso, no kanban as issues são usadas para gerenciar o projeto.

O erro de ter 10 issues no Doing pra equipe de 3 pessoas representa um excesso do WIP. O WIP tem o limite que serve para restringir a quantidade de tarefas para ser feitas juntas. Se tiver muitas, os dev vão precisar ficar pulando de tarefa para tarefa toda hora, e com isso, vai diminuir o desempenho deles e vai ter mais dificuldades de completar as tarefas.

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

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

A vantagem de usarmos o Monorepo é que vamos conseguir deixar tudo centralizado em um único repositório, desde os códigos até a documentação final. Com isso vamos ter uma organização maior de nós da equipe e evita a sobrecarga de informação caso tivesse em vários repositórios diferentes.

Ele nos ajuda na rastreabilidade transversal, que significa que varias partes diferentes do nosso projeto vamos poder atualizar junto, ou seja, é mais fácil de nós acompanharmos o que foi alterado no projeto a cada mudança feita por um de nós dev.

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

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

Quando não temos o Project Charter no nosso desenvolvimento, como o ChatBot que vamos fazer nesse semestre, nós podemos ter muitos problemas, como embolar os objetivos sem decidir ao certo o que queremos. O aumento de funcionalidades do nada no projeto, sem já ter definido 100% as funcionalidades que vamos ter, sem essa definição, podemos ter retrabalho para mexer nas funcionalidades; problema nas visões do projeto, em que cada um de nós podemos ver de forma diferente de como executar; não sabermos definir ao certo qual resultado final queremos e, por fim, há grandes chances de não cumprirmos os prazos de entrega.

Como exemplo igual disse, pode ser o ChatBot: o professor primeiro pediu para fazermos ele para responder perguntas acadêmicas, e aí desenvolvemos o nosso projeto inteiro em cima disso. Porém umas 5 semanas depois, o professor disse que também queria que nele tivesse todo o histórico de conversas e também gerasse um relatório para analisar as dúvidas tiradas. E como essas funcionalidades não tinha sido formalizadas antes, no início, a equipe toda vai ter que fazer o retrabalho para implementar elas e, provavelmente vamos atrasar a entrega do projeto.

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

🟢 LETICIA MAURICIO. (Matrícula: 20243001649, Login: @leticia)

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

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

A configuração de um Pipeline de CI/CD testa e compila o código em um servidor remoto, um ambiente isolado, de modo que as ferramentas, versões, sistemas operacionais e outros são sempre os mesmos. Além disso, roda testes automatizados que impedem a atualização se algum teste falhar

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

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

Issues gerenciam e fracionam o tempo, enquanto milestones gerenciam o escopo. Uma milestone é um marco temporal fixo, como uma sprint, que agrupa um conjunto de issues para conclusão de um objetivo estratégico.

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

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

Se uma issue leva mais de 2 dias de código, provavelmente ela é um épico e precisa ser fatiada. Uma issue intitulada “Fazer todo o backend do Assistente de IA” com certeza leva mais de dois dias de código, leva semanas para ser concluída, por isso é considerada um épico e precisa ser dividida em issue menores, visto que uma issue tão geral quanto essa possui um prazo de conclusão longo, podendo gerar problemas de gerenciamento de tempo, sobretudo pelos fatores humanos como subestimar o trabalho que uma tarefa dá, não possui boas métricas de sucesso e é difícil de ser testada, sendo um pesadelo para a gestão do projeto.

O que contribui para o sucesso do método Kanban é justamente definir limites de WIP (Work in progress), pois esses limites obrigam a equipe a terminar o que já foi iniciado antes de iniciar novas issues, diminuindo a troca de contexto que é inimiga da produtividade. Se a equipe possui apenas três pessoas, não deveria ter 10 issues na coluna de doing, pois cada pessoa deveria realizar uma issue de cada vez.

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

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

Por se tratar de um projeto acadêmico para uma disciplina específica com uma equipe pequena e inexperiente, um Monorepo é mais adequado por ser mais simples e centralizar todo o projeto em um único lugar, de modo que é possível saber exatamente qual issue gerou qual alteração em todo o sistema, bem como atualizar e ajustar várias partes do projeto em um único commit, diminuindo a sobrecarga de gestão de múltiplos repositórios.

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

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

Os maiores riscos que a equipe corre envolvem o crescimento descontrolado do escopo, com a adição desenfreada de funcionalidades sem mudança no prazo final e sem aumento dos custos; mudanças nas funcionalidades, ocasionando retrabalho em etapas que tidas como concluídas; ausência de métricas de sucesso, de modo que não é possível determinar quando uma operação foi concluída e quando precisa de ajustes; divergências acerca de prioridades dentro do projeto; má gestão do tempo; entre outros. Como exemplo do que pode dar errado podemos citar a divergência de expectativas acerca do projeto, em que o professor tem um objetivo específico com o trabalho, mas o aluno não entende qual é esse foco, e entrega um projeto com boas características, porém focando em funcionalidades/atributos diferentes do que o professor vai avaliar. O mesmo pode acontecer em um projeto para um cliente, caso as expectativas dos dois lados não esteja alinhada.

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

🟢 MATEUS SILVA LOPE. (Matrícula: 20243004300, Login: @MateusLopes15)

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

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

Quando se utiliza o CI/CD, a cada Commit feito, há um “robô” verificando se todos os códigos funcionam, ele basicamente, clona o repositório, compila e executa cada parte. Caso exista um erro, o commit não é colocado no repositório, o erro volta para que seja consertado, dessa forma, caso haja alguma incompatibilidade seja ela qual for, rodará em todos os computadores, pela garantia que o CI/CD dão. Basicamente isso remove a chance do erro humano, garantindo um código limpo e estruturado.

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

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

Uma Issue, é basicamente uma parte do programa que vai ser feito, como um “O que”, então por exemplo, no chatbot, teria: “implementar a conexão com banco de dados”, “Criar interface de comunicação”, algo detalhado e bem descrito, do que vai ser feito em cada Issue. Por outro lado, os milestones seriam conjuntos de Issues, que definem quanto tempo vai demorar uma, fazendo paralelo com Scrum, temos uma milestone sendo como uma sprint, e o Issue uma task da sprint.

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

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

Épicos são considerados basicamente funcionalidades principais do programa, ela costuma durar mais dias para montar, por exemplo de vez de 4 horas, ela dura 2 a 3 dias. Colocar um épico apenas, sem fatiar, e deixar detalhado em cada coisa, criando tarefas atômicas, o programa consegue ser desenhado de maneira mais concisa.

Quando pensamos que numa equipe de 3 pessoas, tem 10 tarefas no doing, isso está sendo feita de maneira errada, ao dividir 10/3, temos em média 3 a 4 tarefas sendo feitas ao mesmo tempo por uma pessoa, de vez de considerar uma pessoa fazendo uma tarefa por completo, antes de pegar outra tarefa. O desenvolvedor, só pode assumir outra tarefa, quando ele já terminou uma, restrigindo o WIP, é impossível que um mesmo programador, queira tentar fazer tudo ao mesmo tempo, é a famosa frase: “quem faz de tudo um pouco, não sabe de nada”

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

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

A principal vantagem de utilizar MonoRepo é a abordagem de rastreabilidade fácil, como tudo está apenas em um repositório, é mais fácil malear ele. Outro pronto é conseguir facilmente interagir e mandar para o repositório, código do back e do front juntos(Commit Atômico), além de que para o professor, fica mais fácil verificar a linha do tempo da criação do projeto, sem ter que ficar navegando entre dois repositórios. Por fim, só é preciso criar uma Pipeline de CI/CD, se houvesse dois repositórios, teria que configurar os dois.

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

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

Um dos maiores riscos é o Scope Creep, quando uma equipe não consegue alinhar bem com o cliente, e ter um escopo bem desenhado e documentado, o cliente pode pedir coisas infinitamente. Um caso que posso citar de algo que aconteceu assim, foi um site que o cliente queria apenas uma manutenção, apenas modificar ali e aqui umas coisas, mas como não tinha documentação nenhuma de nada, o cliente foi pedindo e pedindo, ninguém teve pulso firme para parar ele, e ele só foi indo. Com isso, chegou uma hora que a manutenção de uma página no site, fez com que o site fosse todo modificado, 5 páginas diferentes e afins. Outro risco, é a conectividade entre os módulos, digamos que um módulo dependa do outro, e esse módulo dependente, seja construído de uma maneira, e esse módulo principal seja construído de outra maneira depois, esses dois módulos nunca vão conseguir se comunicar sem uma manutenção, ou seja, retrabalho. Além disso, fica complicado prever um tempo de um projeto, se não tem nada definido. Uma outra coisa que é parecida com o Scope Creep, o chamado Scope Misalignment ou Poor Scope Definition. É a famosa foto que tem o cliente pedindo um balanço numa árvore, e tudo que é definido em cima daquilo. Um exemplo, vivido por mim, foi o cliente definir que queria x, dizer muitas vezes que queria aquilo, mas na reunião de mostrar o protótipo o cliente não ver que faltava o que ele pediu, ai no meio do projeto, o cliente perguntar onde está o que ele pediu, eu indagar falando que isso não estava no escopo definido e tomar uma investida do cliente. Nesse caso foi possível contornar tranquilamente, mas poderia ter frustrado muito o cliente.

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

🟢 MATHEUS MATOS BOT. (Matrícula: 20243001353, Login: @matheusmb10)

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

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

O pipeline de CI/CD remove o fator humano e realiza testes automatizados com os commits feitos pelos devs. Se os testes apresentarem falhas, o merge request pode ser bloqueado. Caso contrário, o código passa e vai a produção para ser continuado.

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

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

A issue define escopo e define o que precisa ser realizado, possuindo responsável, prioridade e estimativa de esforço. Milestones gerenciam o tempo e definem quando um pacote de escopo deve ser entregue, agrupando uma determinada quantidade de issues.

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

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

Fazer o backend do assistente de IA é algo extremamente geral e que é na verdade um conjunto muito grande de subtarefas, que estas sim, deveriam estar no kanban e que representariam de fato aquilo que está sendo feito durante o projeto, passo a passo. Quanto a essa quantidade de tarefas para 3 pessoas, é algo que dificulta o processo pois cada pessoa estaria muito provavelmente fazendo mais de uma tarefa ao mesmo tempo e a partir disso é possível concluir que essa pessoa estaria exposta a diferentes situações e necessidades ao mesmo tempo, ou seja, pode acabar errando durante a construção de cada necessidade.

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

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

Centralizando o projeto em um unico repositorio facilita analisar o panorama geral por completo do projeto. Isso permite maior rastreabilidade pois todas mudanças estarão armazenadas em um lugar comum.

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

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

Considerando que o project charter contém o que o sistema fará, algumas premissas e restrições, justificativa e entre outras caracteristicas que delimitam o projeto, se você não o constrói previamente, você irá construir algo no “escuro”, sem saber se o caminho que está tomando o leva de fato para aquilo que se espera. Como exemplo, podemos citar a discordância direta com o cliente, onde ele pode solicitar alterações durante o projeto, que não foram comunicadas com você antes e dizer que era algo que inicialmente ja estava planejado, sendo que não era o caso.

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

🟢 NATHAN BALMANT DE. (Matrícula: 20223004358, Login: @NathanBalmant)

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

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

O pipeline CI/CD garante a entrega do projeto e das alteracoes do projeto funcionando em uma maquina limpa, enquanto antes poderiamos ter o problema de um projeto funcionar em uma maquina especifico porque poderiamos ter variaveis como versao da linguagem usada, sistema operacional, arquivo nao commitado, etc… Enquanto o pipeline CI/CD nao é influenciado por esses fatores ja que roda em um container novo e so usa o que esta commitado no projeto.

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

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

Issues sao as tarefas que executamos (uma unidade de trabalho), já Milestones é o prazo em que essas Issues devem ficar pronta, e a medicao de esforco das Issues devem caber dentro da Milestones que ela esta. Logo o primeiro gerencia o escopo de cada tarefa (Issues) e o segundo gerencia o tempo (MIlestones).

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

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

Porque “Fazer todo o backend do Assistente de IA”. nao é uma tarefa, é parte do projeto inteiro, e muito provavelmente se estamos falando de um projeto serio, essa tarefa nao vai caber em um ciclo de trabalho ou em uma sprint, logo ela é um epico.

O WIP significa “Work in progress”, ou seja, o trabalho que esta em andamento, e para isso ele estabelece um limite de tasks que pode estar em doing, e nesse caso é na faixa de 3, 10 issues seria um numero muito fora do limite.

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

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

Considero que a principal vantagem do Monorepo é deixar o versionamento mais simples, ja que separar backend,frontend, entre outros, pode deixar o cenario mais dificil de conseguir uma visao completa do que aconteceu. Já com o monorepo as versoes sempre vao estar sincronizadas, os merges tambem, os commits e as documentacoes tambem, entregando assim muito mais rastreabilidade ao sistema.

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

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

Acredito que o retrabalho, devido a nao ter Project Charter os escopos ficam mal definidos, e fica na interpretação dos desenvolvedores o que fazer, o que considerar como mais importante, além de ficar mais dificil dar estimativa e prazos, ate por isso, esse é um dos pontos que podem dar errado com clientes, ou professor, pois pode se errar bastante no prazo estimado, e outro ponto que pode estar errado é o próprio desalinhamento de expectativas e no final o cliente/professor podem ficar pedindo funcionalidades que nao estavam expressas no sistema.

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

🟢 PEDRO CLAUDIO JAC. (Matrícula: 20223006791, Login: @pejacome)

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

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

Pois ela gera um processo de teste no próprio git. Assim ele pode ser testado de forma mais universal.

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

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

Issues gerencia o escopo, determinando o que deve ser feito. Milestones é um conjunto de issues que deve ser feito em um tempo determinado.

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

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

O projeto deve ser feito e planejado em partes. Se não não dá pra acompanhar o desenvolvimento corretamente e verificar se segue o charter.

É ruim ter 10 na coluna de doing por falta de foco e difícil de gerenciar.

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

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

Ter uma visão geral sobre o projeto.

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

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

O maior risco é desnorteamento. A equipe pode desenvolver um software que não cumpre a funcionalidade básica e se foca em externalidades, ou pode fugir das necessidades do cliente, etc.

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

🟢 RONALD RODRIGUES. (Matrícula: 20243003723, Login: @ronaldrodriguesvitorino)

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

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

Uma pipeline de CI/CD (Integração Contínua, Entrega Contínua) garante que todo código que é submetido para entrar no repositório é verificado, empacotado e levado para a produção em segundos; o CI, a parte de integração, garante que a cada commit, um robô irá baixar o código, compilar e rodar testes e, se esses testes falharem devido a algum erro ou código defeituoso, o merge é bloqueado, fazendo com que todo código submetido seja testado em um ambiente isolado para garantir que está totalmente funcional. O CD, a parte de entrega, garante que, se os testes passarem na parte de CI, esse robô empacotará e enviará tudo direto para a produção, removendo o fator humano na parte de submeter o código na codebase.

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

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

As issues servem para gerenciar e fracionar o escopo, mensurando o que deve ser feito a cada entrega do sistema para incrementá-lo, enquanto as milestones servem para gerenciar e fracionar o tempo, delimitando quando um pacote do escopo deve estar pronto, funcionando como uma ‘sprint’, agrupando um pacote de issues sob um objetivo estratégico temporal fixo.

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

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

Uma issue épica é aquela que demanda mais de 2 ou 3 dias intensos de código e, idealmente, não deve existir, precisando ser fatiada em issues menores que, juntas, poderiam compor essa issue maior; essa issue épica complica o gerenciamento do projeto, pois não existem critérios claros e mensuráveis de aceitação e demorará muito tempo. Além disso, ao utilizar o board de Kanban, é importante entender que não faz sentido manter uma quantidade de issues exorbitantemente maior do que a quantidade de pessoas na equipe, e o ideal é terminar o que começou antes de colocar uma outra issue em ‘Doing’, o que reduz a troca de contexto e aumenta mais a produtividade técnica.

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

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

Seguir uma abordagem monorepo centraliza todos os artefatos relacionados a um projeto (seja o project charter, diagramas, modelos, backlog, relatórios e o próprio código em si) em um mesmo lugar, permitindo uma rastreabilidade muito mais efetiva em relação à abordagem polyrepo; um único commit ou merge request possui a capacidade de atualizar todos os artefatos de forma atômica, sendo ideal para times e projetos de escopo pequeno, que não necessitam de uma alta escalabilidade, e é possível ver o que cada um está fazendo de forma muito mais rápida. A abordagem polyrepo gera uma sobrecarga bem maior em gestão, já que vários repositórios precisam ser geridos ao mesmo tempo, e uma configuração de CI/CD distinta para cada uma delas, sendo especialmente problemático para equipes pequenas.

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

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

Um Project Charter é um documento formal que serve para nortear e fornecer as informações iniciais acerca de um projeto, delimitando seus objetivos, escopo inicial e critérios para que haja um alinhamento entre todos os envolvidos. A falta de um Project Charter torna um projeto muito instável pela falta de concordância entre o que será, ou não, produzido; sem os requisitos, premissas, restrições e objetivos, não pode existir uma cadeia de comando que garante que o projeto está nos conformes. O escopo do projeto pode aumentar muito, comprometendo os prazos, não existem métricas para mensurar se o resultado está dentro de um padrão estabelecido, além de problemas na comunicação como a quebra de expectativa ao cliente perceber que uma funcionalidade não estava seguindo a sua visão que tinha para o projeto, pela falta de objetivos mensuráveis no início, ou a falta de uma cadeia de comunicação clara para evitar ruídos entre a equipe.

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

🟢 SABRINA EVELYN SI. (Matrícula: 20243000454, Login: @SabEvelyn)

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

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

Dizer que “Na minha máquina funcionava” não é garantia de que em o código funcione efetivamente. Por isso existe o CI/CD que automaticamente testa o código antes de colocá-lo para rodar.

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

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

As Issues registram as tarefas, os bugs ou ideias de um projeto, elas gerenciam o escopo do projeto. Já as Milestones agrupam essas Issues e definem um tempo de entrega (prazo).

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

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

Essa issue é muito grande para ser feita como uma só tarefa, então é necessário dividi-la em pequenas tarefas. Ter dez tarefas em “doing” para três pessoas é muito trabalho, para melhorar essa situação o WIP limita a quantidade de tarefas simultâneas da equipe.

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

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

A principal vantagem de optar pelo repositório único é a organização, pois toda a documentação, back-end e front-end estrão juntos. Isso facilita a gestão e o acompanhamento compartilhado do grupo quanto à esses documentos.

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

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

Sem o Project Charter a equipe fica sujeita à erros, pois a equipe começa a trabalhar sem ter a construção da justificativa, funcionalidades, custos e prazos do projeto (isso tudo está no Project Charter. Essa situação pode causar retrabalho, como por exemplo: modelar uma funcionalidade, mas o cliente não a tinha solicitado.

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

🟢 SAMUEL BRUM LELLE. (Matrícula: 20243004560, Login: @Sam)

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

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

Disponibilizar o código criado em um modelo de pipeline faz com que ao longo da produção o projeto seja testado e posto a prova de falhas e bugs em um espaço padronizado para todos, de tal forma que ao rodar em uma máquina o código simplesmente funcionará como em qualquer outra, não havendo interferência de falta de componentes ou de inconsistência de versão e tendo todas as alterações documentadas e tornando o que foi feito público para toda a equipe de desenvolvimento de forma auditável.

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

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

As milestones são as definições de momento de início e de finalização estipuladas para alguma etapa ou implementação do projeto enquanto Issue é uma pontuação descritiva do que deve ser feito ou arrumado no trabalho.

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

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

Essa issue é um objetivo muito abrangente do projeto, é necessário pontuar mais especificamente limites bem definidos do que deve ser resolvido. Os limites de wip são uma forma de controlar o que está sendo tirado do planejamento, posto em prática e então finalizado. Se tem muitas atividades ditas em progresso o trabalho não tem um foco definido e a organização e controle das atividades desenvolvidas fica esparso.

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

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

A principal vantagem é que todo o material elaborado está centralizado em um único acervo, fazendo com que todas as mudanças e atualizações do projeto estejam documentadas em um único local minimizando a chance de se trabalhar simultaneamente duas versões diferentes do projeto e garantindo que todos os componentes estejam alinhados ao longo da produção.

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

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

A equipe pode não saber se coordenar para dividir as etapas de desenvolvimento e acabar gerando uma bola de neve de bugs ou pontas soltas no projeto, constando falta de elementos essenciais para o produto final ou até mesmo implementar coisas que o cliente nem pediu. Por exemplo chegar na data limite ou próximo e o cliente ao ver o estado final do produto afirmar que não era o que ele queria, como não houve organização para notificar os estágios de produção ao cliente ocorre essa falha de comunicação avassaladora.

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

🟢 THALLES VINÍCIUS. (Matrícula: 20243014001, Login: @Thalles_cruz)

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

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

O pipeline atua como um guardião do código, no CI são realizadas integrações continuas a cada push ou commit, em um ambiente compartilhado, criando automaticamente um ambiente limpo, após isso são feitos testes e passando nesses testes pelo CD, o código é empacotado e implantado automaticamente automaticamente. Se o código não passa no teste, ele não vai para o ambiente de produção, e protegendo o código da main!

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

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

As issues servem para gerenciar o escopo, as entregas menores divididas, já o Milestones serve para gerenciar essas issues dentro de um espaço temporal, como nas Sprints. Por exemplo podemos dividir o projeto em 4 Sprints que irão durar duas semanas cada uma, e haverá diversas issues dentro dessas Sprints.

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

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

Uma issue que leva mais de dois dias de código para ser finalizada, provavelmente é um Épico e precisa ser fatiada em frações menores. Precisa mais de um ciclo de trabalho ou sprint para ser desenvolvida! As issues precisam ter clareza do que é para ser feito para que se possa mensurar os resultados! As doing no kamban devem serem colocadas de acordo com o que se vai resolvendo, não devem ser colocadas todas de uma vez, uma vez que isso atrapalha na qualidade final do projeto, o limite de WIP, foca na finalização de tarefas em que se pretende que o desenvolvedor e os membros da equipe não troque para a próxima tarefa, sem antes terminar a que estava em execução, eliminado desse jeito as trocas de contexto, que atrapalham o rendimento do programador!

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

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

A abordagem Monorepo mantém o back end e o front end no mesmo repositório, facilitando o acesso e o trabalho da equipe! Facilita a rastreabilidade, pois todas as partes do projeto ficam no mesmo lugar e podem ser acompanhadas por commits, branches e issues! Podendo ser verificado o que e quando foi mudado e por quem, e em qual etapa do projeto! Facilita na organização!

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

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

Não havendo um Project Charter pode haver conflitos de alinhamento entre a equipe e o cliente! Gerar problemas na entrega e na qualidade do produto! O Project Charter serve para alinhar e mapear todas essas expectativas e o que deve ser entregue de fato ao final do projeto.

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

🟢 VICTOR OTAVIO SOU. (Matrícula: 20243001219, Login: @vsouza)

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

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

O CI/CD (Integração e Entrega Contínuas) chegou para dar um fim a frase “na minha máquina funcionava!”. A Integração Contínua (CI) garante que, a cada comit, um robô crie 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 é bloqueado. A Entrega Contínua (CD) entra logo após: se os testes passam, o robô empacota o software e o implanta automaticamente na nuvem (Heroku, Render, AWS), colocando-o em produção em segundos.

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

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

Uma issue é um contrato de trabalho verificável, descrevendo o que precisa ser feito (uma funcionalidade, bug ou débito técnico) quem é o responsável (Assignee), a prioridade (labels) e a estimativa de esforço (Weight). Já um milestone é a representação técnica de uma Sprint (marco de tempo - geralmente 2 semanas) que agrupa um pacote de Issues sob um objetivo estratégico. Portanto, a Issue gerencia o escopo, enquanto o Milestone gerencia o tempo.

Como exemplo prático para criação do Assistente IA, podemos criar um Milestone “Sprint 1 - Integração básica” definindo um prazo (2 semanas) e em sequência, criar uma Issue “Configurar chave da API do backend” definindo o scopo do trabalho.

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

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

Se uma Issue leva mais de 2 dias de código, ela é considerada um Épico e precisa ser fatiada. “Fazer todo o backend do Assistente de IA”, não possuiu critérios, não possui uma forma de teste objetiva, além de que seu desenvolvimento levaria dias ou semanas. O WIP (Work in Progress) é um limite que força a equipe a terminar o que começou, antes de iniciar algo novo, o que reduz a troca de contexto (que destrói a produtividade) e mantém o fluxo, além de que não faria sentido em uma equipe de 3 pessoas, terem 10 tarefas In Progress.

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

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

A adoção do monorepo centraliza o código fonte do back-end, interface, testes, documentação e os scripts em um único lugar. Dessa forma é possível saber exatamente qual Issue gerou qual alteração em todo sistema. Além disso, essa arquitetura facilita a auditoria do projeto, oferecendo visibiliade total sobre a colaboração e as contribuições de cada membro da equipe ao longo do ciclo de desenvolvimento.

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

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

Os maiores riscos de se iniciar um projeto sem uso do charter é o risco de scope creep, sendo uma proteção a equipe contra mudanças não programadas ao longo do projeto, além da ausência de critérios, com a ausência do charter, o projeto não atenderá os objetivos SMART não será possível saber se os objetivos foram bem definidos e ao fim do projeto se foram alcançados.

Exemplos de erros na comunicação com o cliente seria adição de novas funcionalidades, tal como “adicione só mais uma função” ou “adicione só mais um botão”, sem a reavaliação de orçamento ou prazo. Além de situações em que o cliente não entende bem os recursos disponiveis, e vislumbre ferramentas e funcionalidades absurdas, que com a existencia do charter, ele abaixaria as expectativas, trabalhando com a realidade.

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

🟢 VITOR EMANUEL VEN. (Matrícula: 20243000919, Login: @VitorEmanuelVS)

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

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

O CI/CD é uma prática essencial para a Engenharia de Software dos dias atuais, ela basicamente serve para retirar o fator humano das entregas de código. É dividido em duas etapas:

  1. Integração Contínua: a cada commit feito, um robô prepara todo o ambiente com as mudanças feitas e roda os testes automatizados, se alguma coisa falhar, o merge não acontece.
  2. Entrega Contínua: caso os testes ocorram corretamente, é gerado um pacote pronto para ir para produção e pode ou não ser implantado automaticamente na nuvem.

Esse processo garante que código com defeitoos não chegue em estado de produção.

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

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

A Issue é a unidade de trabalho, ela determina aquilo que deve ser feito. As issues são responsáveis por definir o Escopo do projeto. Já, as milestones estão ligadas ao gerenciamento do tempo do projeto, são marcos temporais, agrupam um conjunto de issues que devem ser feita em um intervalo estabelecido, o critério de agrupamento pode ser apenas tempo ou um objetivo que o conjunto de issues pode significar.

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

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

Essa issue leva esse nome por ter ser algo muito grande para ser feito. Por ter essa característica, outras se originam a partir dela, que são: falta de objetividade, dificuldade de dizer que está completa ou não, muito tempo para ser completada. Dessa forma, o que faz mais sentido é dividí-la em Issues menores que, por fim, levarão à conclusão do objetivo maior.

É um erro ter uma coluna de trabalhos em progresso muito grande em relação à quantidade de pessoas trabalhando naquele quadro porque isso quer dizer que a equipe está se dividindo em vários trabalhos diferentes, sem finalizar nenhum deles. Essa troca gera o fenômeno de “troca de contexto”, que diminui muito a produtividade. Estabelecer um limite de WIP (Work In Progress) é essencial para diminuir a ocorrência de trocas de contexto ao longo do trabalho e, assim, estar mais próximo de manter a produtividade esperada.

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

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

A principal vantagem dessa estratégia (Repositório Único) é que ela garante visibilidade completa dos módulos do projeto em um ponto central e a atomicidade, visto que uma mudança de uma característica pode ser feita de forma completa em apenas um commit. Tudo isso favorece a total Rastreabilidade Transversal, que é a capacidade de determinar qual Issue (unidade de trabalho) foi responsável pela mudança que ocorreu no sistema. Em projetos e equipes menores, isso é uma grande vantagem, visto que existe uma grande ligação entre as partes do projeto.

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

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

Sem o Project Charter estabelecido e com acesso aos envolvidos no projeto, é evidente que não é possível atingir aquilo que o cliente desejava através em um processo de desenvolvimento real. Para que seja possível, é necessário ter uma referência comum, estruturada e definida em acordo entre os impactados pelo projeto. Sem ela, não é possível garantir que chegará a um resultado desejado, até porque esse resultado não existe de forma objetiva, cada um que interfere no projeto pode interpretar certo elemento de uma maneira diferente. Uma maneira de se pensar é que, quando não existe uma fonte primária de informação, as fontes podem ser qualquer um envolvido e a cada nível que essa informação inicial passa, informação é perdida ou mudada, podendo chegar em algo completamente distante do que é necessário para o cliente do projeto para sua aplicação, o que gera, por fim: retrabalho, gastos desnecessários e entrega de produto incorreto.

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

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

  • BIANCA DA SILVA B. (@biancaB)
  • CARLOS EDUARDO (@CarlosEduardo)
  • FILLIPE TOMAZ CAR. (@Fillipe)
  • FLÁVIO CORCINI DE. (@FlavioCorcini)
  • GABRIEL SILVA GON. (@mewndigo)
  • HUGO VICENTE COEL. (@hugovicente)
  • JOÃO CARLOS FERRE. (@joaocarlos.fm)
  • RAFAEL DE OLIVEIR. (—)
  • SAULO DIAS DE OLI. (@Saulo)
  • VICTOR GABRIEL MA. (@vicmagione)
  • VITOR OLIVEIRA CA. (@Vitor)
  • WELLINGTON JHONNEY (—)
De volta ao topo