Sprint 2 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?
US03 - Conectar Conta ao Github	✅
US09 - Manter Release	✅
US10 - Manter Sprint	✅
US12 - Manter Retrospectiva de Sprint	❌
US14 - Manter História	❌

1.1 O que foi feito?

• US10 (FrontEnd);
• US09 (FrontEnd);
• US03 (Completa);

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

• US12 - Testes de Controller e Front-End
  • Faltou tempo devido ao desenvolvimento da história dívida (US09);
• US14 - Back-end e Front-End
  • Faltou tempo devido ao desenvolvimento da história dívida (US10);
  • Não utilização das ferramentas oficiais da API do Github;
  • Má organização da ordem de desenvolvimento das histórias;

2. Retrospectiva

2.1. O que deu certo?

• Melhora na comunicação graças à realização de feedbacks.
• Super pairing aumentou a frequência de pareamentos, contribuindo, assim, para a produtividade.
• A reunião realiza aos sábados mostrou-se efetiva.

2.2. O que deu errado?

• Interdependência entre histórias dificultou o desenvolvimento.
  • Solução de problemas ficaram em branches específicas, não na devel, onde estariam disponíveis para todo o grupo.
• Membros ausentes (Lucas e Kelvin viajaram).

2.3. Como melhorar?

2.3.1. Must Have

• Ser mais criterioso quanto à política de branches;
• Planejar melhor a escolha das histórias pensando na interdependência entre elas.

2.3.2. Nice To Have

• Realocar pareamentos em caso de ausência de membros;
• Fazer super pareamento (time inteiro) para atacar histórias críticas (gargalos) que se propagaram ao longo das duas sprints;
• Treinamentos de front-end para melhoria da produtividade.

3. Burndown Chart

Nesta sprint, como denotado no gráfico, os pontos começaram a ser queimados mais cedo (2 dias após o início). Isso se deve principalmente à realização da reunião no primeiro dia da sprint (sábado), que possibilitou a identificação e resolução imediata de gargalos e dificuldades.

A equipe conseguiu diminuir em oito o número de pontos de dívida. Por outro lado, dez pontos de dívida técnica ainda restaram. A próxima sprint deve quitar as dívidas deixadas, além de concluir novas histórias.

4. Velocity

O time conseguiu concluir mais pontos do que a última sprint, o que denota um crescimento no valor do velocity. Novamente o time superestimou sua capacidade, planejando mais pontos do que mostrou-se capaz de concluir. A equipe deve ter atenção à isso, e planejar um número de pontos mais próximo ao observado no velocity.

5. Relato do Scrum Master

Nesta sprint novamente foram deixadas dívidas e o principal motivo foi a falta de conhecimento do grupo com relação à API do Github, que interferiu até mesmo na ordem de realização das histórias. Outro fator importante foi a ausência de dois membros da equipe,o que contribuiu para a não realização das histórias.

Além disso, a interdependência entre as histórias alocadas e as demais mostrou-se um problema, pois impede o avanço da equipe quando há dívidas técnicas. Por esse motivo, a US14 voltou para o backlog, pois há histórias que são pré-requisitos para a sua realização.

Os super parings realizados foram efetivos, pois a equipe realizou mais pareamentos. Do mesmo modo, o feedback das atividades realizadas, coletadas pelo scrum master de forma anônima, possibilitou melhorias específicas a cada membro da equipe.

Por fim, a reunião de sábado se mostrou muito efetiva, uma vez que presencialmente os membros trabalham mais e de forma melhor.

Para a próxima sprint espera-se que os débitos sejam quitados, com o amadurecimento da equipe.

6. Métricas

6.1. Churn

6.2. Duplicação

Algumas controllers (Projects e Sprints) ficaram com uma nota muito baixa nesta sprint. Isso se deve ao fato que muitas das verificações feitas nessas controllers são parecidas. Deve-se lançar mão do uso das _helpers_ para evitar a duplicação de código.

6.3 Cobertura de Testes

A cobertura de testes no BackEnd subiu nesta sprint para cerca de 85%, ficando mais próxima do mínimo exigido pela disciplina (90%). A equipe deve manter este ritmo para que não seja introduzido código não testado na branch principal e que partes não testadas sejam cobertas.

6.4. Quadro de conhecimento

6.4.1. Antes da sprint 2

6.4.2. Depois da sprint 2

Percebe-se que o conhecimento da equipe evoluiu em termos das tecnologias utilizadas, principalmente com relação à vueJs e ruby on rails.