Sprint 3 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?
US 12 - Manter Retrospectiva	❌
US 04 - Importar Repositório	✅
US 05 - Listar Possíveis Projetos	✅

1.1. O que foi feito?

• US05 - Completa
• US04 - Completa

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

• US12 - Front-End
  • Falta conhecimento da equipe em tecnologias específicas relacionada à história;

2. Retrospectiva

2.1. O que deu certo?

• Super pairing ajudou a disseminar o conhecimento entre os membros da equipe;
• Equipe mais empenhada em desenvolver as atividades necessárias;

2.2. O que deu errado?

• Alguns membros faltaram os pareamentos aos quais encontravam-se alocados;
• Dívida técnica não foi concluída;

2.3. Como melhorar?

2.3.1. Must Have

• Membros devem estar mais presentes nos pareamentos;
• Devem ser realizados Treinamentos de Bootstrap;

2.3.2. Nice to Have

• Evitar ausências nos pareamentos

3. Burndown Chart

A utilização dos _super pairings_ mostrou-se um sucesso. O Burndown da sprint reflete isto: Os pontos começaram a ser queimados já no segundo dia, e continuaram a ser concluídos de forma mais constante até o fim da sprint. A dívida técnica foi deixada novamente, o que denota os 3 pontos que sobraram ao fim.

4. Velocity

Devido à maior quantidade de histórias concluídas, o velocity médio da equipe subiu, ficando próximo aos 12 pontos. Isto denota não só uma maior taxa de conclusão de pontos (15.5 pontos), mas um amadurecimento da equipe.

5. Relatos do Scrum Master

Nesta sprint o número de dívidas técnicas diminuiu, principalmente pelo grande esforço que a equipe fez na semana universitária. Esta estava muito empenhada com o desenrolar do projetos e todos dedicaram muito tempo à matéria. Os _super pairings_, aliados à reunião no sábado, ajudaram a equipe a desenvolver confiança e enfrentar os problemas logo no começo da sprint, o que ,como denotado no burndown, reflete-se na queima rápida dos pontos.

Devido às dívidas deixadas, a equipe foi dividida em dois grandes grupos nessa sprint, dessa forma, todo o time trabalhou simultaneamente nas mesmas histórias(exceto nas dívidas técnicas), de modo que metade foi alocada no *front-end* da aplicação, enquanto os demais trabalharam no *back-end*.

Embora a semana tenha sido muito produtiva nem todos os membros puderam participar dos *super parings* por motivos de viagem ou outras atividades, assim, a dívida técnica persistiu.

6. Métricas

6.1. Churn

6.2. Duplicação

Alguns arquivos críticos da sprint passada tiveram suas métricas melhoradas nesta sprint. O `sprints_controller.rb` manteve sua nota F, entretanto com 9 issues a menos. O arquivo `projects_controller.rb`, por sua vez, diminuiu sua duplicação e passou a ser julgado com a nota D, ao invés de F, o que indica um esforço da equipe em realizar a manutenção do código por meio de refatoração.

6.3 Cobertura de Testes

A cobertura de testes aumentou pouco em relação à última sprint, porém os hits/linha subiram também. Isso mostra que a equipe apenas testou aquilo que produziu. Deve-se haver um esforço na produção de testes para atingir o valor mínimo (90%), de modo que não existam pedaços de código que não sejam testados.

6.4. Quadro de conhecimento

6.4.1. Antes da sprint 3

6.4.2. Depois da sprint 3

Devido ao grande esforço da equipe no desenvolvimento, o conhecimento da mesma aumentou em termos das tecnologias Ruby on Rails, VueJs e Github. Os membros de Gpp, por exemplo, ampliaram bastante o nível de conhecimento em relação à última tecnologia citada.