Resultados S1

• Monitoramento e Controle
  • Status das Estórias no Fim da Sprint
  • Burndown
  • Velocity
  • Retrospectiva
    • Ações Tomadas
  • Sentimentos
  • Produtividade
  • Daily
  • Evolução do Conhecimento
  • Análise do Scrum Master
  • Análise do Product Owner
• Indicadores de Qualidade do Código
  • ABC Metric
  • Complexidade Ciclomática
  • Tamanho das Classes
  • Cobertura de Testes
  • Análise do Tracker
• EVM
  • Gráficos
    • Valor Planejado x Custo Real x Valor Agregado
    • Variação de Custos x Variação de Prazos
    • Índices de Desempenho
  • Análise do Tracker

---

Monitoramento e Controle

Status das Estórias no Fim da Sprint

Pontos Concluídos: 42

Burndown

Velocity

Retrospectiva

Ações Tomadas

• Para o conhecimento de testes foi conversado com todos da equipe para que tomassem algumas iniciativas: primeiro pesquisar na internet sobre testes (já que alguns ainda não tinham ao menos procurado sobre), ver se alguém da equipe pode sanar alguma dúvida ou explicar sobre testes, e caso ainda estivessem com dúvidas procurassem o coache. (E para caso as dúvidas fossem pertinentes de vários membros, um dojô de teste seria uma alternativa)

• Para os horários dos dailys procurar uma maneira mais eficiente para que todos os membros participem, ajudando a minimizar o gap de comunicação.

• GPP ter o compromisso de atualizar a wiki e manter up-to-date.

Sentimentos

Produtividade

Daily

Integrante	Dom	Seg	Ter	Qua	Qui	Sex
André	✔️	❌	✔️	✔️	✔️	✔️
Emanoel	✔️	✔️	✔️	✔️	✔️	❌
Filipe	✔️	✔️	✔️	✔️	✔️	✔️
Guilherme	✔️	❌	✔️	✔️	❌	✔️
Igor	❌	❌	✔️	❌	✔️	❌
Leonardo	✔️	✔️	✔️	✔️	✔️	✔️
Lucas	✔️	❌	✔️	✔️	✔️	✔️
Batista	✔️	❌	✔️	✔️	✔️	❌
Figueiredo	✔️	✔️	✔️	✔️	✔️	❌
Naiara	✔️	✔️	❌	✔️	❌	❌
Victor	✔️	✔️	✔️	✔️	✔️	❌
Vinícius	✔️	❌	✔️	✔️	✔️	✔️

Evolução do Conhecimento

Análise do Scrum Master

As reuniões aconteceram todos os dias da semana e teve lista de presença para saber quem estava presente. De 64 pontos planejados foram entregues 42, onde nem todos os grupos conseguiram entregar suas histórias, deixando de débito para a sprint 2.
Percebeu-se que o valor agregado foi menor que o custo planejado portanto os índices de custo e prazo estão negativos.
A cobertura de teste aumentou em relação à release anterior, isso se deu pelos integrantes estarem motivados. A produtividade do time aumentou muito a partir da sexta feira, próximo à data da reunião.

Análise do Product Owner

A maior parte das histórias foram entregues, os critérios de aceitação auxiliaram a equipe de desenvolvimento com a implementação das histórias, contudo algumas histórias importantes não foram implementadas, ficando como débitos para a próxima sprint. Os critérios de aceitação foram validados com o cliente e auxiliaram este a entender como funciona os critérios de aceitação e que toda semana será entregue um incremento de software a ele, tendo assim uma funcionalidade nova ao fim de cada sprint.

---

Indicadores de Qualidade de Código

ABC Metric

Segundo os parâmetros descritos no Relatório de Métricas para ser considerado bom, um arquivo deve ter o valor abaixo de 15. Segundo a Saída da Ferramenta, 2 arquivos não estão de acordo com o estipulado. No Gráfico Comparativo é possível ver que a porcentagem de arquivos considerados bons no projeto aumentou em relação a Release 1.

Saída da Ferramenta

Gráfico Comparativo

Complexidade Ciclomática

Segundo os parâmetros descritos no Relatório de Métricas para ser considerado excelente, um arquivo deve ter o valor até no máximo 3. Segundo a Saída da Ferramenta, 2 arquivos não estão de acordo com o estipulado. No Gráfico Comparativo é possível ver que a porcentagem de arquivos considerados excelentes no projeto aumentou em relação a Release 1.

Saída da Ferramenta

Gráfico Comparativo

Tamanho das Classes

Segundo os parâmetros descritos no Relatório de Métricas para ser considerado bom, um arquivo deve ter o valor até no máximo 100. Segundo a Saída da Ferramenta, todos os arquivos estão de acordo com o estipulado. No Gráfico Comparativo é possível ver que a porcentagem de arquivos considerados bons no projeto continuou 100%.

Saída da Ferramenta

Gráfico Comparativo

Cobertura de Testes

Segundo os parâmetros descritos no Relatório de Métricas para ser considerado bom, o projeto deve ter no mínimo 90% de cobertura de testes. Segundo a Saída da Ferramenta, o projeto está com 80.68% de cobertura. E no Gráfico Comparativo é possível ver que a cobertura aumentou em relação a Release 1.

Saída da Ferramenta

Gráfico Comparativo

Análise do Tracker

Todas as métricas colhidas pela ferramenta, ou melhoraram em relação ao projeto todo (ABC Metric e Complexidade Ciclomática) ou continuaram excelente (Tamanho das Classes). A Cobertura de Testes mesmo aumentando consideravelmente, ainda está abaixo do aceitável pela disciplina, que é 90%. Para que esse indicador melhore ainda mais, o estudo de testes em Rails será intensificado.

---

EVM

Gráficos

Valor Planejado x Custo Real x Valor Agregado

Variação de Custos x Variação de Prazos

Índices de Desempenho

Análise do Tracker

Nessa primeira Sprint foram planejados 64 pontos e feitos apenas 42 pontos, passando assim 22 pontos para a próxima Sprint. O planejado para entregar para o cliente foi o total de 20,90% do projeto inteiro, como não foram entregues todos os pontos, foram entregues apenas 12,50% do projeto, um deficit de 8,40% que serão acrescentados a próxima Sprint.