Sprint 7 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?
US23 - Planejar Sprint	✅
TS16 - Alocar História para Sprint	✅
US19 - Visualizar Velocity	✅
TS05 - Adapter para API	❌
TS06 - Refatorar Componentes Releases e Sprint	❌

1.1 O que foi feito?

• US23 - Planejar Sprint
• TS16 - Alocar História para Sprint
• US19 - Visualizar Velocity

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

• TS05 - Adapter para API
  • Dificuldade técnica para implementar a tecnologia na aplicação;
• TS06 - Refatorar Componentes de Releases e Sprint
  • Equipe muito atarefada com outras disciplinas;

2. Retrospectiva

2.1. O que deu certo?

• Escolha da biblioteca ChartJS facilitou a geração de gráficos;
• Equipe desenvolveu documentações que estavam faltando.

2.2. O que deu errado?

• Dependência de alguns membros de MDS em relação a outros atrasou desenvolvimento de histórias;
• Equipe muito atarefada com outras disciplinas.
  • Alguns membros não conseguiram realizar pareamentos eficientes;
  • Baixo comprometimento com os stand ups do meio ao fim da sprint;

2.3. Como melhorar?

2.3.1. Must Have

• Membros devem ser mais independentes para realizar suas histórias;
• Levar em conta o calendário acadêmico dos integrantes da equipe ao planejar a sprint;

2.3.2. Nice To Have

• Fazer o próximo planejamento e revisão da Sprint utilizando o Falko;

3. Burndown Chart

A partir do gráfico de burndown observa-se que a equipe queimou os pontos planejados, mas não o fez de maneira homogênea, como deveria ter acontecido. Isso porque o time possuiu muitas atividades externas devido o fim do período. Observa-se que os pontos só começaram a ser queimados dois dias após o início da sprint e depois continuaram a ser queimados descompassadamente.

4. Velocity

O velocity demarca entretanto, uma certa estabilização na produtividade da equipe, de forma que gira em torno de 13 pontos. Além do mais, todas as histórias planejadas foram concluídas, o que demonstra que esta realmente é uma boa quantia de pontos a serem alocados para uma sprint.

5. Relato do Scrum Master

Essa semana foi complicada para a equipe pois todos possuíam diversas atividades, afinal, é fim do semestre letivo. Entretanto, durante o período inicial da sprint a equipe esteve comprometida com os stand ups e reuniões, enquanto que no final os rituais foram negligenciados. Levando isso em consideração, foram deixadas dívidas referentes à histórias técnicas.

Um ponto positivo a ser relatado diz respeito à produção de documentações que estavam faltando na wiki e a mudança da biblioteca D3js para a chartjs que produz códigos mais claros e uma dinâmica melhor para a aplicação. O problema relativo à dependência em relação à outros membros da equipe retardou o desenvolvimento das histórias, isso por que devido à ocupação dos membros com atividades da faculdade, alguns pareamentos não foram efetivos. Isso nos acorda para a necessidade de levar em conta o calendário acadêmico dos integrantes para desenvolver as atividades.

A equipe decidiu que para testar a aplicação devemos utilizá-la para planejar a próxima sprint do Falko. Além disso, a partir dessa sprint será abandonado o acompanhamento do gráfico de Churn pois este tem se mostrado ineficiente para a avaliação e refatoração do código devido à inexperiência da equipe.

6. Métricas

6.1 Duplicação

As duplicações de código levantadas anteriormente persistiram, entretanto, um ponto interessante a ser considerado é que o número de arquivos com código duplicado não aumentou, o que se torna um ponto positivo e demonstra a preocupação do time ao desenvolver.

6.2 Cobertura

A cobertura, como visto na figura, caiu cerca de 5% em relação à sprint anterior, o que denota um número maior de linhas adicionadas sem cobertura de teste. Da mesma maneira hits/lines reduziu, passando a ser 9.44. Entretanto, a cobertura atende às exigências da disciplina.

6.3 Quadro de conhecimento

6.3.1 Antes da sprint 7

6.3.2 Depois da sprint 7

O conhecimento geral da equipe aumentou muito após essa sprint, entretanto, testes javascript e testes de aceitação ainda configuravam um gargalo, uma vez que o conhecimento se mantinha concentrado entre poucos integrantes. Essa característica denota um importante ponto a ser mitigado.