Data de Publicação

12/09/2026

Data de Modificação

31/08/2026

Relatório de Avaliação - L01

Gerado em 31/08/2026 09:18:02

📊 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
BIANCA DA SILVA B.	✅	✅	✅	✅	✅	5/5
CARLOS ESTEVÃO	✅	✅	✅	✅	✅	5/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
FILLIPE TOMAZ CAR.	✅	❌	❌	❌	❌	1/5
FLÁVIO CORCINI DE.	✅	✅	✅	✅	✅	5/5
GABRIEL ALVARENGA.	✅	✅	✅	✅	✅	5/5
GABRIEL CAMPOS MA.	✅	✅	✅	✅	✅	5/5
GABRIEL PINHEIRO.	✅	✅	✅	✅	✅	5/5
GABRYEL FERREIRA.	✅	✅	✅	✅	✅	5/5
ISAÍAS CÉSAR SAMP.	✅	✅	✅	✅	✅	5/5
JOÃO CARLOS FERRE.	✅	✅	✅	✅	✅	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.	❌	✅	✅	✅	✅	4/5
SAULO DIAS DE OLI.	❌	✅	✅	✅	✅	4/5
THALLES VINÍCIUS.	✅	✅	✅	✅	✅	5/5
VICTOR GABRIEL MA.	✅	✅	✅	✅	✅	5/5
VICTOR OTAVIO SOU.	✅	✅	✅	✅	✅	5/5
VITOR EMANUEL VEN.	✅	✅	✅	✅	✅	5/5
VITOR OLIVEIRA CA.	✅	✅	✅	✅	✅	5/5
CARLOS EDUARDO	❌	❌	❌	❌	❌	0/5
GABRIEL SILVA GON.	❌	❌	❌	❌	❌	0/5
HUGO VICENTE COEL.	❌	❌	❌	❌	❌	0/5
RAFAEL DE OLIVEIR.	❌	❌	❌	❌	❌	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: Por que código bom não basta?

Um exemplo é o citado na sala de aula, sobre um aluno que possa dizer que ele vai ser o dev, e que não precisam se preocupar, pois ele sabe de tudo, e pode fazer tudo, e por isso existem as gestões, para que oque foi proposto seja realmente feito, outro exemplo é a falta de comunicação, querer ser um lobo solitário em uma equipe, podem ocorrer problemas graves por falhas de comunicação.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A falta de tranparência não é olhada com bons olhos, esconder um bug pode transformar uma correção que seria de rotina em uma crise no futuro, em compensação reportar precocemente, faz com que a equipe possa se reajustar e corrigir para que o erro não chegue no cliente.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

É uma bomba relógio pois em algum momento tudo pode e vai se tornar caótico, fazendo de qualquer jeito só para entregar, faz com que a equipe, com o projeto ja entregado, em fases que estaria lidando só com estabilidade e manutenção, tem que ficar tempo todo presa em operações para apagar incendios e manter o programa funcionando, sem contar o risco de uma falha geral, pois a maioria dos softwares sofre falhas não por limitação tecnológica, mas por escopos mal definidos, ou seja, entregar algo instavel só prejudica a credibilidade da equipe e não ersolve o problema do usuário

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Eu diria a eles que, ao colocar um prazo curto reduzindo o tempo e deixando o custo fixo, sem novos desenvolvedores, é impossivel manter a mesma entrega sem sacrificar a qualidade, e como reduzir a qualidade não é uma opção, oque resta é negociar o escopo, sendo assim usariamos uma visão ágil MVP, assim a equipe pode entregar o maior valor possivel dentro de um prazo mais curto.

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

📝 Questão 1: Projetos vs. Operações na Prática

Na matéria de Modelagem de Sistemas, fizemos um projeto de um aplicativo para que os clientes pudessem agendar procedimentos na barbearia pelo celular. Nesse caso, o trabalho seguiu um fluxo claro, que envolvia o levantamento de requisitos, a criação de diagramas e o desenvolvimento da arquitetura do banco de dados para a barbearia.

Já na matéria de Desenvolvimento de Software, colocamos em prática o que tínhamos feito no papel, construindo a aplicação. Embora nessa fase o trabalho tenha sido mais dinâmico lidando com pequenos ajustes e melhorias no código , ainda se tratava de um projeto. Para isso, usamos a dinâmica de métodos ágeis, por se tratar de uma entrega que deveria ser concluída dentro do prazo da disciplina.

Quanto à rotina e sustentação, não chegamos a operar o sistema em produção, mas a operação seria manter o aplicativo no ar, monitorar o serviço de banco de dados e corrigir pequenos bugs diários relatados pelos clientes e barbeiros.

Para separar esses dois mundos, a diferença tem mais a ver com ter claramente um objetivo final e, a partir disso, procurar a melhor forma de alcançá-lo mantendo a continuidade do serviço.

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: Por que código bom não basta?

Um dos problemas é com as regras de negócio, sem uma gestão pra poder planejar elas é impossivel gerar um código para solucionar o problema sem um problema bem definido, e outro problema é o código bom em si não fala sobre o projeto e sem uma documentação própria pode ser díficil expandir sobre ele

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder um bug debaixo do tapete para cumprir um prazo você corre o risco de um usuário do sistema passar por esse bug na produção, o que pode causar um enxame de problemas para a empresa dependendo do bug, por isso é sempre melhor ser transparente no processo e sempre anunciar bugs

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Corrigir de forma superficial um problema para alcançar um prazo pode fazer o problema voltar de forma mais severa, com até possiveis problemas em produção que afetam diretamente o cliente

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Se é necessário atencipar o lançamento de um software em 1 mês e não é possivel aumentar o orçamento, seria necessário negociar o escopo do projeto de acordo com o triângulo de ferro, que é composto por tempo, custo e escopo, como o tempo e custo permanecem fixo a única variável nesse projeto seria o escopo dele, sendo ele o que vai definir a qualidade do projeto que é inegociavel

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

📝 Questão 1: Projetos vs. Operações na Prática

Projetos eram os trabalhos que os professores davam um tempo maior para fazer e tinham uma especificação maior e operações pode ser as listas de atividades que alguns professores passavam semanalmente, que não tinham muitas informações, eram mais simples e era algo que eu tinha que fazer constantemente cada semana

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: Por que código bom não basta?

O primeiro motivo que eu penso se deve aos ruídos na comunicação humana. O problema nesse caso não é técnico, é de alinhamento e ponto de vista. Sem formalidades, ao final do projeto vai estar tudo diferente do esperado, e com pouco ou nenhum tempo para rastrear os erros e corrigir.

O segundo motivo que eu coloco é muito psicológico, é o já citado ego. Com o tempo, as pessoas se apegam ao próprio código como uma extensão do próprio ser, então qualquer crítica ao trabalho costuma ser entendida como um ataque pessoal, porque a pessoa se enxerga como parte daquilo. Não só no trabalho, mas percebe-se esse padrão em várias áreas da vida. Portanto, o processo formal aqui é muito útil para tirar o emocional da jogada e colocar um árbitro para preservar a parte racional, então aqui entra a revisão por pares, documentação e métricas objetivas de qualidade no geral.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A diferença é que esconder o bug não ajuda em nada, só posterga a descoberta, acumulando o problema como uma bola de neve. Além disso, se não for reportado, ninguém no time vai saber que aquele problema existe, então outras partes do sistema podem ser construídas em cima dele, o que espalha o erro para mais lugares. Isso afeta a credibilidade do desenvolvedor no longo prazo.

Já reportar o bug cedo numa reunião de alinhamento permite que o time todo saiba do risco, decida junto como agir (corrigir agora, isolar o problema, ou aceitar o risco conscientemente) e evita que outras pessoas construam código dependendo de algo quebrado.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Porque fazer de qualquer jeito vai causar prejuízos no futuro. Se pularmos ou atropelarmos as etapas corretas de implementação, uma hora essa bomba vai estourar e vamos ter que voltar para arrumar. Então, o tempo ganho agora será pago no futuro de alguma forma e com juros, porque corrigir um bug em produção sempre custa mais caro do que ter feito certo desde o início.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Para se ter uma entrega de alta qualidade é necessário equilibrar 3 fatores: tempo, escopo e custo. Uma vez que vocês propõem antecipar o tempo em 1 mês, vai ser necessário balancear as outras variáveis de acordo. Porém, vocês não querem contratar desenvolvedores. Então, como se decidiu manter o custo fixo e antecipar a entrega, necessariamente precisaremos alterar o escopo do projeto. Do contrário, a qualidade do serviço ficará extremamente comprometida, o que geraria mais custos no futuro, para eventuais correções de bugs em produção e manutenção custosa.

Sendo assim, em métodos ágeis, como o Scrum, conseguiríamos construir um MVP (Produto Mínimo Viável), entregando o maior valor no menor tempo disponível, optando por cortar funcionalidades secundárias (o que vai ser cortado deve ser decidido e classificado junto com a equipe).

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

📝 Questão 1: Projetos vs. Operações na Prática

O projeto mais bem definido que vivenciei até aqui na graduação foi na disciplina de Compiladores, com a implementação de um Compilador Mini-Pascal. O escopo era fechado desde o início: as fases estavam bem delimitadas e o fim era claro. Cada etapa tinha seu próprio entregável, o que reforçava a ideia de um esforço temporário, com começo, meio e fim bem marcados.

Já em relação à operação, o exemplo que mais se aproxima foi a disciplina de Desenvolvimento de Sistemas, na qual implementamos uma biblioteca. Diferente do compilador, esse projeto não tinha um fim natural: começamos, mas era um processo contínuo de commits, ajustes e evoluções, que inclusive ainda poderia continuar sendo desenvolvido e aprimorado até hoje.

A diferença que percebo entre os dois casos é justamente essa: no compilador, o objetivo era entregar um resultado único e específico, e quando isso foi alcançado o trabalho terminou. Já na biblioteca, o objetivo era criar, manter e evoluir um sistema, sem um ponto de encerramento definido e nem tarefas sequenciais.

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

🟢 BIANCA DA SILVA B. (Matrícula: 20223004410, Login: @biancaB)

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

📝 Questão 5: Por que código bom não basta?

Duas razões humanas são:

Falhas de comunicação: podem gerar interpretações diferentes, retrabalho e atrasos. Processos formais ajudam a manter todos alinhados.
Expectativas irreais: prazos, custos e entregas podem ser vistos de formas diferentes por clientes e equipe. A gestão ajuda a negociar prioridades e definir o que realmente é possível.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug para cumprir um prazo pode evitar um problema imediato, mas aumenta o risco de consequências maiores no futuro. O erro pode afetar outras partes do sistema, chegar ao usuário final e acabar exigindo mais tempo e esforço para ser corrigido depois. Já reportar o problema assim que ele é identificado permite que a equipe avalie o impacto, defina prioridades e tome uma decisão em conjunto. Mesmo que o bug não seja corrigido naquele momento, todos passam a conhecer o risco e podem se planejar melhor.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Um código feito às pressas tende a ter mais erros, ser mais difícil de entender e exigir mais tempo para manutenção e correções. No mês seguinte, a equipe pode acabar gastando muito tempo corrigindo problemas da entrega anterior. Além disso, quanto mais esse código é utilizado e recebe novas alterações, mais difícil e caro fica corrigi-lo.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Nessa situação, eu explicaria à diretoria que pelo conceito do Triângulo de Ferro, prazo, custo e escopo estão diretamente relacionados. Como o prazo será reduzido em um mês e não haverá aumento no orçamento, seria necessário ajustar o escopo para que a entrega continue sendo viável e mantenha a qualidade esperada. A negociação seria feita identificando quais funcionalidades são essenciais para o lançamento e quais podem ser entregues posteriormente. Portanto, a primeira versão do software teria um escopo menor, priorizando as funcionalidades mais importantes para o usuário e para o negócio.

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

📝 Questão 1: Projetos vs. Operações na Prática

No meu estágio, os trabalhos em que somos alocados possuem características de projetos, principalmente porque a empresa atua como consultoria. Logo, uma empresa cliente contrata a consultoria para desenvolver um sistema ou uma solução específica, e existe um início, um período de desenvolvimento e uma etapa de finalização e entrega.
As operações estão mais relacionadas às atividades recorrentes do dia a dia, como as dailys, reuniões de alinhamento, acompanhamento das tarefas e atualização do andamento das atividades. Considero que a principal diferença está no fato de que os projetos possuem um objetivo específico e um período determinado para serem concluídos, enquanto as operações correspondem às atividades rotineiras que dão suporte ao desenvolvimento e à organização do trabalho.

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

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

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

📝 Questão 5: Por que código bom não basta?

Acredito que as principais razões para adotar essas ferramentas são:

Falhas de comunicação: Muitas vezes “só falar” não adianta, é muito complexo descrever uma tarefa de desenvolvimento apenas por conversa. Essas falhas geram aquele classico problema do telefone sem fio, onde uma pessoa passa a informação para a outra conforme a sua propria interpretação. Isso gera divergencia e problemas sérios para a qualidade de um projeto.
Expectativas irreais: um grande problema é que nós tendemos a achar que conseguimos fazer tudo rápido. Se não tiver um planejamento bem definido, não conseguimos ver com clareza possíveis problemas que podem ocorrer durante o desenvolvimento, ocasionando em atrasos.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug durante o desenvolvimento é ignorar uma bomba que pode explodir a qualquer momento em que software estiver em produção. Isso tudo pode custar muito mais caro do que alterar a data de entrega do projeto ou reduzir o escopo para focar na solução do bug.

Ao reportá-lo imediatamente, o dev deixa os superiores cientes de que há um problema que precisa ser resolvido e que pode ocasionar em prejuisos e complicações graves no futuro.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Um código mal feito gera bugs e desorganização, fazendo o time perder tempo apagando incendios no futuro, se a aplicação estiver em produção o time vai precisar ficar corrigindo esses bugs e refatorando código em vez de focar na adição de features. A melhor forma de ajustar prazos é fazendo redução de escopo do projeto, assim é possível fazer em menos tempo com o mesmo investimento um MVP e depois adicionar as novas features aos poucos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é composto por três variáveis (Escopo, Tempo e Custo) e a qualidade é o centro. Como a diretoria reduziu o tempo, e travou o custo, a única variável flexível para não afetar a qualida é o Escopo. Portanto, eu recomendaria a redução do escopo dessa primeira entrega, dando prioridade para as funcionalidades esssenciais, e deixando as secundarias para uma versão futura.

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

📝 Questão 1: Projetos vs. Operações na Prática

Durante meu tempo na Commit Jr., participei de diversos projetos de sites e sistemas com início, meio e fim bem estabelecidos. A parte inicial consistia na coleta de requesitos com o cliente e no planejamento do projeto; o meio, na execução e desenvolvimento; e o fim, nos ajuste pontuais, entrega e implantação do sistema.

Muitas vezes também era necessário realizar operações contínuas, como atualizações de conteúdos e pequenas manutenções periódicas.

De forma geral, um projeto tende a ter datas de início e fim definidas, criando um fluxo ou produto completamente novo. Por outro lado, uma operação não tem uma data final pré-determinada, seguindo um fluxo padronizado e repetitivo voltado para a sustentação de estabilidade do que já foi entregue.

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

🟢 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: Por que código bom não basta?

O ego muitas vezes pode acabar “cegando” uma pessoa, não aceitando que ela não consegue resolver determinado problema sozinha. Com isso, são geradas as falhas na comunicação, pois não serão reportados os impedimentos e, como consequência, o projeto pode estagnar, causando prejuízos para a equipe.

As expectativas irreais também são problemáticas, as vezes querer demais ou buscar coisas que estão além do alcance atual pode acabar prejudicando o desenvolvimento de determinado projeto, até mesmo afetar a moral de uma equipe inteira. O sentimento de falha e de que não é “bom o suficiente para fazer aquilo” acabam afetando diretamente a disposição das pessoas, podendo gerar atrasos, falta de criatividade para resolver os obstáculos, perda da vontade de realizar o projeto, abandono.

Os processos formais ajudam a reprimir parte da natureza humana, pois seguir etapas, criar um planejamento, executar, monitorar e controlar tanto pessoas individualmente quanto uma equipe inteira, possibilitam que nada fique para trás e tudo seja visto, analisado e moldado aos poucos, permitindo que o projeto seja entregue com a maior qualidade possível.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Durante a construção de um projeto, é necessário a comunicação clara e contínua. Com isso, é essencial a humildade em reconhecer e reportar a própria situação atual, seja, principalmente, por estar travado em alguma parte do desenvolvimento por causa de erros ou bugs. Ademais, esconder as falhas podem acarretar em problemáticas futuras e que geram transtornos tanto para a própria equipe quanto para o cliente.

Sendo assim, buscar ajuda e comunicar a equipe são formas maduras e éticas de agir, permitindo alterações precisas nos planos para que tudo ainda consiga ser entregue na maior qualidade possível.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

É uma bomba-relógio porque pode acabar gerando uma dívida técnica, que são os custos futuros de soluções rápidas ou decisões abaixo do ideal tomadas durante o desenvolvimento de software. Sendo assim, sacrificar a qualidade do código vai acarretar na cobrança de altos juros no futuro com manutenções impossíveis e quedas críticas em produção.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Caro membros da diretoria, venho lhes informar que conseguiremos antecipar o lançamento do software, garantindo a exclusividade de seu produto e a liderança no mercado. Entretanto, devo-lhes explicar um conceito muito comum da área antes, para que não haja dúvidas do que será realizado. Quando estamos desenvolvendo um projeto, nós lidamos com três importantes restrições que seriam o Escopo, o Tempo e o Custo, sem que isso afete absolutamente em nada na qualidade final do produto. Tendo em vista que, o nosso objetivo é reduzir o tempo sem que ocorra custos adicionais, é necessário que abordemos uma metodologia mais ágil, sendo assim iremos realizar a criação de um MVP (Produto Viável Mínimo) para que possamos fazer uma análise do Escopo e decidir como entregar o maior valor possível no tempo disponível, com isso talvez seja necessário o corte de algumas funcionalidades secundárias. Todavia, elas poderão ser entregues em atualizações do software através de operações futuras, se assim desejarem!

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

📝 Questão 1: Projetos vs. Operações na Prática

Ainda não comecei um estágio. Entretanto, durante a faculdade participei de várias atividades e acredito que a maioria delas eram/são projetos, como trabalhos que eu iniciava no início do semestre, ia evoluindo e desenvolvendo eles conforme a curva de aprendizado de determinada disciplina (do professor que passou a atividade) aumentava com as aulas e permitia a progressão deles (Um exemplo seria o projeto de Compiladores realizado no semestre passado). Além disso, existem pequenos projetos mais simples, que eu realizei, com a produção de slides e de simples pesquisas que permitia uma entrega mais rápida, mas ainda sim concisa (Fiz isso em matérias como Otimização I).

Ademais, faço parte de uma empresa júnior chamada Commit Jr., acredito que realizei tanto projetos quanto operações até o momento nesse caso, porque eu participei de propostas que apresentavam início, meio e fim, e, após a finalização, geralmente nós cuidamos apenas de algumas manutenções periódicas!

Não acredito que eu tenha participado de “Operações” suficientes para ter uma separação tão profunda, mas acredito que eu me empenhe mais em cumprir as metas diárias que eu mesmo proponho para mim mesmo em meus projetos (fazendo ele de pouquinho a pouquinho, acompanhando os prazos para que ele consiga funcionar, ser feito de maneira correta e as vezes corrigir falhas), como: “Quero terminar essa parte até hoje e deixar essa para amanhã”, já as operações serem revisadas conforme a necessidade (se for uma vez ou duas na semana, planejar direitinho para revisar/resolver sem que comprometa quaisquer outro compromisso).

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: Por que código bom não basta?

O uso da Gestão Ágil ou de métodos, tem como objetivo organizar toda a estrutura do projeto para que seja possível alinhar o objetivo do projeto com o que será desenvolvido, com intuito que o programador deixe desenvolva alguma funcionalidade ou desenvolva algo inútil. Assim, utilizando esses métodos é possível otimizar o tempo de produção como também organizar a equipe para que todos estejam em sincronia.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um Bug por mais que seja algo simples pode trazer consequências futuras para o projeto, erros que podem chegar em outras funcionalidades do sistema como também levar a um possível gasto de tempo da equipe para analisar e corrigir o bug. Diferente de esconder o bug, ser transparente facilitaria para a equipe em buscar uma solução com mais facilidade já que não seria necessário sofrer no futuro em algum momento e organizar a equipe com mais facilidade para corrigir o bug com mais velocidade.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Essa baixa qualidade trás diversos prejuízos a equipe e para o projeto. Ao sacrificar a qualidade do código, aumenta-se a quantidade de erros e posteriormente há uma dificuldade maior na manutenção, sendo necessário um gasto de tempo maior para implementar as correções nas próximas funcionalidades. Assim, por mais que a entrega estará dentro do prazo, trará uma dívida, que será cobrado no futuro.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Com o custo mantido e o tempo de entrega reduzido, deverá alterar o escopo que simplesmente será “piorado” ou deixará de ter algumas funcionalidades que não seriam tão importantes de imediato. Portanto, o método utilizado será o Método Ágil, na qual quando o custo e o tempo soa fixos (valor e tempo já definidos e não podem ter alterações) o escopo é o único que a ser alterado.

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

📝 Questão 1: Projetos vs. Operações na Prática

Até o momento não estive em nenhum estagio, portanto todos os projetos foram feitos pra faculdade, os considerados “projetos” foi o trabalho final de Desenvolvimento de Sistemas(https://github.com/Elielvitor45/Trabalho-Final-DS) e um trabalho de POO que dei uma atenção amais sobre ela (https://github.com/DanyelZini/Processamento-PGM-em-Matriz-Esparsa), esses dois são exemplos de projetos que eu tive como intuito tanto iniciar o projeto com intuito de postar no GitHub em especifico e “documentar” antes e depois da finalização do projeto. Para aqueles que eu considero “operações” são aqueles voltados a somente resolver o problema ou a entrega de algo.

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: Por que código bom não basta?

Processos formais não servem apenas para garantir a qualidade do código, mas também para garantir que todo o material humano que está em contato com o projeto estará na mesma página e com os mesmos objetivos. Um exemplo disso seria os possíveis problemas de comunicação. Dois bons programadores podem ter ideias diferentes para resolver o mesmo problema e em caso de cada um implementar uma parte separadamente sem ter uma comunicação clara e esclarecedora com o com outro resultará em um software com problemas, mesmo ambos escrevendo um bom código. Outro exemplo que não envolve só os programadores em si mas o cliente também são as expectativas que podem ou não ser atendidas. É comum uma pessoa de fora da área imaginar coisas para um software que não são realmente possíveis de serem feitas, sejam pela limitação técnica ou por compatibilidade com o projeto, se essas requisições forem colocadas como metas sem uma comunicação entre o cliente e o profissional é capaz de gerar um projeto com erros ou limitado.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Quando um bug é escondido ele acaba se tornando um problema futuro. Com o passar do tempo é capaz do projeto crescer e o tempo para revisitar esses erros e conserta-los diminui, até chegar em um ponto onde ele é exposto e se torna um problema real ou se torna um empecilho para o crescimento do software, podendo comprometer tudo que veio depois dele. Ao reportar o erro precocemente é mais fácil de tratar o problema e exclui a possibilidade de um problema inicialmente pequeno escalar em algo maior com o projeto já mais avançado.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Entregar o projeto “de qualquer jeito” para cumprir um prazo gera a chamada divida técnica. Esse código feito às pressas entrará em produção e será exposto a todos os ambientes reais, podendo causar bugs e problemas sérios que causaram um prejuízo maior que um adiamento, e, mesmo em caso de não haver bugs esse código com menos qualidade dificultará manutenções futuras e a implementação de novas funcionalidades, causando um efeito bola de neve que diminuirá a produtividade.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O planejamento da criação do software foi feito com base no calendário original, ou seja, toda a divisão de trabalho junto com o escopo do projeto foi planejado para se encaixar em um contexto especifico. Mudando o prazo para pior e não negociando essa mudança para a melhora de outro ponto, seja diminuindo o escopo ou aumentando a força de trabalho, se torna impossível garantir a qualidade original. Uma mudança drástica como a de diminuição de um 1 mês no prazo original pede uma realocação dos recursos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Trabalhos como o projeto em Modelagem de Sistemas que gerou um novo projeto em Desenvolvimento de Sistemas. Para mim um projeto é algo com mais potencial e demandas definidas onde é possível estimar desde o começo qual o trabalho que iremos ter.

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: Por que código bom não basta?

Duas razões são falhas de comunicação e expectativas irreais. Uma comunicação ruim pode fazer a equipe entender requisitos de formas diferentes. Já expectativas irreais podem gerar prazos e entregas difíceis de cumprir. A gestão ajuda a organizar o trabalho e manter todos alinhados.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug faz a equipe continuar o projeto sem considerar um problema que pode crescer e afetar outras partes do sistema. Quando ele é informado cedo, a equipe consegue avaliar, planejar a correção e evitar consequências maiores.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade pode até ajudar a cumprir o prazo imediato, mas gera dívida técnica. Depois, a equipe terá mais bugs, dificuldade de manutenção e retrabalho, gastando ainda mais tempo para corrigir problemas que poderiam ter sido evitados.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Eu explicaria que, mantendo o mesmo orçamento e reduzindo o prazo, será necessário ajustar o escopo. Priorizaria as funcionalidades essenciais para o lançamento e deixaria as menos importantes para versões futuras. Assim, tempo e custo ficam fixos, enquanto o escopo é reduzido sem comprometer a qualidade.

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

📝 Questão 1: Projetos vs. Operações na Prática

No meu estágio, um exemplo de projeto seria a migração de um Power BI para uma nova arquitetura de dados, pois existe um objetivo definido, etapas de desenvolvimento e um momento de conclusão após a entrega e validação.

Já como operação, considero atividades como acompanhar atualizações de dados, corrigir falhas em cargas e dar suporte a indicadores já publicados, pois são tarefas contínuas e recorrentes.

Eu separo os dois principalmente pelo objetivo e duração: projetos têm início e fim definidos, enquanto operações fazem parte da rotina e continuam acontecendo ao longo do tempo.

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: Por que código bom não basta?

Uma razão é a falha de comunicação. Cada pessoa envolvida em um projeto carrega uma imagem mental diferente do que está sendo construído. Sem um processo formal para alinhar essas imagens continuamente, cada um segue trabalhando com base na sua própria interpretação, e essas interpretações divergem silenciosamente ao longo do tempo. Um código bem escrito resolve exatamente o problema que o desenvolvedor entendeu que deveria resolver. Se o entendimento estava errado desde o início, código perfeito == solução perfeita para o problema errado. Isso não é bug de sintaxe, é falha de alinhamento entre pessoas. Processos como reuniões de refinamento, sprint reviews e documentação de requisitos existem justamente para forçar pontos de verificação regulares onde as divergências de entendimento são expostas cedo, antes de virarem código construído sobre uma premissa errada. Sem isso, você só descobre o desalinhamento na entrega final, quando já é caro demais para corrigir.

Outra razão seriam as expectativas irreais. Seres humanos são sistematicamente otimistas ao estimar prazos e subestimam a probabilidade de imprevistos. Um desenvolvedor tende a estimar quanto tempo levaria se tudo desse certo, não o tempo realista considerando bugs, dependências, reuniões, doenças, mudanças de escopo. É desconfortável admitir “não sei quanto tempo isso vai levar” ou “posso ter subestimado”. Muitos profissionais preferem dar um número otimista e “se virar depois” a admitir incerteza publicamente, especialmente diante da diretoria. Nenhuma quantidade de habilidade de programação corrige um viés cognitivo. É um problema de julgamento humano sob pressão social, não de conhecimento técnico. Por isso a gestão formal é indispensável: técnicas como estimativa em grupo e métricas históricas de velocidade no Scrum existem exatamente para corrigir estatisticamente esse viés, tirando a estimativa da opinião individual otimista de uma pessoa e baseando-a em dados reais do próprio time ao longo do tempo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Na prática, esconder o bug não o faz desaparecer, ele só fica invisível temporariamente. A longo prazo, o bug pode ser descoberto no pior momento possível, geralmente pelo cliente. Assim, pode-se ter uma queda de confiança na empresa, como também entre o time desenvolvedor com a pessoa que sabia do bug e não falou. Além disso, outros desenvolvedores podem construir código em cima da parte do bug, achando que ela é confiável, fazendo o problema crescer sem ninguém perceber.

Na prática reportar o bug, pode fazer com que a equipe o conserte a tempo da entrega. A longo prazo, permite que novas funcionalidades sejam implementadas sem erro no código e entregas sejam feitas sem bug.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Porque assim que o prazo passa, todos se mantêm ocupados com a próxima entrega urgente. Como cada novo módulo implementado depende do código mal escrito, isso aumenta o custo e o risco de consertar depois. Além disso, os problemas com o código podem ser descobertos depois do lançamento, geralmente pelo usuário final, com custo de reputação, não só técnico. Além disso, o time pode ficar mais lento porque precisa consertar e inserir novas funcionalidades no código.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Eu diria que conseguiria entregar em 1 mês, se pudermos selecionar prioridades (funcionalidades essenciais) do escopo original, propondo um produto mínimo viável em que decidiríamos o que realmente precisa estar pronto em um mês para o lançamento fazer sentido.

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

📝 Questão 1: Projetos vs. Operações na Prática

Considerando projetos da faculadade, percebe-se que escrever o Trabalho de Conclusão de Curso é considerado um projeto, pois tem início, meio e fim. Como também implementar uma nova funcionalidade pedida pelo professor em um código de Algoritmo genético da disciplina de IA também é considerado um projeto. Podemos concluir que o projeto além de possuir um início, meio e fim, possui um encerramento.

Já em outras atividades de disciplinas, revisar código de programação de colegas para construção de um site é considerado uma operação, pois é uma rotina contínua, não tem fim. Como também fazer a manutenção preventiva no meu computador é também uma operação, pois é uma manutenção, rotina contínua. A operação não possui um encerramento, as operações continuam existindo até serem descontinuadas ou automatizadas.

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

🟡 FILLIPE TOMAZ CAR. (Matrícula: 20233004600, Login: @Fillipe)

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

📝 Questão 1: Projetos vs. Operações na Prática

Na minha experiencia de faculdade, a maioria das matérias da grade curricular, incluindo a programação e o desenvolvimento de softwares, foram em matérias operacionais, na qual eram em separados os trabalhos e as avaliações especificas para cada momento do curso. Mas, houve casos específicos como na matéria de “Programação Web”, “Modelagem de sistemas” na qual matéria foi guiada em volta de um trabalho final a ser entregue no semestre.

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

❌ Questões Faltantes

Questão 2: O Triângulo de Ferro e a Pressão da Diretoria
Questão 3: O Preço Oculto da Baixa Qualidade
Questão 4: Esconder Bugs vs. Transparência
Questão 5: Por que código bom não basta?

🟢 FLÁVIO CORCINI DE. (Matrícula: 20243007295, Login: @FlavioCorcini)

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

📝 Questão 5: Por que código bom não basta?

Duas das razões que métodos de organização são indispensáveis são, por exemplo, clientes que pedem prazos muito curtos, com metas altas e baixo investimento, como em um pedido em uma plataforma de serviço que virou meme, onde foi pedido para fazer uma IA igual ao ChatGPT por 1.500 reais, o que seria resolvido em um levantamento de requisitos e definição do escopo esperado; outra razão é o mau planejamento na escolha de prazos por parte da empresa desenvolvedora, o que seria resolvido com uma gestão Ágil/PMBOK ou, como a gestão exige, documentação de “Riscos”, em vez de tentar prever uma data final.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao escolhermos esconder um bug, estamos apenas adiando e escalando o problema que ele causa. Isso acontece porque, ao implementarmos novas funções que dependem desse código, o erro só se alastra e acaba atrasando mais a produção futuramente. Já ao reportá-los, temos apenas o atraso e o incômodo inicial de tratá-los, mas evitamos muitos problemas, retrabalhos e bugs em cascata no futuro.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código para cumprir prazo não é uma boa opção, pois, ao fazer um código às pressas, muitas coisas não são bem planejadas e executadas, assim acumulando muitos bugs e não formando uma base sólida para novas funcionalidades, o que acarreta que, no mês seguinte, além de entregar as demandas do mês, será necessário fazer uma boa correção do código do mês passado e ainda serão necessárias mudanças difíceis para novas funções, desta forma só adiando e dobrando o tempo e trabalho necessário.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Diante da exigência da diretoria, minha abordagem seria validar a importância da decisão para o negócio, mas utilizar fundamentos de gestão de projetos para adequar a realidade da entrega. Eu explicaria que entendo que antecipar o lançamento pode ser vantajoso, mas que, devido à recusa por um orçamento maior para a equipe, teríamos que obrigatoriamente renegociar o escopo e a estratégia do lançamento para que a entrega continuasse com uma boa qualidade. Para não comprometer a qualidade, eu sugeriria focar em um MVP (Produto Mínimo Viável) para a nova data estipulada

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

📝 Questão 1: Projetos vs. Operações na Prática

No meu contexto acadêmico e pessoal, separo os dois mundos avaliando a temporariedade da atividade.

Os projetos desenvolvidos foram trabalhos nas disciplinas de Modelagem de Sistemas, Desenvolvimento de Sistemas e Programação Web. Nelas, modelamos documentações de software e softwares do zero. Eram projetos claros pois possuíam um escopo bem definido, um planejamento a ser seguido e uma data final de entrega.

Já as operações desenvolvidas são as minhas atividades contínuas, como a resolução diária de problemas no LeetCode, meus estudos semanais e as correções e refatorações de códigos passados. Elas se enquadram como operações porque são rotinas de manutenção (do meu conhecimento e do código) que não possuem um início, meio e fim delimitados no tempo

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

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

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

📝 Questão 5: Por que código bom não basta?

A Márcia que gostaria de responder essa pergunta, por vezes ela já contou a experiência dela com projetistas por fora do CEFET, mas assim, se não tivesse uma documentaçãozinha deboa que seja, ia ter um telefone sem fio danado que tipo, o cliente pediu X o cara de comercial anotou Y e passou Z pro cara de projetos que passou α para a equipe…. Ou seja, ia ser igual aquela imagem da balança que a Márcia já mostrou na sala que eu não vou achar pq ela tem uns 30 slides por aula. Outra coisa poderia ser o mau aproveitamento do tempo do projeto, pois se eu dividisse fazer um e-commerce de uma forma desregrada: Cada elemento eu vou gastar 3 dias pra fazer, eu ia ter um probleminha, eu vou gastar 3 dias num rodapé e só 3 dias cuidando da segurança, 3 pra programar um carrinho de comprar e os posts personalizados no blog dela sei lá… Enfim, Documentação e Gestão de Recursos foram meus destaques

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

📝 Questão 4: Esconder Bugs vs. Transparência

É outra preferencia temporal bem das burrinhas, pois eu entrego as coisas no prazo hoje, ai semana que vem o bug chega no usuário final e sei lá, eu vazo dado de cliente e eu pago multa cara, se ferrou atoa para entregar a task na hora… O jeito certo é chega na reunião semanal e reportar o bug pro problema ser do gerente, e ele que lide com esse pepino, nem que atrase o projeto, pois o erro é corrigido antes de criar danos… Claro que tem o colateral de atrasar o projeto talvez, mas é uma troca por confiabilidade, o que também melhora sua posição no long run né

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Acho que só não tem problema se no mês que vem a equipe de programador for a do seu concorrente, pq por exemplo, na Commit direto rolava margem negativa no WordPress, e isso por falta de dominio da ferramenta claro ou por pressa, e isso culmina em problemas de responsividade em qualquer alteração. Ou seja, entregar com qualidade abaixo para evitar desgaste imediato prejudica em potencial a manutenibilidade, escalabilidade, segurança e outros fatores que podem gerar um desgaste muito maior no futuro… É uma preferência temporal meio tosca

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro lembra muito o episódio de todo mundo odeia o chris que ele e o greg vão comprar identidade falsa com o Tio Ryan e eles querem bom rápido e barato: O triângulo vai estar vigiando escopo, recursos e prazo. Quando um desses três reduz e outro é congelado, o outro tem que reduzir também. Nesse caso específico, o recurso de orçamento pra chamar mais gente é congelado, e querem um prazo curto de entrega, então o escopo do projeto tem que ser reduzido, e ai a diretora pode me perguntar o motivo, e seria para garantir qualidade, afinal ou o produto não sai com todas funcionalidades, ou ele sai com tudo mal feito ou eu crio um desgaste interno tão grande que torno a equipe insustentavel a longo prazo, e se for um programador só eu acho que ele se demite ainda (experiencia de empresa junior pelo menos, onde o cara não recebe nada, pode ser meio enviesada)

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

📝 Questão 1: Projetos vs. Operações na Prática

A minha experiência com projetos na instituição é vasto, tenho uma bagagem desde o meu estágio do curso técnido, projetos na empresa júnios, projetos de pesquisa e projetos de extensão, e a maior diferença entre projeto e operação que posso trazer como contraste é a preocupação com a vitalidade, ou seja, o inicio, o meio e o fim de um projeto são únicos, mesmo quando comparados a similares. Trago por exemplo projetos de extensão, como o da astronomia, onde começou com reuniões, conhecimento teórico, observações astronomicas de teste, observações abertas ao público e no meio do projeto, colimações, alinhamentos, adequar graduação de telescópios como declinação magnética e mais ao fim, que é a fase que nos encontramos, organizações logísticas simples para observações futuras e escritas de relatos de experiência do projeto. Perceba que dentro do projeto haviam operações, que são essas atividades por vezes cíclicas que são importantes, como tampar os telescópios um dia depois da observação para não acumular umidade e ter que limpar o espelho (o que é fácil de quebrar, difícil de executar e trabalhoso de fazer).

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

🟢 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: Por que código bom não basta?

É necessário adotar esses processos formais de gestão justamente para evitar falhas humanas como a má gestão, em que as tarefas são mal distribuidas sobrecarregando apenas alguns dos desenvolvedores e a falha de comunicação em que erros e bugs são deixados no código e não são comunicados com a equipe, causando problemas futuramente.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder o bug no código, ele pode causar problemas onde que outros desenvolvedores não irão achar, enquanto que reportá-lo durante uma reunião pode ajudar a entender como evitá-lo e possíveis outros bugs. Nos dois casos a produtividade da equipe é afetada.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Safricar a qualidade do código em prol do prazo pode vir a se tornar um problema para a equipe devido a como o código pode ter sido escrito podendo se tornar não legível, ou não ser escalável

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Visando utilizar o Triângulo de Ferro na negociação com a diretoria, e sabendo dos três vértices do triângulo, seria necessário negociar sobre o Escopo visando o reduzir sua quantidade para manter uma boa qualidade do software, visto que com menos tempo e menos recurso (monetário), para que o software não seja entregue com uma má qualidade, é preciso reduzir sua quantidade de funcionalidades para que seja devidamente testado e seja entregue sem bugs e defeitos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Durante experiências passadas na faculdade, os “projetos” poderiam ser classificados como os trabalhos passados pelos professores e as “operações” seriam os exercícios passados para consolidar o conteúdo.

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: Por que código bom não basta?

Existem duas razões humanas que fazem com que a adoção de processos de gestão sejam essenciais no desenvolvimento de um projeto. A primeira é a falha de comunicação entre as pessoas envolvidas no projeto onde o produto a ser desenvolvido pode ter seu escopo mal definido se todas as partes envolvidas no projeto (Desenvolvedores, Product Owner e cliente) não possuírem o conhecimento detalhado do que está sendo criado. Já a segunda razão é o ego da equipe onde a vergonha e medo de admitir dificuldades ou até de reportar um erro cometido pode acarretar na quebra total do código ao longo do desenvolvimento do restante do projeto devido a base do código ser totalmente instável.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder um bug a fim de cumprir um prazo durante a produção pode causar problemas graves visto que toda a equipe continuará desenvolvendo o restante do sistema em cima de um problema existente sem possuir noção dele, logo quando o erro quebrar a implementação e ficar exposto para toda equipe, a quantidade de tempo para corrigi-lo será bem maior já que também será necessário modificar todas as outras partes que foram construídas se baseando neste código com bug também terão que ser modificadas. Agora, se o problema for reportado assim que identificado, será feito um planejamento coletivo para avaliar o bug de forma que ele seja corrigido o mais rapidamente possível sem danificar futuras partes do sistema, garantido então o controle e estabilidade do projeto.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código a fim de cumprir um prazo se torna uma “bomba-relógio” futuramente porque a instabilidade e os problemas deste código ruim não desaparecem com a entrega dentro do prazo e sim apenas adia estes erros para o futuro. Quando for necessário implementar algo novo dentro do código instável, é bem provável que seja necessário gastar muito mais tempo corrigindo as partes problemáticas e mal feitas para que o sistema não quebre totalmente do que necessariamente priorizar a nova funcionalidade. Este problema acarreta na redução dos prazos novamente devido ao tempo mal gasto e gera assim um ciclo vicioso de prazos curtos e códigos mal implementados.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Sabendo do prazo reduzido, do custo inalterado e conhecendo o triângulo de ferro formado por tempo, custo e escopo mantendo sempre a qualidade independentemente, eu explicaria para a diretoria a inviabilidade de manter o escopo do projeto com a redução de tempo sem aumentar gastos e, aplicando o conceito de MVP (Minimum Viable Product), faria uma lista com todas as funcionalidades a serem implementadas e buscaria tomar uma decisão conjunta com a diretoria para separar quais funções são essenciais e inegociáveis e quais podem ser adiadas para uma atualização futura a fim de manter os limites do prazo.

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

📝 Questão 1: Projetos vs. Operações na Prática

Um projeto é um atividade realizada ao longo do determinado tempo com o objetivo de atingir um resultado único como a criação de um produto. Exemplos: Trabalhos de faculdade como a criação de uma plataforma web usando Angular e Spring Boot, criação de um sistema de recomendação com todas as suas regras, montar no simulador um processador MIPS monociclo funcional.

Já uma operação se trata da realização de uma tarefa contínua e repetitiva sem um prazo definido a fim de manter algo pré-estabelecido. Exemplos: Estudar para provas a fim de manter meu nível acadêmico, realização de atividades e avaliações acadêmicas recorrentemente como questões de maratona de programação em Java, resolução de listas de exercícios, etc.

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: Por que código bom não basta?

Uma boa gestão é indispensável pelo fato da falha humana em vários âmbitos, por exemplo um desenvolvedor falar que tal estrutura funciona melhor que outra sem realmente ter o dado daquilo, o gerente do projeto não conseguir alinha com o cliente o que realmente o sistema feito precise cobrir. Temos vários outros exemplos que mostram como um alinhamento de equipe constantemente é importante para manter a coesão e sucesso do trabalho, além de uma checagem com os avanços das tecnologias presentes.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ficar escondendo bugs por questão de metas e prazo é uma prática errada e com certeza pode causar danos lá na frente que podem ser muito mais complexos de serem corrigidos. Reportar um bug precocemente em uma reunião de alinhamento é a prática correta para um desenvolvimento adequado de um projeto. Talvez a linha entre essas duas decisões seja bastante tênue.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Isso prejudica em vários aspcetos do projeto, por exemplo, futuras correções podem ser mais difíceis ou até inviáveis, pode ocorrer conflito com uma nova estrutura e novas funcionalidades, o entendimento do código por novos devs entre outros. O barato que sai caro.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Diria que não é possível entregar o projeto inteiro como especificado no escopo, adiantando o prazo de entrega e não contratando novos devs para adiantar o processo. Uma solução de entrega do sistema seria abordarmos as funcionalidades com maior prioridade para o funcionamento do sistema e depois complementá-lo , caso fosse possível.

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

📝 Questão 1: Projetos vs. Operações na Prática

Minha experiência aqui no CEFET-MG até agora foi muito mais voltada para operações do que para projetos. Considero operações, basicamente, como a resolução de um determinado problema utilizando uma estrutura de dados e linhas de código. Já os projetos, por terem início, meio e fim, envolvem muito mais organização, separação de papéis e planejamento, além de um acompanhamento, como, por exemplo, por meio de um projeto no Trello. Alguns exemplos foram os sistemas desenvolvidos nas disciplinas de Desenvolvimento de Sistemas e POO. Esses trabalhos exigiram toda a estruturação de um projeto, incluindo planejamento, acompanhamento e codificação.

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: Por que código bom não basta?

Duas das razões puramente humanas que tornam a adoção de processos formais de gestão indispnesáveis na área da engenharia de software são: falhas de comunicação e expectativas irreais. Durante meu tempo como presidente da empresa júnior, houve um projeto de e-commerce que a cliente tinha a expectativa de integrar com o ERP dela. Essa integração não existia nativamente na plataforma de e-commerce que estava sendo desenvolvido o site e a equipe não tinha capacidade técnica de fazer isso do zero (expectativa irreais). Durante as sprints, houve troca de gestão (entrei como presidente) e o antigo gerente do projeto havia documentado que a situação do ERP havia sido comunicado com a cliente. Na reunião de apresentação, foi nos informado que a cliente mudou de ERP por recomendação do antigo gerente do projeto que acreditava que esse ERP novo integrava (não integrava) e a bomba caiu sobre mim (falhas de comunicação).

Listei esses dois exemplos para sustentar que falhas de comunicação acontecem mesmo em ambientes de trabalho próximos (empresa junior são todos estudantes) e, ao parecer algo leve, podem gerar consequencias gravíssimas, como o exemplo citado acima que por pouco não terminou em disputas judiciais. Expectativas irreais também devem ser controladas pois, ao prometer um escopo que você não pode entregar, você falha como prestador de serviços ao acordar com escopo em que o contexto é inviável, como aceitar fazer um ERP do zero sem equipe qualificada.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Na prática, você vai apenas postergar o descobrimento do bug. Em produção, um usuário vai bater nesse bug e reportar aos donos do aplicativo. Um bug reportado em produção e que afeta o cliente é muito mais grave do que um bug reportado no andamento da task. Além de afetar o negócio da empresa, vai também afetar as relações interpessoais que existem em um ambiente de trabalho em equipe.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

A medida proposta pelos times imaturos é uma bomba-relógio pois, muito provavelmente, esse código ficará confuso, difícil de alterar e ilegível. Dessa forma, a refatoração desse código vai gerar um retrabalho enorme, contrariando expectativas de uma manutenção pontual nos fluxos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um conceito que utiliza da analogia de um triângulo em que as três arestas desse triângulo são: escopo, tempo e custo. Na situação em que alguma dessas arestas é puxada (no caso, aumentada), afeta as outras arestas do triângulo. No cenário em questão, o tempo é diminuído e o custo é mantido. O escopo desse projeto deve ser negociado de maneira em que se busca equilibrar com o tempo afetado. Negociaria um escopo mais simples para atender ao tempo e custo do projeto.

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

📝 Questão 1: Projetos vs. Operações na Prática

Uma atividade que foi um projeto foi o trabalho prático final do técnico em Desenvolvimento de Sistemas. Nesse caso, o objetivo era a implementação de um sistema de cadastro de clientes e consultas para um dentista, algo simples hoje em dia, mas foi bastante desafiador na época (2022). O projeto contou com toda a etapa de planejamento de sistemas: entrevista, levantamento de requisitos, design, desenvolvimento, testes, implementação e manutenção. Outra atividade que é uma operação é, no estágio que atuo, atuo na manutenção e atualização de uma aplicação web. Separo esses dois mundos principalmente pela gestão, pois no projeto o escopo é bem definido e as operações diárias com o time são bastante distintas em uma atividade do tipo operação, que o escopo é mais aberto e o objetivo não é criar, e sim melhorar algo que já existe.

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

🟢 JOÃO CARLOS FERRE. (Matrícula: 20213003750, Login: @joaocarlos.fm)

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

📝 Questão 5: Por que código bom não basta?

A adoção desses processos formais evitam que existam falhas de comunicação entre os envolvidos em que o entender do problema seja diferentemente interpretado entre os desenvolvedores, cliente e gestores que podem entender requisitos e funcionalidades de maneira diferente. Essa implementação também evita expectativas irreais acerca do projeto em que o balanço entre escopo, tempo e custo deve ser devidamente discutido e analisado para evitar risco no desenvolvimento.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Reportá-lo incialmente em uma reunião de alinhamento evita que o bug gere erros e problemas ao cliente, que podem descredibilizar o produto da empresa. O bug encontrado deve ser relatado e corrigido assim que possível para evitam problemas posteriores.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Esse sacrifício gera a consequência da presença de erros e funções do projeto sem a devida atenção. A bomba-relógio vem quando o cliente se torna insatisfeito com a entrega, gerando problemas para a empresa.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Eu iria propor despriorizar alguma funcionalidade não essencial presente no sistema devido o tempo reduzido do projeto. Essas funcionalidades podem ser incluídas em versões futuras do sistema e o sistema fundamental seria entregue mesmo com a retirada de um mês do tempo previsto.

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

📝 Questão 1: Projetos vs. Operações na Prática

Os projetos contam com datas de entregas predefinidas e aspectos característicos bem particulares enquanto as operações seguem como manutenção e inclusão de novas infraestruturas. O foco principal é dado aos projetos onde encontram expectativas e satisfação do cliente enquanto a manutenção serve como aprimoramento e correção de bugs internos.

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: Por que código bom não basta?

Primeiro temos as falhas de comunicação, em uma equipe quando está em um projeto de software acontece muitas falhas de comunicações como erros não reportados (como respondi na última questão) que podem trazer grandes atrasos, e interpretações de requisitos que muitas vezes pode haver ambiguidade entre os devs, por isso é necessário as reuniões para o alinhamento de visão e evitar mal entendidos.

E também as Expectativas Irreais, muitas vezes nas reuniões com os clientes eles criam expectativas muito grandes com quantidade de funcionalidades no software, eles acabam achando que é possível fazer tudo em um curto período de tempo sendo que isso é muito difícil. Por isso deve-se ter uma metodologia onde tenham reuniões, e com elas deve-se decidir prazos e mostrar as evoluções de cada etapa do projeto para o cliente.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug em baixo de um tapete para entregar o software dentro do prazo é um tiro no pé, uma hora ou outra ele vai interferir no seu projeto trazendo erros ainda maiores que podem atrasar uma próxima etapa. Isso acaba trazendo uma grande dor de cabeça para todo o time que está no projeto. Já reportar ele em uma reunião de alinhamento de equipe é o ideal, pois através desse feedback a equipe pode ser direcionada para resolver esse problema o mais rápido possível para continuar o andamento do projeto. E com isso é evitado grandes erros futuros no software.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Pois isso acaba virando uma bola de neve, após essa entrega do software pode ter outras entregas, e você não consegue voltar para resolver os problemas. Quando você for mexer neles já não lembra mais qual o processo que foi feito e assim demora muito mais tempo para resolver os erros. Esses erros podem atrapalhar a velocidade do software e deixar ele mais lento. Também na nossa área as vezes os desenvolvedores acabam saindo rápido das empresas, e com o código mal feito os outros que forem corrigir acabam tendo grande dificuldade, por falta de documentação e conhecimento sobre como o software foi criado.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Explicaria que não é possível entregar o software 100% com esse adiantamento. Eu poderia dar opções de como entregar ele mas com menos funcionalidades, primeiro entregaria ele com a funcionalidades mais importantes e depois com o tempo as demais, essa é a única forma que penso para poder “adiantar” o processo sem perder muito a qualidade do software.

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

📝 Questão 1: Projetos vs. Operações na Prática

Projeto é a criação de um aplicativo ou um site/sistema como fizemos em Desenvolvimento de Sistemas no semestre passado, em que nele decidimos que iriamos fazer um sistema de posto de saúde e com isso foi definido a tecnologia que íamos usar, tínhamos data de entrega e também tínhamos uma “conclusão” que era as funcionalidades que o professor pediu que tivesse para conseguirmos 100% da pontuação.

Já as operações é após já estar no ar, elas são monitorar o sistema, corrigir falhas inesperadas descobertas e aplicar atualizações para corrigi-las e também melhorar o sistema, isso tudo é uma rotina contínua.

As diferenças são que o projeto é “temporário” pois tem data de início e uma data de término planejadas e quando é alcançado o que deseja o projeto encerra, já a operação é contínua pois não tem ponto final definido, ela se repete de forma permanente enquanto o sistema ou serviço estiver funcionando.

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: Por que código bom não basta?

Pessoas em geral tem dois grandes problemas que justificam a adoção desses processos, que são subestimar o tempo e esforço necessários para a realização de uma tarefa e o péssimo hábito de só se preocupar em realizar as tarefas quando o prazo final de entrega se aproxima, como eu nessa atividade. Sendo assim, mesmo um profissional experiente pode não considerar todas as variáveis envolvidas em determinadas etapas do projeto, o que pode ser parcialmente solucionado com a elaboração de documentação detalhada, cronogramas e análise de risco por uma equipe, trazendo diferentes visões e vivências para o projeto, considerando muitas obrigações e situações que podem surgir. Além disso, dividir um grande projeto em pequenas e frequentes entregas é uma maneira eficiente de acompanhar a evolução do software e garantir que os profissionais envolvidos não vão procrastinar eternamente, acumulando o serviço e não entregando o que foi proposto em tempo hábil.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug debaixo do tapete para cumprir um prazo imediato não faz com que o problema real desapareça e que as coisas continuem fluindo. Muitas vezes um bug em uma determinada etapa do projeto afeta negativamente todas as etapas subsequentes, gerando dois tipos de desgastes. O primeiro é que em algum momento esse bug vai ter que ser resolvido, então os desenvolvedores terão que dedicar tempo a uma etapa que já deveria estar concluída, trazendo consigo todos os problemas citados na questão 3, e a outra é que nem sempre quando alguma coisa der errado lá na frente vai ser evidente onde está o erro, então surge outro gasto de tempo e perda de produtividade que atrapalham o cronograma do projeto, uma vez que encontrar o que está gerando um erro ou bug nem sempre é uma tarefa trivial, muitas vezes não fica clara a relação entre fases já concluídas e um bug inesperado na fase atual. Em contrapartida, reportá-lo precocemente pode atrasar ligeiramente o cronograma original, mas garante que não será dedicado a essa situação mais tempo do que o estritamente necessário, com esforços dedicados para a resolução do problema, proporcionando tranquilidade e confiabilidade para o seguimento do projeto.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código como “variável de ajuste” para cumprir um prazo é uma bomba-relógio para a equipe porque pode resultar em um software que não foi testado adequadamente, com bugs e falhas críticas de funcionamento que passaram despercebidas, gerando uma situação de estresse e desgaste quando esses problemas se tornam evidentes e a equipe tem que trabalhar em dobro e sob pressão para resolver os problemas em tempo recorde. Além disso, na prática, o ciclo de vida do projeto não termina na entrega do software, e a equipe que deveria focar em outras fases desse projeto ou em outros projetos fica presa a essa situação e a um projeto ou etapa que já deveria estar concluído, o que pode gerar um efeito dominó e atrasar outras fases e projetos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Existem três fatores principais atrelados à qualidade de um software: tempo, custo e escopo. Se o tempo diminui e o custo não aumenta para compensar é necessário promover mudanças no escopo do software, com o objetivo de não comprometer a qualidade, que é inegociável. Sendo assim, não é possível entregar o software completo e com qualidade diminuindo o prazo de entrega em um mês e sem contratar mais desenvolvedores, mas é possível entregar uma versão menor do software previsto originalmente, com algumas funcionalidades ou recursos a menos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Projetos de extensão eram claramente projetos, com suas etapas bem definidas de planejamento, execução e relatório final, e o decorrer de uma disciplinas envolve diversas operações, como o estudo contínuo, trabalhos, tarefas e provas. De modo geral, para separar o que são projetos e o que são operações envolve analisar o tempo e a complexidade envolvidos, atividades anteriores e os objetivos de cada um.

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: Por que código bom não basta?

Um exemplo bom para considerar uma estratégia de processos formais, é a linha do tempo da construção de um software, por exemplo, se cada pessoa fosse fazendo um módulo de qualquer jeito, sem considerar a ordem de criação dos módulos por exemplo, pode ocorrer um problema entre as versões dos usuários. Por exemplo, num hemocentro tem-se um módulo de registro de bolsa e outro módulo para os exames de sangue presentes na bolsa de sangue, se esses módulos forem feitas na ordem errada, ou sem pensar em como conectá-los, no final podem ter dois módulos bons, mas que simplesmente nunca se conectam, sendo que para uma bolsa ser registrada como apta no estoque obrigatoriamente ela tem que passar pela triagem dos exames.

Além de que as pessoas têm linguagens, frameworks e afins preferidos, se começam a produzir um software e cada programador escolhe sua linguagem de programação preferida, no final o programa vai ser um Frankenstein de linguagens que podem nem se comunicar direito.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Ao esconder o erro pra debaixo do tapete, você não o deleta, você apenas deixa ele lá, fazendo um paralelo com deixar uma agulha(bug) apontada para cima debaixo de um tapete(programa), podemos pensar que uma hora ou outra uma pessoa(programador) que constantemente passa por cima(programa) do tapete, eventualmente ele pode pisar nessa agulha que está escondida e se machucar(problema no programa). Entretanto, se fosse relatado precocemente para as pessoas da casa que uma agulha estava lá, elas poderiam ter retirado a agulha.

A principal diferença de reportar um bug precocemente, é a possibilidade de adequar o escopo para consertar aquele problema, sem abrir mão da qualidade do programa, mesmo que ele seja atrasado, vai evitar que o triângulo de ferro seja prejudicado.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

“Uma hora o preço será cobrado”.

Primeiramente, adiar consertar partes de um programa pode ser algo gritante pois, ao tentar arrumar algo para deixar correto, você pode acabar quebrando a estrutura de outro local do programa, causando assim um efeito em cascata de problemas para serem resolvidos. Segundamente, realizar um realise sem ao menos resolver os problemas que você sabe que existem, vai prejudicar as próximas atualizações do projeto. Por exemplo, ao realizar uma matéria no semestre anterior, conversamos com uma empresa que produz softwares para rádio, e nessa conversa foi indicado algo interessante para a gente.

Basicamente quando eles acabam uma release, eles realizam 3 etapas de teste sendo elas resumidamente: “o dev testa tudo e tenta consertar”-> passa pela equipe de teste de bugs->vai para clientes beta testers. Caso haja algum erro a “equipe dev” conserta. Mas algo interessante que foi falado é que diversas vezes, quando eles estão fazendo a release de outra parte do programa, de outra função, eles acabam encontrando erros de releases passadas. Ou seja, os programadores que fazem 3 testes deixam erros passarem sem querer, imagine programadores que “rusham” programas sem testes, o quanto de erros que vão aparecer.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um triângulo a princípio equilátero onde nas pontas dele tem-se: Tempo, Custo e Escopo, e no meio tem-se: qualidade. Não há como mexer em uma das pontas dele, sem prejudicar as outras, ou seja, se a gente tentar achatar o tempo, sem ajustar o custo e o escopo, o projeto terá uma queda de qualidade. Não há indicação se a equipe está trabalhando com cascata ou scrum, pois isso diferenciaria o triângulo em si. Mas de todo modo, caso fosse um com escopo variável ou não, o escopo teria que ser mexido para garantir a qualidade do projeto. Se o projeto tivesse menos tempo e o mesmo custo, para manter o triângulo equilátero, mantendo uma mínima qualidade, precisaria diminuir o escopo do projeto para evitar que tenham erros catastróficos.

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

📝 Questão 1: Projetos vs. Operações na Prática

Eu posso citar que as operações em grande maioria eram as atividades passadas pelos professores durante as semanas, em cada aula ou em conjunto de aulas, tanto em BD, quanto AEDI II, FP e afins existiam certas atividades para treinar algumas coisas. Por exemplo, em AEDI há uma atividade de fazer uma pilha ou fila.

Em contraste, diversas dessas matérias existiam projetos maiores, por exemplo, em “Desenvolvimento de Software”, tinham toda semana uma atividade para treinar, mas ao fim da matéria tivemos que entregar um aplicativo simples com endpoints, com mínimo funcionamento.

Em resumo, eu acredito que elas têm uma separação que causa uma união. Para realizar um projeto de início-meio-fim, você precisa saber construir as partes, e essas partes separadas você aprende com essas atividades isoladas, não me recordo se foi em POO ou AEDI, mas em dupla construímos um “sistema” de estacionamento, ele utilizava diversos conhecimentos, não dava para construir ele todo sem esses conhecimento que foram adquiridos aos poucos nessas atividades.

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: Por que código bom não basta?

Acredito que a personalidade individual de cada humano é um fator que acaba tornando a gestão algo indispensável. Muitas vezes encontramos e lidamos com colegas de equipe que não aceitam que também estão sujeitos a errarem ou que simplesmente vão repassando o erro para frente por puro egoísmo de não saber lidar com a culpa. A falha de comunicação também pode ser citada nesse sentido e muitas vezes também se relaciona com a personalidade. Percebo que muitos colegas da nossa área não são muito sociáveis, muitas vezes por receio ou vergonha de interagir com outro alguém e isso acaba criando barreiras dentro de uma equipe, que pode por consequência comprometer o projeto final. Algumas pessoas costumam deixar algo passar simplesmente para não ter que lidar com o que a outra pessoa pode falar, por acabar gerando raiva, intriga e entre outras relações ruins. Isso costuma se acumular e fatores pequenos e de pouca relevância se tornam grandes e perceptíveis.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Podemos fazer uma analogia com educação financeira. Escolher esconder esse bug seria equivalente a não pagar determinada dívida em seu determinado prazo. Essa situação gera juros que quando a pessoa se der conta, ela vai estar pagando mais juros do que o próprio valor inicial. De mesmo modo, esconder um bug ao invés de reunir e se dispor a corrigi-lo, trará problemas ainda maiores que podem eventualmente acabar se tornando tão maiores quanto o pressuposto inicialmente. A manutenção que inicialmente poderia ser simples, irá ser algo complexo, o que te torna vulnerável a mais e mais bugs em um efeito dominó.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Acredito que pode se tornar uma bomba-relógio pois essa falta de cuidado que você tem no momento em que decide entregar antes mesmo que com menor qualidade, necessariamente retorna a você e muitas vezes em uma escala maior, quando você for de fato corrigir (“depois a gente arruma”). Nesse patamar, seu cliente ja vai estar em uso do site e pode acabar encontrando dificuldades que você nem tinha sequer se preparado para lidar. Dessa forma, o trabalho que você deixou de ter ao tomar essa decisão, simplesmente foi adiado e se tornou pior do que era no passado, por pura e simples ignorância, preguiça, mas normalmente por pressão também. Código ruim, se torna difícil de ler, alterar então se pagam juros muito altos por um prazo que nem sempre costuma chegar.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro conceitua a união de 3 aspectos no âmbito da gestão de projetos: escopo, tempo e custo (formando um triangulo). Essa união implica que, ao alterar um dos lados do triangulo, altera também os outros dois e por consequência a qualidade final do projeto. No caso dessa questão, houve uma diminuição de tempo e além disso o orçamento vai se manter, pois não querem contratar mais desenvolvedores. Para negociar essa situação, o único lado do triângulo restante é o escopo, que para manutenção de qualidade, precisa ser reduzido, assim como o prazo foi, caso contrário, não será possível entregar o que foi projetado com a mesma qualidade presumida inicialmente.

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

📝 Questão 1: Projetos vs. Operações na Prática

Acredito que os exemplos mais comuns de projetos eram os próprios trabalhos práticos. Normalmente eram planejados, feitos e depois de apresentados/entregues provavelmente não voltaríamos a vê-lo (talvez era interessante fazer isso, mas nunca ocorreu). Um exemplo de operação é o ato de estudar (do mundo das ideias), pois é algo que está em constante manutenção, precisa ser feito diariamente para construir o conhecimento e não tem fim no período determinado pela faculdade e enquanto estiver no mercado de trabalho, pois enquanto um bom profissional você precisa se atualizar sobre aquilo que compõe sua bancada de trabalho, normalmente estudando.

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: Por que código bom não basta?

O primeiro ponto acredito que seja a organização, pois com a Gestão Ágil conseguimos controlar as entregas e as datas sem extrapolar e subestimar o projeto, ou seja, sempre estaremos trabalhando e finalizando tarefas de uma forma mais controlada, sendo assim muito mais fácil saber se nosso progresso vai ser o suficiente para entregar no prazo, sem isso poderíamos ficar perdido nas entregas e mantermos uma expectativa falsa que esta tudo no tempo certo. O segundo ponto pode ser uma confiança excessiva do desenvolvedor com o próprio código, mas como a gestão ágil geralmente separa o tempo para revisão em que outra pessoa vai validar o que foi feito, esse problema é mitigado.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Acredito primeiramente que dependendo do bug essa acao de esconde-lo é um grande risco a todo o projeto, pois a gravidade pode ser grande caso esse bug gere danos aos usuarios do sistema, como vazamento de dados. Em paralelo acredito que nao ajustar um bug pode gerar um acumula de códigos errados na codebase, que no longo prazo pode se tornar inviavel corrigir tudo sem fazer grandes alterações no projeto, por ultimo, podemos falar na confiabilidade e transparência que voce vai ter com a equipe, tendo em visto que todos estao la para fazer algo de qualidade e sabem que podem contar com seu trabalho.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Eu penso que em primeiro lugar pode estar a variável de segurança, acredito que sacrificar a qualidade do código pode gerar falhas e vazamentos de dados que depois podem gerar danos graves ou ate irreversíveis para empresa.Em segundo, é fato que no mes seguinte teremos retrabalho nesse codigo, so que agora podemos ja estar atuando em outros escopos, alem de que a correção de um projeto que esta em produção da muito mais trabalho, ou seja, pode ser que eu nao consiga mais chegar na qualidade de projeto que eu iria ter se tivesse ajustado o prazo de forma correta e tivesse feito uma primeira versão com qualidade.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Explicaria que eles estao mexendo na variavel tempo diminuindo o tempo proposto, mantendo o custo, entao o escopo do projeto seria afetado. Com esse escopo do projeto sendo afetado alguma funcionalidade ou varias funcionalidades do sistema seriam comprometida, eu daria a sugestao de adiar a construcao de alguma parte do sistema para depois, assim eu equilibraria o escopo com tempo e custo novamente, eu vejo como a melhor solucao para nao comprometer a qualidade.

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

📝 Questão 1: Projetos vs. Operações na Prática

Em minha experiência profissional, consigo perceber que existem iniciativas que são projetos, principalmente relacionadas a coisas novas. Mais especificamente no meu contexto, poderia citar a construção de um pipeline de transformação, limpeza e deploy de um dado novo que está chegando à empresa. Nesse cenário, conseguimos identificar mais claramente um início, meio e fim.

Contudo, no meu contexto, existem também operações de atualização de dados, que têm suas datas definidas, como de mês em mês ou de seis em seis meses. Essas tarefas são mais rotineiras e contínuas. Além disso, um projeto construído que é finalizado, depois de um tempo, provavelmente passa para um status de manutenção, em que, de forma contínua, vamos conferindo seus resultados e ajustando seu fluxo.

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: Por que código bom não basta?

Eu não acho que o motivo da necessidade de gestão formal é humana. Gestão só é uma parte importante de sistemas complexos onde se deve haver comunicação entre suas partes. Um projeto de software, mesmo duas pessoas colaborando em um programa simples, é um sistema complexo.

Pense sobre a internet: para baixar uma página web, você precisa de dividir o arquivo HTML em partes, e encapsular estas partes cada uma em uma pilha de pacotes IP/TCP/HTTP. Sendo que TCP e HTTP devem primeiro abrir e depois fechar uma conexão com o servidor de origem. Todos esses headers de protocolos e estabelecimento de conexões são artefatos de “gestão:” comunicando informação entre partes para garantir realização de uma tarefa complexa. Neste exemplo não tinham pessoas envolvidas mas mesmo assim há um grande overhead de gestão.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Se reportar o bug antes tem uma chance maior de ele ser resolvido antes do software ser entregue. Também acaba não desperdiçando recursos de QA com achando bugs já descobertos.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Por que no mês seguinte existirão os prazos do mês seguinte E os ajustes necessários.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O escopo é o tamanho de um projeto. Os objetivos do projeto projeto teriam que ser reduzidos para permitir a manter o custo e tempo baixos como exige a diretoria.

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

📝 Questão 1: Projetos vs. Operações na Prática

Eu só tive “projetos” na minha formação acadêmica. A maioria foram tarefas dados por professores com data de entrega. A única exceção foi o semestre passado com o Mundo do Código.

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: Por que código bom não basta?

As falhas de comunicação são o maior motivo para a adoção de um processo formal de gestão para um projeto de software; é impossível saber o que se passa na cabeça das pessoas que estão em conjunto desenvolvendo o projeto, ou até mesmo a do cliente; a forma de implementação de uma feature pode ser passada de forma muito vaga por um superior, ou uma pessoa pode ter opiniões ou um estilo de trabalho totalmente diferente de uma outra, ou um cliente possui uma visão muito irreal sobre o que o projeto se propõe a ser. Sem uma hierarquia e processos formais bem definidos, a informação pode ficar muito concentrada em um só lugar, sem circulação e alinhamento, e o processo totalmente desajustado, gerando trabalho para todos os envolvidos. Um processo formal se mostra indispensável para ajustar e alinhar a todos.

Um outro motivo para a adoção de processos formais de gestão são os imprevistos no projeto; são comuns e, sem um método de gestão formal, esse imprevisto gera discussões entre a equipe, trabalho excessivo e mais problemas derivados a esse, se não houver uma solução eficiente. Em um processo formal de gestão, basta incluir a demanda atrelada ao imprevisto na fila de prioridades, ou reorganizá-la e reordená-la com base na capacidade atual do time (no caso de alguém sair da equipe, e não houver alguém para substituir; haverá trabalho extra mas é possível mitigar esse problema). Essencialmente, um processo formal de gestão de software é imprescindível para gerir e mitigar imprevistos em um projeto.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Embora esconder um bug pode diminuir a carga de trabalho imediatamente, isso cria um problema que inevitavelmente precisará ser resolvido mais na frente; seja ignorando-o ou simplesmente “resolvendo-o” com uma solução mal-feita, isso aumenta a complexidade de resolver o problema a longo prazo, visto que o sistema já estará mais complexo do que no momento em que o bug foi notado, além de poder quebrar outras partes do sistema completamente não-relacionados ou até gerar outros problemas derivados desse, além de abaixar muito a qualidade do software.

Reportar o problema precocemente permite traçar um plano para a correção do bug com mais pessoas de forma a não afetar o resto do sistema, agindo na raiz do problema e trabalhando em prol de um produto mais robusto. A longo prazo, isso melhora a qualidade do software entregue, permite uma maior previsibilidade, com as estimativas de entrega levando em conta esses problemas ao longo do caminho, além de promover uma maior transparência e menos retrabalho para a equipe, já que o problema vai ser resolvido uma vez, documentado, e não será necessário voltar nele; o foco poderá ser em uma nova funcionalidade.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Um código feito às pressas e sem o devido cuidado pode resolver o problema temporariamente e, embora possa bater o prazo, o ganho de tempo feito com um código frágil é totalmente perdido quando se precisa corrigir falhas e desvendar um código caótico e sem sentido.

Essencialmente, isso gera problemas futuros no sistema ao escalá-lo para algo maior, gerando bugs, dificuldade de leitura, falta de documentação adequada e falta de testes adequados, podendo quebrar partes do sistema que já existem, além do tempo alocado da equipe em sprints posteriores não estar destinado a trabalhar em novas funcionalidades para o projeto, mas sim a corrigir erros e “desvendar” (quase que literalmente) o que eles haviam feito para conseguir darem seguimento ao projeto.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um conceito da gestão de projetos que relaciona as três principais restrições de um projeto: escopo, prazo e orçamento, ao passo que, mudar qualquer um dos três inevitavelmente muda os outros dois, e também incide necessariamente na qualidade.

No caso apresentado, as duas principais variáveis em questão são o prazo e o orçamento. O problema do prazo ser antecipado pode ser mitigado ajustando uma das outras duas variáveis: o orçamento não é o caso, visto que não haverá aumento de orçamento para a contratação de mais desenvolvedores. Sendo assim, o escopo precisará ser negociado.

Não é possível manter o projeto do jeito que está (visto que, sua previsão normal seria ter um mês a mais de desenvolvimento); dessa forma, haverá a necessidade de retirar funcionalidades para entregar o projeto dentro das restrições de prazo e orçamento, focando mais nas funções principais. O valor entregue ao cliente será menor, as chances da qualidade do produto entregue ser menor do que em relação a um cenário normal são bem maiores, e talvez seja necessário implementar esses ítens posteriormente, sendo o trade-off necessário para conseguir entregar esse projeto devido às alterações nas variáveis.

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

📝 Questão 1: Projetos vs. Operações na Prática

Na faculdade, as atividades que eram “projetos” eram, principalmente, os trabalhos de alguma disciplina, como um código para resolver um problema em específico ou a modelagem de uma CPU didática: tinham um objetivo e escopo claro, com início, meio, fim e uma data de entrega; não se fazia uma manutenção ou havia algum tipo de continuidade nesse trabalho depois de entregue. Assim que finalizado, não havia mais nada a se fazer.

A atividade mais marcante de operação que fiz em projetos passados foi um pequeno bot feito em Java para a plataforma Discord, com a finalidade de tocar músicas. Como era algo mais pessoal e, principalmente, feito para amigos, não havia um escopo muito claro (embora esse não seja o caso, necessariamente, para uma operação!). Ao invés disso, toda funcionalidade que eu achasse interessante (ou que me recomendassem, ou que eu achasse engraçada), inevitavelmente acabaria sendo adicionada, além dos fatos de ter que lidar com as APIs, bibliotecas quebrando, tendo que ser atualizadas e trocadas; essencialmente, o cuidado precisava ser muito maior, e era uma checagem contínua e quase diária para garantir que o bot estava funcionando corretamente.

Essencialmente, um projeto é algo delimitado e temporário, com início, meio e fim e com a finalidade de criar algo único, e acaba assim que as metas forem atingidas. Uma operação é algo mais contínuo, sem uma data para acabar, geralmente sobre um mesmo objeto e de forma repetitiva.

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: Por que código bom não basta?

Como um projeto não é só código e envolve pessoas ele está suscetível a erros. Um deles é a falha de comunicação, por exemplo: uma funcionalidade do sistema é solicitada pelo cliente, mas mal interpretada pela equipe e, posteriormente entregam algo errado. Outros exemplo é colocar expectativas irreais, por exemplo: solicitar um tempo menor que o normal para desenvolver algo que leva tempo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Mesmo que o erro seja escondido, ele continuará existindo e com o avanço do projeto poderá se transformar em uma bola de neve e comprometer todo o projeto. Ao reportar o erro imediatamente e com transparência, a equipe consegue corrigir o problema antes que ele cause consequências maiores.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Eu acho que fazer esse código “de qualquer jeito” só para cumprir o prazo pode gerar problemas futuros, porque seria necessário mais tempo para organizar essa bagunça. O que pode gerar mais custo e tempo no projeto desse software.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro traz o conceito de tempo, custo e escopo. Nessa situação apresentada o tempo diminuiria e o custo continuaria o mesmo, sem aumento do orçamento. Ao meu ver, seria melhor priorizar o escopo, entregando inicialmente as funcionalidades essenciais para que o software funcione.

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

📝 Questão 1: Projetos vs. Operações na Prática

As atividades que se enquadram como projetos e que eu me lembro de realizar são: o projeto da matéria de DS e trabalhos da Iniciação Científica. Já as operações são: estudar para as provas, assistir às aulas e acessar o SIGAA. Nos projetos, como eles possuem um prazo maior para serem realizados, costumo dividir as atividades em partes ou etapas. Já as operações são atividades recorrentes que são realizadas com maior frequência e sem ter um fim necessariamente.

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

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

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

📝 Questão 5: Por que código bom não basta?

R: Não basta haver a competência técnica para desenvolver o software, é necessário ter certeza de que tudo o que está sendo construído está de acordo com o que é idealizado pelos clientes e projetistas, e envolvimento de toda equipe para entender como cada face do projeto está em andamento e se comporta. Além disso, esses processos mitigam o problema da criação de expectativas irreais a respeito do projeto, como propor a elaboração de um escopo muito grande para um projeto tal que não é praticável pelas limitações de orçamento, deixando o cliente ciente de tudo o que pode ou não ser desenvolvido.

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

📝 Questão 4: Esconder Bugs vs. Transparência

R: A principal diferença é que reportar de antemão um problema, seja um bug ou falha no projeto de escondê-lo da equipe para entregar o mais rápido possível é que no primeiro caso é aberta a oportunidade de toda a equipe se unir para decidir como remediar a questão sem que surjam novos problemas ou encontrar métodos para não comprometer a qualidade do software que será disponibilizado ao cliente, o que pode gerar prejuízos avassaladores, no segundo caso os bugs podem causar problemas para todos os envolvidos, escalar em bugs ou problemas maiores futuramente e dificultar a manutenção do software.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

R: Porque um código mal desenvolvido tende a ser pouco ajustável para manutenções e alterações do projeto, fazendo com que a escalabilidade do que foi desenvolvido seja comprometida e que os desenvolvedores tenham o retrabalho a posterior de codificar um novo trabalho ou de lidar com a correção de bugs e problemas em larga escala, atrasando toda a cadeia produtiva.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

R: O conceito do triângulo de ferro é uma premissa de que há três pontos fundamentais na gestão de um projeto: escopo, prazo e custo do projeto. Se uma dessas grandezas sofrer aumento ou redução as demais grandezas devem ser alteradas também para que a qualidade do projeto não sofra maiores danos. Nesse caso o orçamento do software se manterá fixo ao passo que é exigido que o prazo seja diminuído. Sendo assim, é necessário diminuir o escopo do projeto pois não serão contratados novos devs para acelerar a produção e continuar com o projeto inteiro pensado para o prazo anterior.

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

❌ Questões Faltantes

Questão 1: Projetos vs. Operações na Prática

🟠 SAULO DIAS DE OLI. (Matrícula: 20203013888, Login: @Saulo)

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

📝 Questão 5: Por que código bom não basta?

Organização e boas praticas, uma equipe com pensamento mais unido e alinhada no seu trabalho consegue contornar mais facil erros e ter clara comunicação do que cada um está fazendo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder Bug

pratica: gera problemas futuros por que o bug pode interferir em outras partes do processo acarretando uma cascata de problemas adicionais.

Longo prazo: Perca financeira, confiança do cliente e/ou usuários.

Reportar Bug

pratica: O problema se resume aquele bug, economizando esforço e tempo da equipe.

Longo prazo: um trabalho bem feito gera retorno satisfatório e possívelmente financeiro já que o cliente e/ou usuário teve ótima experiencia com o produto.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Basicamente o time empurrar o trabalho mais para frente, incluindo adicional de deixar o cliente e/ou usuários insatisfeitos e com pessíma impressão para a empresa, resultando também em perca financeira e até mesmo atraso de outros projetos em cascata.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Como podemos ver pelo triangulo a base representada por tempo e orçamento estão mais afastadas simbolizando menor eficiencia e saindo do escopo, que e representado no topo da piramide, quanto mais baixo o topo, mais fora do escopo está, em resumo não é possivel com menos orçamento e tempo adiantar o projeto mantendo qualidade.

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

❌ Questões Faltantes

Questão 1: Projetos vs. Operações na Prática

🟢 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: Por que código bom não basta?

Dois dos fatores humanos que podem afetar um projeto, mesmo quando o código é bem feito, são:

1. Falhas de comunicação: informações podem não ser passadas corretamente entre a equipe, causando erros, retrabalho e decisões diferentes sobre o que deve ser feito.

2. Expectativas irreais: clientes ou gestores podem esperar resultados em prazos muito curtos ou com poucas pessoas, sem considerar a complexidade do projeto. A gestão ajuda a alinhar essas expectativas e definir prioridades.

Por isso, processos de gestão são importantes para organizar as pessoas, alinhar expectativas e evitar que problemas humanos comprometam o projeto.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Esconder um bug pode até ajudar a cumprir o prazo naquele momento, mas aumenta o risco de o problema se tornar maior e mais caro de corrigir depois.

Ao reportar o bug precocemente, a equipe consegue avaliar o impacto, buscar uma solução e ajustar o planejamento antes que ele afete outras partes do projeto. Isso também aumenta a confiança entre os membros da equipe e evita surpresas no futuro.

Portanto, a transparência pode gerar um impacto imediato no prazo, mas reduz os riscos e os custos no longo prazo.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código para cumprir um prazo pode parecer uma solução rápida, mas acaba gerando problemas maiores depois.

Um código feito de qualquer jeito tende a acumular dívida técnica, tornando mais difícil corrigir erros, adicionar novas funcionalidades e fazer manutenção. No mês seguinte, a equipe pode gastar muito mais tempo corrigindo esses problemas do que gastaria fazendo o código corretamente desde o início.

Por isso, cumprir o prazo sacrificando a qualidade pode apenas adiar o problema e aumentar o custo do projeto.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Neste caso, eu explicaria à diretoria que será necessário negociar o escopo do projeto.

O Triângulo de Ferro é formado por escopo, tempo e custo. Como o tempo foi reduzido e o custo permanece o mesmo, não seria viável manter todo o escopo original sem aumentar os riscos de atraso ou perda de qualidade.

Por isso, eu priorizaria as funcionalidades mais importantes para o lançamento e deixaria as menos urgentes para uma segunda etapa. Assim, mantgendo o prazo e o orçamento com uma redução controlada do escopo.

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

📝 Questão 1: Projetos vs. Operações na Prática

Na faculdade participo de uma atividade de extensão na qual é possivel ver claramente a diferença entre esses dois mundos.

Pegamos projetos de sites e sistemas onde definimos um escopo de desenvolvimento(inicio), depois desenvolvemos o site(meio) até sua finalização, aprovação da cliente e entrega(fim). Participei de um projeto da construção do site de uma advogada, onde tive a experiência de trabalhar em equipe e participar de todas essas fases do projeto.

Já quando falamos em operações, envolve toda a parte que é necessária no dia a dia para manter a empresa, como por exemplo reuniões, elaboração de contratos, protocolos, termos, contratação de ferramentas. Durante minha participação na empresa junior, tenho participado da diretoria jurídica, onde elaborei vários contratos e termos.

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

🟢 VICTOR GABRIEL MA. (Matrícula: 20203004575, Login: @vicmagione)

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

📝 Questão 5: Por que código bom não basta?

Muitas vezes ocorre de fazermos um código “gambiarra” para que o sistema funcione, isso a longo prazo pode causar alguns problemas, caso essa função crida seja usada por outras funções e dependem dele para o funcionamento correto, com isso essa “gambiarra” vai se acumulando, de forma que num futuro 1 leve bug nessa função inicial demore muito para ser corrigido.

E também ocorre de criar uma expectativa maior para o cliente e na entrega final não comprir com essa expectativa criada, e ter apenas 50% do que foi dito que teria, pois ou não teve tempo de criar as funções ou simplesmente não teve a capacidade mesmo.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Se for escondido, esse bug pode acabar sendo esquecido e causando problemas para o cliente num futuro, porem se for um bug não muito perceptível ele pode acabar sendo irrelevante. E se for reportado terá de ser feito uma analise e demandar um leve custo e tempo para resolve-lo, e se fosse imperceptível teria sido um gasto “atoa”.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificando a qualidade, podemos ter um possível redução de custos e entrega mais rápida, porem se nos mês que vem não tiver a mesma dedicação, para resolver o código, pode acabar se tornando uma bola de neve, de forma que outras partes do código começam a depender da parte já feita, e para altera isso só demoraria mais tempo.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Tem de ser feito um ajuste do escopo, pois se reduzir o tempo e não tiver um orçamento melhor o escopo cai significativamente seguindo a logica do triangulo de ferro.

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

📝 Questão 1: Projetos vs. Operações na Prática

Tive 2 “grandes” projetos durante a faculdade, o primeiro na disciplina de Desenvolvimento de sistemas, onde fiz um sistema de banco, em que o usuário podia depositar, sacar, transferir e criar um pix e utilizar esse PIX. E outro trabalho na disciplina de Contexto, que tive a oportunidade de fazer uma aplicação real dos meus conhecimentos, em que em conjunto com outra pessoa desenvolvemos um site para uma igreja de Timóteo, com front e back end. Foram projetos que tiveram que ser desenvolvidos com tempo e ajustes seja do professor ou da instituição que ajudamos.

Já operações sinto que o exemplo mais claro para mim são esses questionários e provas que possuem em toda matéria, que já fazem parte da rotina e surgem como manutenção.

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: Por que código bom não basta?

Dificuldade de Comunicação / Comunicação Passiva - Dificuldade em dizer não com a colegas de trabalho/ liderança com prazos e entregas irreais que não podem ser cumpridas.

Ego : Dificuldade em assumir erros e atrasos com prazos.

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

📝 Questão 4: Esconder Bugs vs. Transparência

Pois isso poderá gerar (e provavelmente irá) um efeito bola de neve, no qual pode acabar prejudicando toda a aplicação. Esse trecho com bug, pode ser utilizado em outras funções por outros programadores, e propagar mais erros. Além de que, corrigir um erro durante o processo de desenvolvimento é mais barato do que após a entrega para o cliente.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Quando eles se reunirem para corrigir esses bugs e erros nos quais eles entregaram será muito dificil pois o código não estará “fresco” na mente deles, e estará desorganizado, mal estruturado, tornando-se um código difícil de enteder e alterar, fazendo com que um erro ou bug que poderia ser resolvido rapidamente, levasse muito mais tempo.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é um modelo que afirma que 3 variáveis determinam a qualidade de um projeto, sendo elas o ESCOPO (o que precisa ser feito, funcionalidades, requisitos e módulos), TEMPO (quanto tempo o projeto vai levar pra ser entregue) e o CUSTO (quanto dinheiro e quantas pessoas serão investidos).

Na situação descrita, haverá uma redução no prazo(TEMPO), enquanto não haverá a mão de obra extra (CUSTO). Nesse caso, a unica variáavel que é possível alterar seria no escopo, ou seja, teria que mexer no escopo, removendo algumas funcionalidades e revendo alguns requisitos.

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

📝 Questão 1: Projetos vs. Operações na Prática

O projeto no qual já fiz foi uma modelagem completa de um sistema de Clínica Veterinária, onde foi feito todo o passo à passo do projeto (entrevista com o cliente, levantamento de requisitos, documentação, a modelagem) até a parte da implementação (back + front).

Outro projeto, foi a criação de um sistema de estacionamento onde apenas foi criado um sistema que registrava entrada e saída, alem de calcular o valor do mesmo. Além de era um sistema com foco em aplicação de conceitos de POO e funcionava apenas em console.

Quanto a operações, acredito nunca ter participado de alguma. Acredito que se o sistema da Clínica Veterinária fosse algo implementado no mundo real, as operações de rotina para manter o sistema em funcionamento como correções de bugs, backups do banco de dados se encaixariam bem nesse contexto.

A maneira como eu diferencio em temporalidade e objetivo. Os projetos tem data final (objetivo é entregar o sistema) e tem como objetivo criar algo novo, enquanto as operações são contínuas (duram enquanto o sistema existir) e tem como objetivo manter o sistema em funcionamento.

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: Por que código bom não basta?

Falha de Comunicação: Quando não existe uma comunicação efetiva entre duas áreas diferentes ligadas ao projeto já existe uma grande possibilidade do resultado estar distante daquilo que era de fato a necessidade o cliente, que é o que realmente precisa ser satisfeito. A comunicação com o cliente é o que mais precisa ser trabalhado, entender o que ele fala e ainda mais o que ele precisa através da observação do ambiente que a aplicação se tornará parte. Um código pode estar muito bem escrito para um contexto, mas também pode estar completamente distante daquilo que seria o ideal.

Expectativas Irreais: Quando um projeto impossível de ser executado, seja no sentido técnico, de custo e ou de prazo é vendido como uma realidade; um código bem executado não será capaz de suprir todas os requisitos simultaneamente. É necessário ter consciência daquilo que é ou não é real dentro do contexto que aqueles envolvidos nos projetos estão inseridos, a ausência dessa habilidade impossibilita a realização de um projeto satisfatório.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A diferença entre esconder um bug ou reportá-lo rapidamente está basicamente na grande diferença de problemas, financeiros e operacionais, que existirão para consertar esse bug, que mesmo sendo escondido, geralmente aparecerá em algum momento futuro. Quando o problema é reportado ainda em momento de desenvolvimento, os problemas serão mínimos, apenas de realmente refatorar o código ou a estrutura com pontos incorretos. Um problema escondido que é encontrado enquanto em operação, terá ser localizado de forma correta inicialmente, além de poder ter gerado outros problemas ligados a ele em série, além dos problemas sérios que aparecem quando esse problema tiver algo ligado aos dados permanentes do sistema, que podem ser muito sérios caso tenha sido populado massivamente.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Não ter a qualidade como ponto essencial desde o início de um projeto implica, com quase certeza, em sérios problemas para o futuro desse trabalho. Um projeto mal desenvolvido pode:

ter sérias falhas de segurança, que impactam diretamente o cliente e pode gerar problemas sérios;
possuir comportamentos que, em primeira instância parecem corretos mas futuramente se mostram como fora do esperado;
se tornar muito difícil ou impraticável de ser consertado a partir do momento que estiver funcionando, com banco de dados povoado ou implantado em um ambiente que a desativação é inviável;
ser um código muito mal estruturado em sua organização e escrita, que implica em baixa manutenabilidade, um sério problema para qualquer projeto que tome proporções maiores.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

O triângulo de ferro é uma forma de representar uma relação entre CUSTO, PRAZO e ESCOPO. Nele, afirma-se que não é possível ter uma melhoria em todos os quesitos simultaneamente, se eu quiser “melhorar” 2 deles, o terceiro tem que ser sacrificado e que, se algum dos três mudar, ao menos uma das outras variáveis terá que ser impactada também. Nesse cenário, foram impostas as restriçoes que: 1. PRAZO será diminuido e 2. Não haverá alteração no CUSTO ligado ao projeto.

Dessa forma, é necessário que o ESCOPO do projeto seja REDUZIDO para que as condições propostas sejam possíveis e a regra do Triângulo seja mantida.

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

📝 Questão 1: Projetos vs. Operações na Prática

É possível mencionar que o que foi desenvolvido ao longo da matéria de Desenvolvimento de Sistemas foi um "projeto": uma aplicação Web. Ela foi planejada, teve as etapa de desenvolvimento e chegou ao fim quando publicamos ela e foi avaliada dentro dos requisitos pedidos. Como "operações", poderia dizer que assistir às aulas de cada matéria durante todas as semanas e as entregas semanais ao longo do semestre de matérias de programação e até mesmo cálculo, podem ser mencionadas, pois ocorrem de forma gradual, planejada e sem necessariamente uma divisão de inicio, meio, fim.
Acredito que para diferenciar os dois pode-se mencionar a noção de um cronograma bem definido, com inicio, meio e fim são estipulados em um projeto e não tão necessários em operações que costumam ser menos ligadas a esse calendário determinado; um projeto geralmente é algo que após o fim, não espera continuidade no trabalho, já operações são contínuas; um projeto envolve muitas áreas diferentes normalmente, operações são mais pontuais; projetos são uma entrega específica e operações geralmente são entregas constantes e que seguem um padrão.

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

🟢 VITOR OLIVEIRA CA. (Matrícula: 20243001059, Login: @Vitor)

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

📝 Questão 5: Por que código bom não basta?

Expectativas irreais e falhas de comunicação: O que o cliente ou a diretoria pede quase nunca é exatamente o que eles realmente precisam, e a comunicação inicial costuma ser cheia de buracos. Sem processos formais para alinhar requisitos e validar entregas constantes, o time programa baseado em suposições, o cliente muda de ideia no meio do caminho, e o projeto afunda em retrabalho e frustração.

Ego técnico e individualismo: É comum o desenvolvedor querer resolver os problemas sozinho sem pedir ajuda ou focar em construir uma arquitetura super complexa apenas pelo orgulho de usar uma tecnologia nova, esquecendo do objetivo real do negócio. A gestão entra para barrar isso, forçando o alinhamento da equipe em reuniões frequentes e garantindo que o foco seja entregar o que o usuário precisa.

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

📝 Questão 4: Esconder Bugs vs. Transparência

A principal diferença está no custo do conserto e no impacto para o time. Esconder um bug só empurra o problema com a barriga: o erro vai silencioso para produção e, quando estourar na mão do usuário, consertar vai ser muito mais difícil e caro, já que o código cresceu e ninguém lembra direito do contexto. Por outro lado, ser transparente e relatar o erro logo de cara permite que a equipe ataque o problema enquanto ele é pequeno ou até renegocie o escopo, evitando retrabalho surpresa e garantindo a estabilidade real do software.

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

📝 Questão 3: O Preço Oculto da Baixa Qualidade

Sacrificar a qualidade do código para cumprir um prazo é uma bomba-relógio porque cria uma forte dívida técnica que a equipe terá que pagar com juros logo no mês seguinte. Ao colocar no ar um sistema feito de qualquer jeito, o software vai para produção frágil e cheio de bugs, o que obriga o time a parar o desenvolvimento das próximas entregas apenas para apagar incêndios e focar em retrabalho. Além de travar a produtividade, mexer em um código mal estruturado faz com que qualquer nova alteração demore o dobro do tempo ou acabe quebrando outras partes do sistema, transformando a manutenção diária em um verdadeiro caos.

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

📝 Questão 2: O Triângulo de Ferro e a Pressão da Diretoria

Explicaria que um projeto é equilibrado por tempo, custo e escopo, sendo impossível alterar um sem afetar os outros. Como o prazo foi reduzido e o orçamento para a equipe continua fixo, a única forma de não comprometer a qualidade e evitar um sistema cheio de falhas é renegociar o escopo, priorizando as funcionalidades essenciais para entregarmos um MVP no novo prazo e deixando os recursos secundários para atualizações posteriores.

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

📝 Questão 1: Projetos vs. Operações na Prática

Projetos têm escopo fechado e data para acabar, enquanto operações são rotinas contínuas para manter tudo funcionando.

Projeto (Faculdade): A modelagem do sistema de gestão prisional. O trabalho teve etapas claras de início , meio e fim.
Operação (Estágio): O suporte diário no TI de um escola. Resolver chamados, dar manutenção em computadores, redes ou sistemas da escola é um processo contínuo e de rotina, focado em manter a estabilidade, sem um fim definido.

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

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

CARLOS EDUARDO (@CarlosEduardo)
GABRIEL SILVA GON. (@mewndigo)
HUGO VICENTE COEL. (@hugovicente)
RAFAEL DE OLIVEIR. (—)
WELLINGTON JHONNEY (—)

De volta ao topo