MprofSC / videolocadoraimperial

0 stars 0 forks source link

**Documentar Revisão individual** #15

Closed samuelbl closed 5 years ago

samuelbl commented 5 years ago

Lições aprendidas do ponto de vista individual dos membros do time em relação a execução do projeto em si.

estrazulas commented 5 years ago

Relato Daniel: Com relação aos acertos do projeto, a decisão de optar por uma ferramenta para facilitar a geração das entidades e cadastros permitiu que a equipe conseguisse entregar rapidamente os principais cadastros necessários para manutenção da video locadora imperial. Ganhamos principalmente com relação aos testes unitários e testes de aceitação pois toda a estrutura do jhipster já vinha com as configurações necessárias e inclusive vários testes da api já implementados. Com relação ao nossos erros de projeto, em muitos casos acabamos tendo que regerar a aplicação pois fizemos a liberação em partes das entidades, gerando vários branchs durante o projeto, pois uma vez que precisávamos mudar algum relacionamento ou campo tínhamos problemas de sobrescritas das classes já modificadas, e isto acabou gerando um certo retrabalho. Algumas tecnologias como uso de mysql com heroku e outh tiveram que ser refeitas, e por dificuldades no desenvolvimento acabamos optando por trocar de tecnologia. Com relação às iterações que tivemos acabamos tendo que aumentar os prazos de entrega, pois foram surgindo situações inesperadas durante a customização no jhipster que tivemos que estudar para poder implementar, uma vez que a equipe de desenvolvimento desconhecia de várias tecnologias utilizadas pelo jhipster.

Relato Eliandro: Iniciamos o projeto com uma reunião entre os membros da equipe, com o intuito de atribuir as funções de cada membro e definir as ferramentas e métodos que seriam utilizados no desenvolvimento do projeto. A atribuição de gerente de projeto, ficou sob minha responsabilidade, no início tive um certo receio de assumir tal função, pelo fato de não ter experiência em desenvolvimento e em gerenciar trabalho em equipe, mas no decorrer das atividades, entendi que esta seria a função mais adequada para ficar sobre minha responsabilidade, tendo em vista minha falta de conhecimento nas questões de desenvolvimento de software. Durante o avanço das atividades, foi ficando mais fácil de entender os motivos pela escolha do XP (Extreme Programing) e os processos de aplicação dessa metodologia na prática. Para cada iteração concluída, foi criado um arquivo post mortem, esses arquivos são relatos dos membros da equipe, referente às atividades desenvolvidas em cada sprint e serviram de base para o documento final deste projeto. As dificuldades encontradas na aplicação de algumas ferramentas, até então desconhecidas pela equipe, serviram de aprendizado de como lidar com possíveis imprevistos, isso fez com que a equipe se reuni-se para debater soluções e buscar conhecimentos para solucionar esses problemas. Como lições aprendidas neste projeto, gostaria de destacar a importância da aplicação correta da metodologia e das ferramentas escolhidas, bem como a necessidade e documentar o andamento do projeto a cada sprint, o que auxilia muito na documentação final.

Relato Samuel: Como organização para o projeto, a equipe desempenhou bem o papel, com cada membro desenvolvendo seu trabalho dentro das atividades de cada sprint. A metodologia XP ajudou durante a programação devido a sua dinâmica da definição dos testes antes do desenvolvimento e também da programação em pares, apesar de parecer que iria demorar mais o desenvolvimento desta forma, acabou acelerando devido a problemas de configurações no projeto e desenvolvimento que um desenvolvedor só acabaria levando muito mais tempo para conseguir solucionar. Como lições aprendidas, as metodologias escolhidas se mostraram corretas no decorrer das atividades do projeto. Alguns sprints foram necessários para identificar a real capacidade da equipe em termos de pontos, aprendemos a considerar também a carga de trabalho do período do sprint de cada membro fora de escopo do projeto na priorização para execução total da sprint. Utilizamos um gerador de CRUD Jhipster que apesar de facilitar na geração dos cruds e testes, adicionou outros problemas no projeto devido a configurações específicas da ferramenta, tivemos que refatorar o projeto algumas vezes por acabar ficando em estado inconsistênte. Tivemos uma curva de aprendizagem mas no geral conseguimos acelerar com a experiência de cada um e comunicação como equipe.