1. Indicadores de Qualidade do processo

Fechamento da Sprint

Burndown

Retrospectiva

• BOM

  • Fomos bem produtivos
  • Nenhum grande defeito!
  • Alguns membros conseguiram entender de vez o React
  • Tá acabando! Dá pra ver o final.
  • Pessoal de MDS foi mais proativo/ativo

• RUIM

  • As TS ficaram largadas...
  • Não tem quadro de conhecimento
  • Semana de provas de outras matérias
  • Alguns membros não contribuíram tanto
  • Não conseguimos fazer funcionar o upload de imagem tal como queríamos.

• MELHORAR

  • Pegar o conteúdo que não foi feito para próximas sprints(pendências técnicas)
  • Fechar as TS.
  • Dar o gás!
  • Aparência pode melhorar.
  • Gráficos de commits a melhorar.

Análise do Scrum Master

Apesar do feriado que quebrou a semana no meio, o time permaneceu ativo e presente, foi possível manter uma linearidade na produtividade.

Quanto ao processo nenhuma mudança drástica se viu necessária, o time estava cada vez mais sincronizado e os grandes dilemas como distribuição do conhecimento, tempo para pareamento foram parcialmente superados. Por outro lado o time ainda não conseguiu mostrar maturidade na pontuação das stories, uma vez que uma delas deixou de ser entregue. Entretanto existe a dúvida em relação a eficiência das pontuações no nosso meio.

Nosso velocity diminuiu em relação a Sprint passada, visto que 42 pontos foram entregues na Sprint 5. A pontuação outra vez não parece fazer sentido no nosso contexto, onde trabalhamos com tantas pendências técnicas que o valor entregue na Sprint parece ofuscado. O que reforça mais a tese de que pontos não estão sendo úteis, é a observação do nosso burndown, com oscilações assustadoras.

2. Indicadores de Qualidade do Código

GPA da API

GPA do APP

Duplicação de código no APP

No app as chamadas de callback do redux eram vistas como replicação, quando na verdade é sempre necessário chamar o callback dessa forma.

Duplicação de código no API

O code climate ainda acusou algumas duplicações de código por similaridade, engano.

Cobertura da API

A cobertura caiu na release pois algumas funcionalidades como não puderam ser testadas pela divergência do banco no Travis. Por isso o teste foi colocado como pendente.

Cobertura da APP

Os testes do app continuaram dando muito trabalho e pouco valor de segurança para o time. A conclusão minha como Scrum Master é que os testes de front-end seriam úteis apenas para evoluções futuras quando o produto estivesse mais estável, tal que esses testes serviriam como testes de regressão. Por hora, eles dispendem muito trabalho para manutenção e pouca ou nenhuma segurança de qualidade, o que os torna prejudiciais ao processo.

A cobertura permaneceu baixa e só foi garantido que nenhum desses testes quebrassem, tal que apenas as funcionalidades principais continuaram a ser testadas.

3. EVM

3.1 Análise do Scrum Master

A sprint não finalizou o planejado, ainda que os resultados tenham sido satisfatórios pela resolução de algumas pendências técnicas. No CV evidencia é possível notar o custo desse atraso na sprint.

O EV e o AC chegaram muito próximos, mostrando que a produtividade do projeto como um todo é satisfatória, isso é enfatizado pelo CPI que está em um limite bom. Em questão de valor entregue as sprints estão quase que alinhadas com o custo real. Entretanto é possível ver no SPI que as entregas estão atrasadas dentro do cronograma do projeto. Ou seja, estamos entregando próximo do planejado mas com certo atraso.