Kiskadee - MES 2018/01

Equipe

• Guilherme Sant'Ana

• João Paulo

• Julliana Almeida

• Marcelo Augusto

• Matheus Sousa

• Naiara Andrade

• Renata Francelino

Planejamento

Sprint 1

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

Issues

• 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)

Reuniões

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

• 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)

Resultados

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

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

Sprint 2

Issues

#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)

Reuniões

Data	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

• 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.

Resultados

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 .

Sprint 3

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

Issues

#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

• 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

Resultados

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.

Sprint 4

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:

Issues

#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

• 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

Resultados

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.

Sprint 5

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

Issues

#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

• 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

Resultados

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

Sprint 6

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.

Resultados

• 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

Número de commits por membro

• 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)