Sprint 6 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 concluída?
US06 - Designar Membros	✅
US08 - Visualizar Burndown	✅
US15 - Pontuar História	✅
US16 - Alocar História para Sprint	➕ / ➖

1.1 O que foi feito?

• US06 - Designar Membros (Completo)
• US08 - Visualizar Burndown (Completo)
• US15 - Pontuar História (Completo)
• US16 - Alocar História para Sprint (BackEnd)

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

• US16 - Alocar História para Sprint (FrontEnd)
  • Desenvolvimento tardio do FrontEnd devido falta de proatividade de membros do par ao qual a história foi alocada.
  • Problemas no desenvolvimento do backEnd devido à falta de conhecimento técnico.

2. Retrospectiva

2.1. O que deu certo?

• Pareamentos foram efetivos;
• MDS mostrou-se ainda mais independente para resolver os problemas propostos;
• Desenvolvimento ágil melhor refletido no burndown;
• Pequema melhoria com relação aos atrasos;

2.2. O que deu errado?

• Complexidade na realização de testes no código permanecem;
• Falta de comunicação entre os pareamentos
  • Pareamentos que finalizaram as histórias no início da sprint não auxiliaram outros alocados em histórias mais complexas, além disso, estes não solicitaram ajuda, demonstrando falta de comunicação entre os membros e atuação falha do scrum master em retirar os impedimentos.

2.3. Como melhorar?

2.3.1. Must Have

• O Scrum master deve estar mais atento ao que é relatado durante os stand ups;
• Utilizar biblioteca Chart.js para substituir a d3.js como forma de testar qual das duas é melhor aplicável ao nosso projeto em termos de complexidade e dinamicidade;

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

Como pode ser visto no gráfico, o desenvolvimento das histórias começaram cedo e os pontos foram queimados rapidamente. Entretanto, os integrantes do grupo que terminaram suas tarefas primeiramente não auxiliaram os demais que estavam com dificuldades para realizar suas histórias. Além disso, faltou proatividade dos membros que estavam realizando histórias mais difíceis em pedir auxílio, o que impossibilitou a queima de todos os pontos, deixando dívida para a próximo Sprint.

4. Velocity

Nessa Sprint pode-se ver que o grupo evoluiu em termos de reconhecer a sua capacidade para a queima de pontos. A Sprint passada completou-se sem nenhuma dívida e nessa Sprint o planejamento esteve próximo de ser alcançado com sucesso.

5. Relato do Scrum Master

Nessa Sprint o grupo de MDS se mostrou mais independente e assumiu algumas responsabilidades sozinhos. As histórias terminaram relativamente rápido, e isso foi reflexo do empenho da equipe nos pareamentos. Entretanto, isso também foi em parte um aspecto negativo, pois os membros que terminaram suas histórias não se disponibilizaram para ajudar aqueles que ainda não tinham terminado, e somado a isso, alguns membros também não requisitaram ajuda.

Diante do que foi exposto, percebe-se que houve uma certa falha na comunicação entre pareamentos diferentes, o que levou no atraso de uma das histórias selecionadas para o desenvolvimento.

6. Métricas

6.1 Churn

6.2 Duplicação

Na imagem fica explícito que a refatoração necessária não foi aplicada nos arquivos devidos, isto porque, a helper de validações permanece com duplicação em 6, o mesmo acontece com os testes da model de usuário e demais arquivos relatados na última sprint.

6.3 Cobertura

O aumento de códigos integrados à aplicação com cobertura abaixo de 100% ocasionou a queda na porcentagem de cobertura total, dessa forma, a mesma passou a ser de 95.01%, ainda acima do recomendado para a disciplina, mas não o suficiente próximo da excelência. O mesmo ocorreu com o hits/line.

6.4 Quadro de conhecimento

6.4.1 Antes da sprint 6

6.4.2 Depois da sprint 6

Os esforços para desenvolver testes de aceitação fizeram com que o conhecimento sobre essa tecnologia aumentasse para alguns membros, além disso, a existência de histórias que exigem muito do backEnd ocasionou melhoras no conhecimento sobre ruby on rails e testes ruby on rails, como pode ser observado no quadro. Além do mais, o desenvolvimento de testes unitários melhorou o domínio da equipe em relação à testes javaScript.