Métricas Sprint 2 Release 3

1. Identificadores da Sprint

• Número da Sprint: 2
• Release: 3
• Planejamento da Sprint: Planejamento
• Data: 27/06/2018 até 03/07/2018

1.1 Responsáveis

Mariana de Souza Mendes e Gustavo Lopes

1.2. Índice de Métricas

É importante ressaltar que a coleta das métricas foi feita no dia 04/07, ou seja, a sprint já havia acabado. Entretanto a branch develop ainda estava desatualizada, logo tivemos que coletar das branchs em que a Equipe de Desenvolvimento estava trabalhando.

Métrica	Coletada?	Justificativa
Percentual de aderência ao processo	✔	--
Percentual de artefatos planejados concluídos por sprint	✔	--
Percentual de métricas coletadas	✔	--
Percentual de melhoria de métricas	✔	--
Percentual de critérios de aceitação concluídos por feature	✔
Percentual de histórias entregues por sprints	✔	--
Percentual de código testado (APP)	✔	--
Percentual de código testado (API)	✔	--
Complexidade Ciclomática (APP)	✔	--
Complexidade Ciclomática (API)	✔	--
Número de erros referentes a folha de estilo proposta (APP)	✔	--
Número de erros referentes a folha de estilo proposta (API)	✔	--
Duplicação de código (APP)	✔	--
Duplicação de código (API)	✔	--
Percentual de endpoints documentados	✔	--
Percentual de comentários no código* (APP)	✔	--
Percentual de comentários no código* (API)	✔	--
Burndown	✔	--
Velocity	✔	--

2. Métricas Coletadas

• Percentual de aderência ao processo

A quantidade de atividades planejadas para a sprint foi coletada do conjunto de atividades definidas no processo de desenvolvimento. A quantidade de atividades realizadas foi coletada com uma entrevista com um dos membros da equipe de desenvolvimento.

Atividade	Realizada?
Elicitar Requisitos	?*
Analisar Requisitos	?*
Refinar Requisitos	?*
Documentar Requisitos	?*
Validar Requisitos	?*
Planejar Sprint	✔
Desenvolver	✔
Testar	✔
Realizar Stand Up	?*
Integrar	✔
Revisar	✔
Realizar Retrospectiva	✔

* = Não foi encontrada evidência da realização da atividade, e não foi possível obter resposta dos membros da equipe de desenvolvimento.

QPS = , QAR = 12; PAP = 6/12 * 100 => 50%

---

• Percentual de artefatos planejados concluídos por sprint

A quantidade de artefatos planejados foi coletada do Processo de Desenvolvimento. A quantidade de artefatos concluídos foi coletada deste repositório.

Artefato	Concluído?
Backlog da Sprint	✔
Incremento de Software	✔
Relatório da Retrospectiva	✔

* = Não foi encontrada evidência da realização do relatório.

QAP = 3 , QAC = 3 => PAP = 3/3 * 100 = 100%

---

• Percentual de métricas coletadas

A quantidade de métricas planejadas foi retirada do Planejamento das Coletas e do Plano GQM.

A quantidade de métricas coletadas foi retirada deste documento.

No total, foi planejada a coleta de 19 métricas, de maneira que as 19 foram realizadas. Logo, o percentual de métricas coletadas foi de QMC / QMP *100 => 19/19 * 100 = 100%.

---

• Percentual de melhoria de métricas

As métricas que se mantiveram aceitáveis ou que melhoraram estão descritas na tabela abaixo. As métricas não citadas ou não melhoraram, ou se mantiveram ruins.

Métrica	Valor Sprint Anterior	Valor Atual
Percentual de métricas coletadas	100%	100%
Percentual de código testado (API)	88%	89%
Percentual de código testado (APP)	35%	35%
Complexidade Ciclomática (APP)	1.30	1.39
Complexidade Ciclomática (API)	1.63	1.62
Número de erros referentes a folha de estilo proposta	0%	0%
Duplicação de código (APP)	0%	0%
Duplicação de código (API)	0%	0%
Burndown	Entregas ao longo da semana	Entregas ao longo da semana
Percentual de comentários no código (API)	32,2%	32%
Percentual de comentários no código (APP)	4,6%	4,47%
Percentual de endpoints documentados	85,19%	87,09%

PMM = QMM / QTM * 100 => (13/18) * 100 = 72.22%

---

• Percentual de histórias entregues por sprints

A quantidade de histórias planejadas foi retirada do Planejamento da Sprint.

A quantidade de histórias concluídas foi retirada do Repositório da API e do Repositório do APP e também do documento de Retrospectiva da Sprint

Artefato	Concluído?
#62 FT01 US01 - Publicar no perfil de um usuário (Testes)	✔
#65 FT01 US01 - Bloquear o perfil de outro usuário (Testes)	✔
#68 REQT 10 - Implementar Entrega Contínua	✔
#71 FT02 US01 - Visualizar apoios recebidos	✔
#67 FT02 US02 - Desbloquear um usuário anteriormente bloqueado	✔
#66 FT02 US01 - Visualizar lista de usuários bloqueados	✔
#64 FT02 US03 - Excluir apoio prestado	✔
#63 FT02 US02 - Visualizar apoios dados	✔
#69 - BUG - Posts por um mesmo usuário aparecem como usuário diferente	X

PHE = QHC / QHP * 100 => 8/9 * 100 = 88,88%

---

• Percentual de código testado

O percentual de código testado foi obtido da análise a partir da ferramenta incluída na integração contínua, o coveralls.

A cobertura de testes no Repositório do APP é de 35% na branch develop.

A cobertura de testes no Repositório da API é de 89% na branch develop.

---

• Complexidade Ciclomática

A complexidade ciclomática foi obtida através da análise na ferramenta Sonar.

**No Repositório do APP a ferramenta reportou uma Complexidade Ciclomática: 1,39921 (valor da complexidade/número de métodos: 324/253)

**No Repositório da API, a ferramenta reportou uma Complexidade Ciclomática: 1,626984 (205 valor da complexidade / 126 funções)

---

• Número de erros referentes a folha de estilo proposta

O número de erros foi obtido através da análise realizada pela ferramenta eslint incluída na integração contínua.

O número de erros encontrados pelo eslint no Repositório do APP foi 0.

Não há folha de estilo configurada na integração contínua do Repositório da API.

---

• Duplicação de código

A porcentagem de duplicação de código foi obtida através da análise realizada pela ferramenta sonar.

No Repositório do APP, foram encontradas 7 duplicações de código.

No Repositório da API, também não foram encontrados blocos de código duplicado.

---

• Percentual de endpoints documentados

A quantidade de endpoints documentados foi obtida da documentação da API no Swagger.

A quantidade total de endpoints foi obtida também no Swagger.

PED = QED / QTD * 100 => 27/31 * 100 = 87.09%

---

• Percentual de comentários no código

A métrica total de percentual de comentários no código foi obtida após a análise na ferramenta sonar.

Projeto	Pull Request	Linhas de Código	Linhas de Comentário	Porcentagem
API	856a2	2417	1136	32%
API	2b941	2184	1039	32.2%
API	3e19b	1916	775	40.44%
API	0dde8	1927	775	40.21%
API	04419	1935	775	40.05%
API	f926f	1954	795	40.68%
API	5b739	2122	848	39.96%
API	c541e	2080	848	40.76%
API	d3e05	2076	858	41.32%
API	c4d03	2076	858	41.32%
APP	86727	3108	139	4.47%
APP	de52b	2791	135	4.6%
APP	9bcc2	2263	89	3.93%
APP	12819	2577	106	4.11%
APP	b3a8e	2720	108	3.97%
APP	b63af	2793	112	4.49%
APP	c8976	2837	112	3.94%

---

• Burndown

Burndown Repositório APP

---

• Velocity

O velocity da equipe foi 24, e as justificativas podem ser encontradas neste documento.

---

3. Análise

Métrica	Resultado	Análise segundo indicador
Percentual de aderência ao processo	100%	ÓTIMO
Percentual de artefatos planejados concluídos por sprint	88.88%	BOM
Percentual de métricas coletadas	100%	BOM
Percentual de melhoria de métricas	72.22%	BOM
Percentual de histórias entregues por sprints	88%	BOM
Percentual de código testado (APP)	35%	RUIM
Percentual de código testado (API)	89%	BOM
Complexidade ciclomática (APP)	1.39	ÓTIMO
Complexidade ciclomática (API)	1.62	ÓTIMO
Número de erros referentes a folha de estilo proposta (APP)	0	ÓTIMO
Número de erros referentes a folha de estilo proposta (API)*	--	--
Duplicação de código (APP)	7	Não há indicador
Duplicação de código (API)	0	Não há indicador
Percentual de endpoints documentados	87.09%	--
Percentual de comentários no código (APP)**	4.47% (MÉDIA)	RUIM
Percentual de comentários no código (API)**	32% (MÉDIA)	Não há indicador para essa porcentagem

* = Não existe folha de estilo configurada na integração contínua da API.

3.1 Processo

3.1.1

O1: Garantir que o processo seja adequado ao contexto da equipe
Questão 01: A equipe está aderindo ao processo?
Métrica	Percentual de aderência ao processo
Resultado	100% - ÓTIMO
Comentários	O resultado indica uma aderência total ao processo o que é muito bom.

3.1.2

O1: Garantir que o processo seja adequado ao contexto da equipe.
Questão 02: A equipe está executando as atividades propostas?
Métrica	Percentual de artefatos planejados concluídos por sprint
Resultado	88.88% - Bom
Comentários	O resultado demonstra que a equipe executou uma quantidade boa de artefatos definidos pelo processo. Logo, a questão é respondida positivamente, já que sim, a equipe está executando as atividades propostas, embora nem todas ainda. Isso indica que o objetio de garantir que o processo esteja adequado à realidade da equipe, está sendo satisfeito.

3.1.3

O1: Garantir que o processo seja adequado ao contexto da equipe
Questão 02: A equipe está executando as atividades propostas?
Métrica	Percentual de melhoria de métricas
Resultado	72.22% - Bom
Comentários	Todas as métricas foram coletadas, ou seja, houve insumo para a coleta e a atividade foi realizada por completo. Percentual de código testado (API) subiu de 88% para 89%. Percentual de código testado (APP) permaneceu em 35%. Complexidade Ciclomática, do App e API, manteve a estabilidade no nível ótimo. Quantidade de erros, duplicação de código mantiveram nível ótimo Burndown estável, com entrega semanal Taxa de documentação de endpoints apresentou um aumento, de 85.19% para 87.09% Dessa forma, o resultado se mostra associado principalmente à qualidade com que o processo de desenvolvimento e medição foram executados. No geral, as métricas estão boas, se mantendo estáveis e até melhorando. O objetivo de garantir que o processo seja adequado está sendo atingido de forma satisfatória.

3.1.4

O1: Garantir que o processo seja adequado ao contexto da equipe
Questão 02: A equipe está executando as atividades propostas?
Métrica	Percentual de métricas coletadas
Resultado	100% - Ótimo
Comentários	O resultado de 100% indica cumprimento total das atividades de coleta de métricas. Executar as atividades propostas, acerca do processo de medição, nesse caso, garante adequação desse processo ao contexto da equipe.

3.2 Produto

3.2.1

O1: Garantir que o Software atenda as necessidades do cliente
Questão 01: O produto atende os requisitos do cliente?
Métrica	1. Percentual de critérios de aceitação concluídos por sprint; 2. Percentual de histórias entregues por sprints.
Resultado	1. - 2. 88,88% - Bom
Comentários	1. Os critérios não estão explicítos, os checkbox não estão marcados para efetivar uma coleta. 2. Boa parte das histórias foram entregues, mas não todas, apesar do nível estar bom, pode significar que em algum ponto do planejamento das sprints possa ter falhado.

3.2.2

O2: Garantir a manutenabilidade do código
Questão 01: Quanto do código está testado?
Métrica	1. Percentual de código testado
Resultado	1. 35% do App - Ruim 2. 89% da API - Bom
Comentários	Enquanto a cobertura de teste se manteve para o app, houve aumento de 1% na API, significando que o App não está conseguindo ter uma cobertura satisfatória como requisito de deixar o código manutenível.

3.2.3

O2: Garantir a manutenibilidade do código
Questão 02: O código está seguindo boas práticas de programação?
Métrica	1. Complexidade Ciclomática
Resultado	1. 1,39 do App - Ótimo 2. 1,62 da API - Ótimo
Comentários	Houve aumento de 0,09% na métrica coletada referente à medida anterior na parte do App e redução de 0,01% na API. Apesar do aumento na parte do App, isso não causa um rebaixamento de nível, fazendo com que permaneça no estado ótimo.

3.2.4

O2: Garantir a manutenabilidade do código
Questão 02: O código está seguindo boas práticas de programação?
Métrica	1. Número de erros referentes à folha de estilo proposta
Resultado	1. 0% do App - Ótimo 2. 0% da API - Ótimo
Comentários	Tanto o App quanto a API estão seguindo suas folhas de estilos propostas, permitindo que o código avance em padrões comuns, facilitando a compreensão e manutenibilidade.

3.2.5

O2: Garantir a manutenibilidade do código
Questão 02: O código está seguindo boas práticas de programação?
Métrica	1. Duplicação de código
Resultado	1. 0% duplicações no App 2. 0% duplicações na API
Comentários	Sem duplicações no código, persistência em fazer com que a manutenibilidade continue melhor.

3.2.6

O2: Garantir a manutenibilidade do código
Questão 03: Quanto do software está documentado?
Métrica	1. Percentual de endpoints testados
Resultado	87,09% - Bom
Comentários	Aumentou-se em 1,9%, mantendo-se no mesmo nível anterior, porém demonstrando que a documentação avançou facilitando a compreensão dos endpoints.

3.2.7

O2: Garantir a manutenibilidade do código
Questão 03: Quanto do software está documentado?
Métrica	1. Percentual de endpoints testados
Resultado	4,47% no App - Ruim 32% na API - Ruim 18,24% no total - Ruim
Comentários	A maior parte dos comentários da API são por conta do Swagger para documentação. Ainda é obscuro dizer sobre o indicador de quantidade de comentários, pois não se sabe do que se trata esses comentários.

3.3 Equipe

3.3.1

O1: Monitorar o desempenho da equipe de desenvolvimento.
Questão 01: O desempenho da equipe está satisfatório?
Métrica	Burndown
Resultado	1. 0 histórias fechadas do primeiro dia da sprint ao penúltimo dia. 2. 20 (todas as histórias) fechadas no último dia da sprint
Comentários	Pelo gráfico burndown observa-se que a equipe esteve trabalhando no desenvolvimento, porém sem fechar as histórias de forma contínua diariamente, pois não houve nenhuma história fechada do primeiro dia da sprint ao penúltimo dia, não há justificativa explicíta.

3.3.2

O1: Monitorar o desempenho da equipe de desenvolvimento.
Questão 01: O desempenho da equipe está satisfatório?
Métrica	Velocity
Resultado	24
Comentários	O velocity demonstrou que a equipe de desenvolvimento conseguiu concluir 24 pontos ao longo de uma sprint de uma semana, um grande aumento comparado ao velocity anterior que era 0.