Sprint 5 Resultados

Sumário

1. Revisão

2. Retrospectiva

3. Burndown Chart

4. Velocity

5. Relato do Scrum Master

6. Métricas

---

1. Revisão

História	Foi concluida?
US022 - Manter Issue	✅
US011 - Manter Revisão de Sprint	✅
US15 - Pontuar História	✅
US06 - Designar Membros	✅

1.1. O que foi feito?

• US 11 - Manter Revisão de Sprint
  • Completo
• US 06 - Designar Membros(Apenas BackEnd)
  • Completo
• US 15 - Pontuar História - (Apenas BackEnd)
  • Completo.
• US 22 - Manter Issue(Apenas FrontEnd)
  • Completo.

1.2. O que não foi feito e por que não foi feito?

Todas as histórias que compõe o backlog da sprint foram desenvolvidas.

2. Retrospectiva

2.1. O que deu certo?

• A equipe desenvolveu uma boa comunicação nos Pull Requests;
• Equipe de MDS se tornou mais madura para desenvolver suas atividades;
• A integração entre os PR’s do Github e o Slack melhorou a rastreabilidade;
• Melhoria dos critérios de aceitação nas Issues;

2.2. O que deu errado?

• Atrasos ainda ocorrem;
• Dificuldade de realizar os testes devido à complexidade do código;

2.3. Como melhorar?

2.3.1. Must Have

• Atraso não justificado maior que 10 minutos terá que pagar balinha/bombom para cada membro da equipe.

2.3.2. Nice to Have

• Refatoração do código para diminuir o acoplamento entre a nossa aplicação e as API’s utilizadas.

3. Burndown Chart

O gráfico desta sprint demonstra que os pontos começaram a ser queimados logo após o primeiro dia da sprint, mostrando que a equipe de desenvolvimento tem se tornado cada vez mais ágil. Do dia 07 a 09 entretanto, nenhum ponto foi queimado, o que evidencia a dificuldade em realizar testes devido à complexidade do código, conforme relatado anteriormente. Após esse período, nos últimos dois dias os pontos foram queimados de maneira mais homogênea, obtendo-se um fim de sprint positivo, com todos os pontos queimados.

4. Velocity

Os 8 pontos planejados da sprint foram cumpridos de um total de 12 (devido à divida do manter issue) o que manteve o velocity próximo à 13, conforme sprint anterior. Com base no gráfico inferimos que a produtividade da equipe se aproxima da estabilidade.

5. Relatos do Scrum Master

Nessa sprint a cobertura de testes no BackEnd chegou a 90%, o que deu mais tranquilidade ao time, tornando possível concluir as demais histórias planejadas e sanar todas as dívidas que ficaram da sprint passada. Além disso, a melhora na cultura de comunicação nos Pull Requests foi muito positiva, trazendo maior profissionalidade ao time, o que fica evidente nos relatos referentes à maturidade do time de MDS. Além disso, a integração do GitHub com o slack facilitou a rastreabilidade e a comunicação no GitHub.

Tendo em vista os pontos expressados anteriormente, pode-se concluir que foi uma sprint de sucesso, principalmente por não serem deixadas dívidas.

6. Métricas

6.1. Churn

6.2. Duplicação

O código com maior número de duplicações diz respeito ao arquivo de teste de helper de validação, com um total de 6 duplicações indicadas pelo codacy, logo, seria necessária uma refatoração. Além disso, percebe-se que há repetição de código em outros arquivos de teste como controller de usuário e release e model de usuário.

6.3 Cobertura de Testes

A cobertura de testes aumentou em cerca de 2%, de 95.22% para 97.4%,o que espelha o comprometimento da equipe com a qualidade do código desenvolvido, assim como o hits/line que saltou de 10.81 para 17.43.

6.4. Quadro de conhecimento

6.4.1. Antes da sprint 5

6.4.2. Depois da sprint 5

O conhecimento da equipe se estabilizou nessa sprint, como pode ser visto no quadro de conhecimento apresentado, de forma que após a mesma, apenas poucos indivíduos do time melhoraram seu conhecimento em testes rails.