Sprint 4 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 ?
US 12 - Manter Retrospectiva	➕/ ➖
US 14 - Manter História	✅
US 22 - Manter Issue	➕/ ➖
US 07 - Manter GPA	➕/ ➖
TS 03 - Vue X	✅

1.1. O que foi feito?

• US 12 - Manter Retrospectiva
  • Back-End finalizado
• US 22 - Manter Issue
  • Back-End finalizado
• US 14 - Manter História (Só possui backEnd)
  • Completa
• US 07 - Manter GPA
  • Back-End finalizado
• TS 03 - VueX
  • Estudar quais componentes precisam de tratamento de estado, para reduzir a confusão devido à necessidade de comunicação entre os componentes do VueJs;

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

• US 12 Manter Retrospectiva - Front-End ainda sem testes de JS
  • Falta de conhecimento sobre teste JS;
• US 22 Manter Issue - Front-End não iniciado
  • Devido à complexidade do Back-End da história o início do desenvolvimento do Front-End foi tardio;
• US 07 Manter GPA - Front-End ainda sem testes de JS
  • Falta de conhecimento técnico sobre teste JS;

2. Retrospectiva

2.1. O que deu certo?

• Equipe de MDS mais independente para desenvolver as histórias
  • Pareamentos MDS vs MDS foram produtivos
• O desenvolvimento das histórias iniciou mais cedo
  • Reunião de desenvolvimento no Sábado cooperou para a finalização das histórias mais cedo
• Divisão de histórias grandes em menores foi positiva para a distribuição e desenvolvimento
• A presença dos membros nos pareamentos melhorou
• Dívidas técnicas antigas foram concluídas

2.2. O que deu errado?

• Ausências e atrasos em reuniões
  • Stand-up meetings foram negligenciados;
  • Membros não avisaram com antecedência as ausências e atrasos nas reuniões;
• Critérios de aceitação não documentados atrapalharam o desenvolvimento de algumas histórias, tornando o processo de entendimento mais lento;
• Algumas histórias dependiam de funcionalidades já implementadas, devido a problemas com estas funcionalidades, o desenvolvimento foi prejudicado.

2.3. Como melhorar?

2.3.1. Must Have

• Melhorar comunicação
  • Avisar com antecedência atrasos e ausências;
• Comprometimento com o Stand-up (Presença e Pontualidade);
• Sempre documentar critérios de aceitação das histórias da Sprint;
• Desenvolver uma cultura de “Código Coletivo”;
• Sempre assinar as issues que estão sendo desenvolvidas;
  • Nunca assinar uma issue que não estão sendo desenvolvidas naquele momento;
• Seguir templates de Pull Request;

2.3.2. Nice to Have

• Pareamento paralelo para realizar refatorações no código;
• Disponibilizar ambiente de Homologação;

3. Burndown Chart

O gráfico desta _sprint_ deixa claro mais uma vez a influência positiva das reuniões no sábado na produtividade da equipe. Pode-se perceber que os primeiros pontos foram queimados logo no segundo dia da _sprint_, o que demonstra um desenvolvimento cada vez mais ágil. A partir de então, os pontos continuaram a ser queimados de forma quase homogênea.

É importante ressaltar que nesta _sprint_ todas as dívidas técnicas foram finalizadas e a US12 foi enfim terminada após três _sprints_, porém uma nova foi introduzida, o _front-end_ da US22 não foi concluído a tempo. Isto resultou em um débito de 4 pontos.

4. Velocity

Apesar dos 20,5 pontos totais da _sprint_ não terem sido queimados por completo, a conclusão de dívidas técnicas antigas e de quase todas as _user stories_ planejadas resultou em um aumento no _Velocity_ da equipe, de 11,833 pontos para 13 pontos.

Com base no gráfico apresentado, podemos inferir que a produtividade da equipe é crescente, mas tem se estabilizado aos poucos.

5. Relatos do Scrum Master

Nessa sprint, apesar dos esforços para desenvolver testes javaScript no front-End, a equipe não conseguiu fazê-lo, de modo que as histórias que dependiam destes foram consideradas finalizadas sem que os testes tivessem sido feitos. Além disso, acerca da manutenibilidade do código, foram feitos esforços para utilizar o vuex e melhorar a comunicação entre os componentes. Percebe-se por fim, que a equipe teve maior segurança com o desenvolvimento do backEnd das histórias.

É preciso salientar que alguns membros continuam negligenciando os stand ups, da mesma forma, observaram-se issues assinadas a muito tempo que não foram solucionadas. O sentimento de código próprio dificultou o entendimento do time acerca de problemas relacionados à histórias já integradas, por esse motivo, identificou-se a necessidade de desenvolver uma cultura de código coletivo na equipe. De maneira geral, a produtividade da equipe começou a se estabilizar e o conhecimento continua a aumentar a cerca das ferramentas, um exemplo, o docker, devido ao treinamento realizado.

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 testes de usuário e helper de validações, o que indica uma maior necessidade de refatoração nos mesmos, com um total de 3 duplicações indicadas pelo codacy. Além disso, percebe-se que há repetição de código em outros arquivos de teste como release, sprint e projeto.

6.3 Cobertura de Testes

Nesta sprint a cobertura de testes (back-end) deu um salto de quase 10%, atingindo, pela primeira vez, o mínimo exigido pela disciplina. Isso por que a equipe se tornou mais compromissada e se acostumou com o pipeline utilizado.

6.4. Quadro de conhecimento

6.4.1. Antes da sprint 4

6.4.2. Depois da sprint 4

Nessa sprint, como pode ser observado no gráfico, a equipe deu um salto na homogenização do conhecimento de modo que os conhecimentos em vueJs melhoram, principalmente devido aos esforços de desenvolver o frontEnd. O mesmo aconteceu com Ruby on rails, além disso, o treinamento de docker fez com que o time conhecesse a ferramenta, ampliando o nível de conhecimento no quadro acompanhado. Com relação a Html/css e testes rails as mudanças no quadro também podem ser observadas.