Logo

UnBoard

Informações sobre ingresso na Universidade de Brasília - UnB

Grafico com chapeu

Projeto

O UnBoard é um projeto Open Source que tem por objetivo a apresentação de dados estatísticos dos aprovados pelo vestibular anual da Universidade de Brasília (UnB), por meio de gráficos que informam a quantidade de aprovados, a demanda de vagas, as vagas reservadas e outras informações de todos os cursos da UnB. Os dados coletados estarão em uma página Web de maneira que facilite a visualização e compreensão do usuário, por meio de dashboards que podem ser filtrados de acordo com o Campus desejado.

Protótipo

Equipe

Somos um grupo da UnB cursando Engenharia de Software no campus Gama. Através da disciplina Métodos de Desenvolvimento de Software, nós nos juntamos para realizar este projeto num período de cerca de 4 meses.

Breno Yuri Barbosa Gomes
Breno Yuri
Barbosa Gomes
Danilo Carvalho Antunes
Danilo Carvalho
Antunes
Francisco Mizael Santos da Silva
Francisco Mizael
Santos da Silva
Guilherme Keyti Cabral Kishimoto
Guilherme Keyti
Cabral Kishimoto
João Manoel Barreto Neto
João Manoel
Barreto Neto
Raphael Mendes da Silva
Raphael Mendes
da Silva

Post Mortem

Geral

Este documento tem como objetivo fazer uma avaliação crítica tanto do ponto de vista do grupo quanto do ponto de vista individual de cada integrante no nosso projeto. Vamos refletir sobre as etapas do projeto, as decisões tomadas e o desempenho individual de cada membro para identificar pontos de melhoria e traçar estratégias para alcançar um resultado ainda mais satisfatório em futuros projetos.

- Equipe: Os integrantes da nossa equipe possuem muita habilidade e vontade de produzir, gerando conversas inteligentes e uma colaboração poderosa.

- Soma de conhecimento: O projeto foi uma excelente oportunidade para praticar o aprendizado por conta própria, sendo essa a habilidade mais importante de todo esse projeto. Esse auto-aprendizado nos permitiu entender e aplicar novas tecnologias de programação, como *Git*, *Python*, *ReactJS* ao mesmo tempo que trabalhavamos como equipe. Essa habilidade será valiosa em futuros projetos e no desenvolvimento pessoal dos membros do grupo.

O projeto foi uma excelente oportunidade para aprender e aplicar os princípios dos métodos ágeis, especificamente o Scrum e o XP. Esses métodos têm como objetivo tornar o processo de desenvolvimento de software mais flexível e adaptável às mudanças, garantindo a entrega de produtos de alta qualidade em prazos curtos. Este aprendizado será valioso em futuros projetos, pois permitirá aos membros do grupo trabalhar em equipe de maneira eficiente e confiante. Além disso, o conhecimento sobre métodos ágeis será uma habilidade valiosa em suas carreiras profissionais.

Pontos Negativos - Dificuldades em seguir as metodologias ágeis: Embora tenhamos tentado seguir as metodologias ágeis, enfrentamos algumas dificuldades em adaptar nosso processo de trabalho a esses métodos. Descobrimos que o trabalho de venda e desenvolvimento de um produto em grupo é extremamente diferente de um projeto de escola. Clientes raramente vão se importar com algum membro da equipe com estresse, doenças e incapacidades, as pessoas de fora do processo vêem somente o produto, quaisquer atrasos e problemas no desenvolvimento vão ser redirecionados a ele. Por isso uma equipe profissional deve ter coordenação suficente para manter sua produtividade e atitude perante qualquer problema, seja a ausência de um membro ou a mudança de escopo, postura essa que não é nada simples de se adquirir sem bastante experiência em equipe e vontade de todos os integrantes. A verdade é que os *técnicas de gestão e organização da equipe*, como os métodos ágeis, não são nada mais do que formas de tentar garantir que a equipe seja dinâmica em qualquer projeto. Esse é um problema que afeta até equipes de profissionais do mercado, não é surpresa que nos afete, é nosso dever agora buscar formas de adquirir tal maturidade.

- Frequência das Reuniões: Fazer reuniões todo dia é pouco realista num contexto em que os estudantes focam em vários conteúdos diferentes com avaliações e atividades próprias. Quando tentamos realizar reuniões mais frequentes, não tínhamos nada significante para falar e isso nos desanimou a realizar novas reuniões.

- Diminuição de dias do semestre: O semestre teve menos dias, o que fez com que todas as disciplinas tivessem que dar uma acelerada. Isso acabou atrapalhando bastante o nosso projeto, pois precisamos realizar muitas tarefas em um período de tempo reduzido.

- Recesso de Natal e Ano Novo: O recesso de Natal e Ano Novo, que ocorreu no meio do semestre, prejudicou bastante o nosso rendimento. Alguns integrantes do grupo viajaram e ficaram ausentes por um período prolongado, o que dificultou o andamento das tarefas.

Sugestões Com base na nossa experiência neste projeto, gostaríamos de compartilhar alguns conselhos para projetos futuros: - Você é uma empresa: Considere-se uma empresa no mercado, você não pode atrasar o lançamento de um produto com o motivo "O fulaninho tava no hospital, aí não deu para acabar". Quem vai investir numa empresa assim? Quem vai confiar nas promessas de uma empresa que não consegue compensar imprevistos corriqueiros dos funcionários? Sempre que tiver dúvida sobre como a professora vai reagir a alguma decisão de vocês, pense como o público reagiria caso uma empresa fizesse esse mesmo anúncio. É para isso que a Carla está preparando vocês.

- Adote a filosofia dos métodos ágeis: É importante adotar uma metodologia ágil para garantir a flexibilidade e a adaptação a mudanças, mas é ainda mais importante entender o porquê um modelo desse foi construído. Ao entender o que faz um modelo ágil ser o que é e o porquê uma postura adequada de uma equipe profissional perante sua produtividade é importante, você poderá aplicar seu próprio sistema de gestão. Um que seja mais adequado para a realidade da sua equipe e projeto.

- Planejamento rigoroso: Como a maior parte dos alunos que fazem a disciplina de MDS não entram sabendo o que precisam sobre um planejamento ágil, seria interessante fazer um planejamento rigoroso do projeto, incluindo uma estimativa realista de tempo para cada tarefa. Isso permitirá que o grupo visualize o projeto como um todo desde o início e se adapte melhor a possíveis mudanças e evite situações de atraso e estresse. Não se preocupe em seguir esse cronograma à risca, porque você com 99% de chance de certeza não vai.

- Comunicação efetiva: A comunicação efetiva é fundamental para o sucesso do projeto. É importante que todos os membros do grupo estejam alinhados quanto aos objetivos, às tarefas e aos prazos. A comunicação é a chave de um grupo para lidar com situações de risco ao projeto.

- Flexibilidade e firmeza: É importante que o grupo esteja preparado para se adaptar a mudanças. **É comum que o grupo não esteja sempre alinhado**, várias serão às vezes que algum integrante estará ocupado ou simplesmente não esteja com tempo/disposição/saco de fazer. Nesses casos, o grupo deve ter a flexibilidade de entender que os integrantes estão todos fazendo o que podem e a firmeza de não parar ou desistir do trabalho por isso. Vocês devem discutir com os integrantes que restam e resolver o problema como uma equipe.

- Manter-se atualizado: É importante que todos os membros do grupo mantenham-se atualizados, tanto sobre tecnologias e métodos utilizados pelo grupo, quanto sobre as intruções e modificações que a professora dá em sala. Tente participar de todas as aulas dela.

- Não tenha medo de diminuir o escopo: À certa altura do trabalho, vocês provavelmente estarão com um prazo apertado para implementar um monte de recursos. É desesperador, pode chorar, mas não hesite em diminuir a quantidade de recursos que você precsia entregar. A saúde vale mais do que ficar acordado até de madrugada implementando código.

Raphael Mendes (Scrum Master)

Desiste não, tudo tem o momento certo para dar errado.

Scrum Master é o membro do grupo responsável por facilitar o desenvolvimento do grupo perante a metodologia Scrum. O grupo sempre se juntava após as aulas para fazer um planejamento e elaborar algumas issues. Enquanto muitos sugeriam e se comprometiam na conversa presencial, a documentação das decisões e divisão de tarefas não era feita por eles no GitHub. Sobrava para mim documentar as decisões na plataforma e, ainda que eu não ligasse muito para isso no início, acabou por desencadear uma série de problemas relacionados a pouca frequência de interação entre os membros no GitHub:

- A comunicação feita pelo GitHub acabava despercebida pela maioria, que acabava por não conferir a plataforma frequentemente.

- O Backlog feito através do ZenHub gerava dúvidas no grupo. Inclusive, NÃO CONFIE NO ZENHUB, no fim ele me deixou na mão, até hoje não consegui acessar o backlog que fiz lá novamente...

- Poucas Pull Requests foram feitas, sendo boa parte das modificações feitas na própria main.

- Códigos associados à ferramentas integradas ao GitHub acabavam defasados porque as outras pessoas não sabiam mexer sem causar erro. Mas confesso que o *GitHub Actions* não é lá muito fácil não.

Confesso que faltou um envolvimento maior com o projeto em seu início, parecia que eu era um dos poucos realmente interessados em começar. E sim, isso é comum e normal, mas acho que ao menos deveríamos ter feito um planejamento inicial mais completo. Apesar dos problemas, eu gostei do time, os integrantes claramente possuem um conhecimento significante e um humor louvável. Quanto mais no fim o semestre ia chegando, mais deu para ver que todos de fato se importavam com o projeto e estavam se esforçando bastante para conseguir. Eu ri, rezei, torci, chorei e sorri, com certeza foi uma experiência memorável. Não teria conseguido produzir esse projeto sem eles, isso é um fato, é a união que faz dessa equipe a que ela é. Sinto-me orgulhoso de participar dessa gambiarra e sei que serão ótimos profissionais num futuro próximo. Caso seja um aluno, tente não se estressar com seus colegas, lembre-se que estão todos no mesmo barco. Caso seja a professora, TENHA PIEDADE! Fico feliz com o grupo que entrei e com o que aprendi aqui. Vejo que tenho muito a melhorar ainda.



João Barreto (Product Owner)

Minha experiência nesta disciplina foi incrível e os motivos para isso são inúmeros, mas o maior deles com certeza foi o trabalho em equipe. Desde o momento em que ingressamos na Universidade trabalhamos em grupo em várias disciplinas e projetos variados. No entanto, o que mais me impressiona é que nunca sabemos 100% como trabalhar assim, uma vez que o convívio e o conhecimento compartilhado é novo a cada projeto.

A disciplina de Métodos de Desenvolvimento de Software certamente proporciona uma ideia de como é o mercado de trabalho e quais serão nossas dificuldades desse momento em diante. Além disso, a disciplina foi responsável por apresentar novas formas de pensar e de resolver problemas. Mesmo conhecendo algumas tecnologias, somos motivados a buscar o que está além do nosso conhecimento, entender de fato o que determinada tecnologia faz e se ela é a mais viável.

Durante a construção do Front-End descobri coisas novas utilizando o React JS. Tive diversos problemas em como seria a arquitetura do trabalho, mas as metodologia ágil nós proporciona uma organização melhor para pensarmos como equipe e a partir disso criamos nosso primeiro protótipo, o que facilitou muito na construção do site. No Back-End precisamos errar muito para chegar na melhor biblioteca Python a ser utilizada. Foram meses testando para conseguirmos encontrar algo que realmente funcionava. Eu e meu grupo aprendemos bastante com tudo isso e nesse momento final, percebemos que não aproveitamos o máximo que podíamos. Entretanto, conseguimos ter a experiência de que é com os erros que se aprende e o importante é não desistir. Se for necessário refazer algo, que seja refeito, pois o importante é enxergar o porquê determinada parte do trabalho deu errado e o que poderia ter sido feito para melhorar.

Como Product Owner do UnBoard, percebi que a visão que eu e muitas outras pessoas que já trabalhei tem sobre um projeto é bastante limitada. Às vezes pensamos pouco e nós restringimos a executar algo que apenas funcione, quando na verdade devemos pensar como se nós mesmos fôssemos clientes e usuários. Ao abrirmos nossa mente para esse tipo de pensamento, conseguimos enxergar o mundo de uma forma diferente e as ideias começam a surgir melhor na cabeça de todos os membros da equipe. Sei que não exerci de forma completamente correta a função a qual me confiaram, mas sei que o aprendizado que tive me fez ter uma nova visão.



Breno Yuri (Desenvolvedor)

A matéria mais desafiadora que fiz na graduação até agora, pois demanda muito tempo e dedicação. O conhecimento por outro lado vai se desenvolvendo. Reconheço a importância de aprender sobre esses temas e como isso pode ser aplicado em futuros projetos.

O projeto foi desafiador, exigindo muito, mas também foi uma ótima oportunidade para aprender sobre métodos ágeis. Eu enfrentei alguns desafios, como a dificuldade de me situar na matéria e de me adaptar ao grupo e ao cronograma. Isso prejudicou o projeto, pois eu demorei muito para entender como as coisas funcionavam, e sei que o meu grupo também lidou com essas questões, mas é uma lição importante para o futuro, pois eu sei que preciso estar mais preparado para lidar com esses desafios. Além disso, eu também sei da necessidade de aperfeiçoar as habilidades em métodos ágeis e estar sempre preparado para lidar com erros inerentes ao desenvolvimento de software. Aprender a trabalhar em equipe e a lidar com as diferenças é uma habilidade fundamental para o sucesso em qualquer área, e nesta matéria, tive a oportunidade de colocar isso em prática e melhorar ainda mais nessas habilidades.

Aprender a gerenciar o tempo e a priorizar as tarefas, também foi um ponto importante na minha evolução como desenvolvedor, já que precisávamos entregar o projeto dentro do prazo estabelecido.

Em resumo, a matéria MDS me trouxe muitos desafios e houveram muitos erros, mas também me proporcionou muitas conquistas, e tenho certeza que tudo o que aprendi será de grande valor para a minha vida profissional.



Danilo Carvalho (Desenvolvedor)

Na minha experiência durante a disciplina, eu mudaria muitas atitudes pessoais. No entanto, foi uma disciplina onde aprendi muitos conteúdos que eu não tinha ideia de sua existência. Falando em geral, meu grupo cometeu erros similares aos meus. Nós nos concentramos muito em estudar arquiteturas, APIs, frameworks e linguagens de programação, negligenciando a documentação do projeto e a participação no GitHub. Acredito que, se tivéssemos nos organizado melhor, poderíamos ter desenvolvido um projeto mais completo e entregar tudo o que imaginamos.

Um dos maiores erros cometidos por mim e pelo grupo foi a empolgação. Tentamos usar mais ferramentas do que devíamos e acabamos seguindo aquele ditado de "faz muita coisa, mas faz tudo mal feito". Sobre minha experiência, posso tentar explicar o que aconteceu. Eu era responsável por fazer os dashboards. Comecei o projeto tentando fazer pelo Power BI, mas depois tentei mudar para o Grafana, o que se mostrou uma péssima decisão. A instalação não deu certo e precisei do suporte do Docker. Depois de um tempo, aprendi a mexer no básico do Docker, mas tive problemas para trazer os dados do projeto para o Grafana. Então, tentei usar o MySQL, o que também se mostrou uma barreira grande.

Me senti muito perdido ao longo da disciplina, pois não tínhamos monitores para ela. Quando enfrentava algum problema, não tinha a quem recorrer, o que me fez perder mais tempo tentando aprender ferramentas e encontrando barreiras maiores cada vez. Acho que a disciplina precisa de dois elementos para ser bem-sucedida: tempo dedicado e um monitor por grupo para direcionar o projeto.

Devolta a quando fiquei preso no MySQL, acabei desanimando e dediquei meu tempo a outras matérias. O atraso do código aconteceu pois não fui o único a ter que se concentrar em outras matérias. Outra pessoa do meu grupo acabou fazendo o dashboard. Eu acabei trabalhando mais com a estrutura do site, pois tentei consertar problemas no backend, o que só gerava mais problemas além disso não conseguia implementar as bibliotecas de forma adequada. Acabei indo para a parte do frontend. De uma forma geral, gostei de fazer o projeto, mas se pudesse mudaria muitas coisas que fiz erradas.



Francisco Mizael (Desenvolvedor)

Como já possuía algum conhecimento prévio em Python e Git, consegui ajudar os outros membros do grupo a desenvolver suas habilidades nessas áreas. No entanto, mesmo com meus conhecimentos anteriores, ainda aprendi muito durante este projeto. Não apenas ampliei meus conhecimentos em Python e Git, mas também aprendi sobre o framework React e sobre métodos ágeis. A oportunidade de compartilhar meu conhecimento com outros membros do grupo e, ao mesmo tempo, aprender com eles, foi muito enriquecedora. Este projeto foi uma ótima oportunidade para continuar a desenvolver minhas habilidades e ampliar meus conhecimentos. Fiquei feliz por poder ajudar outros membros do grupo, mas também aprendi muito ao longo do caminho. Espero poder aplicar tudo o que aprendi em projetos futuros e continuar a crescer como profissional.



Guilherme Kishimoto (Desenvolvedor)

Minha experiência neste projeto foi bastante enriquecedora. Embora tenha sido um pouco complicado trabalhar em grupo, no final foi uma ótima oportunidade para conhecer pessoas novas e desenvolver habilidades de trabalho em equipe. No quesito de programação, aprendi muito ao longo deste projeto. Tive a oportunidade de aprender novas tecnologias como Git, Python e ReactJS, o que me permitiu aprimorar minhas habilidades e conhecimentos na área. Além disso, o aprendizado sobre métodos ágeis, especialmente o Scrum e o XP, me deu uma visão mais clara sobre como aplicar práticas ágeis em projetos futuros.

Apesar de ter sido uma boa oportunidade para desenvolver minhas habilidades e ampliar meus conhecimentos, foi um pouco desafiador conciliar este projeto com as outras matérias do semestre. Devido ao semestre ter sido mais curto, foi necessário acelerar o ritmo de todas as disciplinas, o que pode ter afetado o rendimento do grupo e individual. Ainda assim, foi uma ótima experiência para trabalhar em equipe e aprender novas tecnologias, mas certamente seria mais viável se tivéssemos um pouco mais de tempo para nos concentrar em cada matéria individualmente.