Projeto Geral Engenharia de Software
Uma palavra que define muito bem todo o processo de desenvolvimento do projeto é Desafio. Tínhamos um grupo formado por 5 pessoas, algumas com um pouco mais de experiência na área de desenvolvimento web e outras completamente iniciantes. Isso de fato foi um desafio, porém também uma oportunidade, pois foi a partir dos encontros que tivemos para ensinarmos uns aos outros que se criou uma integração e um espírito de time. Talvez isso tenha sido um dos principais combustíveis para o sucesso do projeto, o espírito de time e responsabilidade com o trabalho. Todos os integrantes da equipe se dedicaram para que o projeto fosse o melhor possível, fazendo com que cada um se alocasse em features específicas e buscasse integrar estas com as demais que estavam sendo feitas em paralelo.
Houve um processo de mudanças nas stack definida no início do projeto em relação a que foi de fato utilizada. No início, decidimos utilizar o React.js, Node.js, Postgres e Docker, porém, ao final, o Node, Docker e Postgres não foram utilizados por alguns motivos, e os principais são: Experiência e Facilidade. Explicando um pouco sobre esses dois pontos citados anteriormente, a Experiência seria um grande problema, pois desenvolver uma aplicação backend do zero, desde toda arquitetura MVC até a manipulação das Tableas e Relacionamentos dentro de um Banco de Dados SQL era, de fato, uma alta carga de estudo necessária para que o time conseguisse desenvolver (sem contar com toda a abstração necessária para se entender o conceito de Containeres proposto pelo Docker…). E a facilidade foi em razão de escolhermos a solução Firebase em troca de um backend próprio desenvolvendo com as tecnologias anteriormente citadas. O porquê do Firebase? Simples! Pois ele oferecia tudo que precisávamos, como Database, Storage, Sistema de Autenticação para Login e até mesmo Deploy, tudo o que precisávamos no backend-side estava pronto alí, só precisariamos, talvez, de algumas semanas de treinamento e estudo para alcançar o nível ideal para um time de desenvolvimento iniciante.
Depois da stack definida, começamos a separar e organizar todas as atividades nas nossa reuniões semanais, que começava às 19 horas e ia até o horário que fosse necessário, utilizando a ferramenta Trelo para Gerenciamento de Atividades. Lá, nós preparávamos a nossa Sprint, definida pelo Scrum, metodologia Ágil, que iria durar um total de 7 dias. Ao final dessa Sprint, nos reuniamos novamente na segunda feira para definir o que foi feito, o que não foi feito, porque não foi feito e o que seria necessário para ser feito. É válido ressaltar que durantes as primeiras Sprints nós separamos atividades para serem feitas em dupla, já que o time, em sua maior parte, não contava com experiência prévia, portanto fazer junto foi uma solução que deu muito certo. Quando o time se tornou mais integrado em questão de Código, Framework React e Versionamento de código com o Git, cada integrante do time pegou atividades para serem feita de forma independente e buscou, diariamente, comunicar no Whatsapp o que estava sendo feito, para evitar conflitos de merge na branch main (sobre isso, nós utilizamos a branch main para ser feito o deploy e as bifurcações para serem feitas as respectivas features que cada integrante do time iria fazer, isso foi um aprendizado que levamos do desafio do Hackenge Tetris, onde perdemos, por falta de organização, diversos testes e features por causa que só utilizávamos a main…).
Por fim, em relação aos pontos que não conseguimos completar, todos eles foram descritos no README.md do nosso repositório GitHub:
As principais causas por não conseguirmos implementar essas Features foram a pouca experiência da maior parte do time com desenvolvimento web e complexidade de certas telas. Para completar o que conseguimos fazer da plataforma demandou 100% do tempo disponível para todos do projeto, o que tornou fazer essas Features algo inviável. É possível que se tivessemos começado a programar o projeto desde o primeiro dia da cadeira, de fato pelo menos metade das atividades dessa lista estariam completas, porém, realmente houve esse atraso de nossa parte. E em relação a complexidade, existiam certas telas, como a de Solicitação de Empréstimo do Produto, que iriam exigir uma certa expertise para criar uma comunicação entre usuários diferentes em uma mesma plataforma, o que acabou não se tornando uma prioridade para ser feita.
E em relação aos testes, seria muito interessante que conseguissemos criar um Teste de Sistema, visto que, de acordo com o livro Engenharia de Sotware Moderna, deveria existir pelo menos 10% de Testes de Sistema ao redor da nossa Cobertura de Testes. Porém, nos dedicamos quase que 100% apenas nos Testes Unitários e Integrados, o que tornou o estudo e aplicação de um Teste de Sistema inviável.
