Saltar para o conteúdo

Kiskadee - MES 2018/01

Fonte: Wikiversidade
  • Guilherme Sant'Ana
  • João Paulo
  • Julliana Almeida
  • Marcelo Augusto
  • Matheus Sousa
  • Naiara Andrade
  • Renata Francelino

Nesta sprint a equipe foi dividida em três subequipes de acordo com o nível de conhecimento descrita abaixo:

  • Documentação
  Melhorar documentação do Fedora(Julliana, Matheus, Guilherme)
  • VM
  Criar VirtualMachine para executar o ambiente do projeto (Renata, Marcelo)
  • Docker
  Criar o Docker para executar o ambiente do projeto (João, Naiara)
Data Horário Descrição Integrantes
05/04 20:00-22:00 Pareamento Docker João, Naiara
05/04 20:00 - 22:00 Pareamento para criar VM Marcelo, Renata
06/04 14:00 - 18:00 Configurar ambiente, melhorar a documentação. Guilherme, Julliana, Matheus
06/04 20:00 -22:00 Pareamento Marcelo, Renata
10/04 16:30 -17:30 Reunião com cliente (Athos) Todos

Retrospectiva da Sprint

[editar | editar código-fonte]
  • Pontos Positivos
    • Identificar os problemas de configuração e issues
    • Divisão balanceada do pareamento
    • Comunicação entre os integrantes da equipe
    • Liberdade para criação de novas issues
  • Pontos Negativos
    • Computador de um dos integrantes estragou
    • Configuração de ambiente
    • Primeira reunião com o cliente tardia
    • Para clonar projeto no pagure deve-se usar SSH, o que impossibilita que certas ações sejam realizadas quando a rede UnBWireless for utilizada.
  • Melhorias
    • Reuniões com cliente as 16:10 às 16:30 (para grupo chegar no horário de aula e aproveitar o horário para trabalhar em grupo)

Não foram entregues issues por conta do ambiente e falha de comunicação com os clientes. E na issue da documentação também ocorreu falha de comunicação sobre o que o cliente queria e o que foi feito.

  • Issues
    • Issue de documentação: Realizada pelos membros, mas não entregue.
    • Issue de VM e Docker: Não concluídas
Pull Requests / Merge Requests aceitos
[editar | editar código-fonte]

Nesta sprint não foram realizados pull requests ou merge requests.

#30 - Utilizar a biblioteca para o reconhecimento da linguagem no código C/C++ (João Paulo, Juliana)
#53 - Mostrar análise completa de alguma versão do pacote (Guilherme)
 Fazer o ambiente funcionar pelo Ansible/Vagrant para usuários Debian (Naiara, Renata, Marcelo, Matheus)
Horário Descrição Integrantes
17/04 16:30-17:30 Reunião com cliente (Athos) Todos
24/04 16:15-17:40 Reunião com cliente (David) Todos

Retrospectiva da Sprint

[editar | editar código-fonte]
  • Pontos Positivos
    • Ver o programa funcionando com o cliente.
    • Clareza do que é o programa e como funciona.
    • Alteração do Vagrant que funcionou.
  • Pontos Negativos
    • Pouco progresso de forma geral, porque ainda não estão todos com o ambiente totalmente configurado.
    • API do programa está com bugs, o que dificulta alguns testes.
    • Por ter que usar o SSH no pagure, o grupo fica restrito por não poder clonar e commitar na rede na UnB.
  • Melhorias
    • Ambiente de todos arrumados.
    • As issues bem descritas e definidas com o cliente.

O time em geral ainda estava com problemas de ambiente. Para fazer a issue do ambiente, o time foi subdividido em 2 duplas, para que cada um arrumasse o ambiente com uma das tecnologias: Ansible e Vagrant.

O time de Vagrant conseguiu fazer o vagrant funcionar, até que foi conversado em uma reunião com os clientes as dificuldades e as necessidades do ambiente, e os clientes falaram que não tinha nada com que arrumar tais arquivos pois já estava funcionando. Então não foi entregue a issue, mas foi usada internamente por alguns integrantes do grupo que tiveram problemas.

  • Issues
    • Issue 53 está com status de aberta,porém foi verificado que a mesma já estava feita e resolvida.
    • Issue 30 não foi concluída.
    • Issue do Vagrant foi feita, mas não entregue.

Pull Requests / Merge Requests aceitos

Nesta sprint não foram realizados pull requests ou merge requests .

Nesta sprint a equipe foi dividida em subequipes de acordo com o nível de conhecimento descrita abaixo:

#30 - Utilizar a biblioteca para o reconhecimento da linguagem no código C/C++ (João Paulo)
#42 - Página para mostrar análise de um pacote (Renata, Marcelo)
#100 - Erro de redirecionamento
#101 - Ordenação aleatória de pacotes
#102 - Seleção do pacote errado (Guilherme, Matheus)
#103 - Erro na chamada na API
Documentar API (Naiara, Julliana)

Retrospectiva da Sprint

[editar | editar código-fonte]
  • Pontos Positivos
    • Histórias foram entregues
    • Cada membro faz contribuições através do seu próprio fork usando ssh
    • Ambientes configurados
  • Pontos Negativos
    • Não foram realizadas reuniões com os clientes e os mesmos não respondem as tentativas de contato
  • Melhorias
    • Entrar em contato novamente com os clientes

Foram entregues as issues #100, #101, #102 e #103. A issue da documentação da API não foi concluída. No caso da issue #42, ela não pode ser resolvida por que não tinha os pré-requisitos para funcionar porque não estava funcional. Então foram criadas outras issues para resolver a issue.

  • Issues
    • Issues #100, #101, #102, #103 foram entregues.
    • Issue de documentação não foi concluída.
    • A issue #42 derivou outras issues para resolvê-la, e não foi concluída nessa sprint.

Pull Requests / Merge Requests aceitos

Foi aberto um pull request com a correção dos erros apontados nas issues #100, #101, #102, #103 . Este pull request foi aberto no repositório responsável pelo front end do projeto.

Nesta sprint cada membro ficou responsável por determinadas issues, sem a realização de pareamentos.As issues e o responsável estão elencados abaixo:

#104 - Criar máquina virtual do ambiente de front-end (João Paulo)
# - Documentar API no Flasgger (Naiara)
#105 - Gráfico não aparece quando a página é carregada (Matheus)
#106 - Resumo da analise não mostra o número total de erros (Marcelo)
#107 - Lista de error não mostra todas as incidências (Juliana)
#108 - Paginação dos reports e results não aparecem em algumas máquinas (Juliana)
#X - Testes unitários e funcionais de front-end (jest/mocha, cypress) (Renata)
#109 -  Se a página de análise for atualizada, os dados presentes são perdidos (Guilherme)

Retrospectiva da Sprint

[editar | editar código-fonte]
  • Pontos Positivos
    • Histórias foram entregues
    • Cada membro faz contribuições através do seu próprio fork usando ssh
  • Pontos Negativos
    • Não teve reuniões e os clientes não respondem aos emails
  • Melhorias
    • Entrar em contato novamente com os clientes

A issue #42 da sprint anterior foi dividida em outras issues nesta sprint. A issue #105 foi iniciada mas foi encontrada problemas no banco de dados fornecido pelos clientes.

  • Issues
    • Issues #104, #109 foram entregues.
    • Issue de documentação foi entregue.
    • Issues de testes do front foi entregue.
    • Issues #105, #106, #107, #108 não foram concluídas
    • A issue #42 derivou outras issues para resolvê-la, e não foi concluída.

Pull Requests / Merge Requests aceitos

  • O pull request da issue #104 foi realizado no repositório do front end do projeto.

Nesta sprint cada membro ficou responsável por determinadas issues.As issues e o responsável estão elencados abaixo:

#106 - Resumo da análise não mostra o número total de erros (Marcelo)
#30 - Utilizar a biblioteca para o reconhecimento da linguagem no código C/C++ (João Paulo)
#42 - Página para mostrar análise de um pacote (Renata, Marcelo)
#100 - Erro de redirecionamento
# - Automatizar configuração da máquina virtual do frontend (João Paulo)
# - Ao entrar na visualização de um pacote, voltar para a página inicial e tentar visualizar o mesmo pacote a análise não é renderizado. (Guilherme)

Retrospectiva da Sprint

[editar | editar código-fonte]
  • Pontos Positivos
    • Conhecimento obtido pela equipe
    • Autonomia da equipe quanto a tomada de decisões.
  • Pontos Negativos
    • Issues sendo resolvidas sem o feedback em relação as mesmas.
    • Membros ausentes por problemas médicos.
    • Greve
  • Melhorias
    • Melhorar a comunicação interna

Nessa sprint a issue #30 foi descontinuada e retirada da lista de issues a serem realizadas, isso ocorreu pois verificou-se que a mesma não poderia solucionar o problema da forma que foi proposto inicialmente pois seu funcionamento é diferente da descrita em sua documentação.Assim sem a comunicação para obter novas formas de realizá-las e tendo os requisitos iniciais foi decidido que a mesma seria descontinuada.

  • Issues
    • Issue referente a não renderização da análise do pacote não foi resolvida.

Pull Requests / Merge Requests aceitos

  • XXXXXX

Devido ao tamanho pequeno do projeto nesta sprint a equipe foi dividida em duas sub-equipes, sendo a equipe responsável por mexer com o FrontEnd e outra responsável pelo Backend. Essa sprint foi planejada de acordo com a disciplina, pois a mesma tem como foco aplicar técnicas de CleanCode e SOLID.

No Backend, para que todos os membros tivessem a oportunidade de aplicar as técnicas os arquivos do projeto foram separados entre os mesmos.

A seguir estão elencados os membros e a frente os arquivos sob responsabilidade de cada um:

  • Subgrupo responsável pelo Backend:
    • Guilherme - Runner
    • João Paulo - Model, Initializer
    • Marcelo - Converter, Database, Monitor
    • Naiara - Queue, Report , Apperk.vue,
  • Subgrupo responsável pelo Frontend:
    • Renata - List.vue, PackagePage.vue, DefaultTable.vue, routes.js, packagePage.js
    • Matheus - PackagePage.vue, List.vue, ErrorTable.vue, RegisterForm.vue, LoginForm.vue
    • Julliana - PackagePage.vue, Headerk.vue, RegisterForm, LoginForm.vue

O subgrupo atuante no Frontend identificou casos gerais de intervenção e cada um dos membros ajustou o código. Devido a isso um arquivo foi alterado por mais de um membro.

Como não foi possível aplicar um número considerável de técnicas por conta do tamanho do projeto, os membros tiveram a possibilidade de resolver possíveis issues ou outros problemas que considerassem necessários de serem resolvidos. Ficando assim, livre a resolução de issues por parte dos membros.

  • Clean Code
    • O Clean Code visa o melhor entendimento do código. Assim, os membros do grupo identificaram e implementaram as seguintes boas práticas do Clean Code no software Kiskadee:
      • Criação de constante para números mágicos
      • Extrações de método
      • Inserção nomes significativos
      • Tratamento de operador ternário
      • Correção de identação
  • SOLID
    • Os princípios SOLID foram identificados principalmente a partir da aplicação de extração de método, preservando o conceito de atomicidade do módulo e caracterizando o princípio Single Responsability Principle (SRP).

Pull Requests / Merge Requests aceitos

  • Nesta sprint os pull requests / merge requests foram realizados de forma interna na equipe, sendo que todas as modificações realizadas foram aceitas pela equipe. Sendo realizado no fork do membro João Paulo.

Resultado Final

[editar | editar código-fonte]

Número de commits por membro

[editar | editar código-fonte]
  • Guilherme Sant'Ana
    • Commits Individuais
      • BackEnd
        • 4 (Master) + 1 (file_analysis)
      • FrontEndt
        • 1 (FixDataLoss) + 1 (FixGetApi)
    • Commits Pareados
      • BackEnd
        • 3 (improving_docs)
  • João Paulo Nunes
    • Commits Individuais
      • Commits no Backend
        • 7 ( Master) + 2 ( Docker) + 1 ( ChangingDocuments)
      • Commits no Frontend
        • 2 (VagrantFile)
    • Commits Pareados
      • Commits no Backend
      • Commits no Frontend
  • Julliana Almeida
    • Commits Individuais
      • Commits FrontEnd
        • 6(Clean Code)
    • Commits Pareados
      • 2 (Dcumentação)
  • Marcelo Augusto
    • Commits Individuais
      • Commits no Backend
        • 4 (Master)
      • Commits no Frontend
        • 2 (FixingGetApi)
    • Commits Pareados
      • Commits no FrontEnd
        • 2 (FixingGetApi)
      • Tentativas de fazer a VM funcionar (pareado com Renata)
      • Pareamento para compreender o código em Vuejs (Com Matheus, Renata e Guilherme)
  • Matheus Sousa
    • Commits Individuais
      • Commits no backend
        • 1 Commit vagrantfile_improvements - joaopaulo
      • Commits FrontEnd
        • 4 Commits fixingGetApi - matheussbernardo
    • Commits Pareados
      • Commits na Documentação
        • 4 Commits improving_docs (Guilherme, Juliana) - joaopaulo
  • Naiara Andrade
    • Commits Individuais
      • 8 (Master) [1 - documentação da API]
      • Tentativas de fazer o Ansible funcionar
    • Commits Pareados
  • Renata Francelino
    • Commits Individuais
      • Commits no Frontend
        • 4 (Testes funcionais) + 9 (Clean code)
    • Commits Pareados
      • Tentativas de fazer a VM funcionar (pareado com Marcelo Augusto)
      • Pareamento para compreender o código em Vuejs (Com Matheus, Marcelo e Guilherme)
      • Pareamentos para compreender o Ansible no ambiente (Com Naiara)