Resultados Sprint 01
A sprint teve seu fechamento no dia 15/05 conforme planejado na cerimônia de de finalização/review de sprint. Nessa cerimônia ocorreu via discord - aplicativo de chamada de voz. A disponibilidade de todos foi o motivo da reunião ter sido realizada de noite (22h) da segunda-feira.
-
Bom
- Escolha de boas historias para início
- Colaboração entre times
- Pareamentos funcionaram
- Dedicação da equipe
-
Ruim
- Não saber teste
- Dificuldade para configurar ambiente
- Mudanças de papéis
- Horários
- Complexidade técnica
-
A Melhorar
- Papel do Scrum master
- Compromisso com os horários
Com a análise do burndown, uma vez que as entregas foram realizadas no ultimo minuto da sprint, podemos perceber que a equipe teve uma grande dificuldade em trabalhar com a nova tecnologia. Outro ponto que deve ser levado em consideração é que devido a falta de disponibilidade o time só pode se reunir para produzir no domingo. Onde percebemos a primeira entrega e assim uma dupla, que já pode adiquirir conhecimento, pode contribuir com outra dupla em outra entrega.
Com a análise da review, temos que grande parte da equipe só conseguiu configurar o ambiente no domingo(14/05). O que gerou um atraso para o desenvolvimento da sprint. Com isso grande desmotivação sobreveio sobre o time.
Por fim, a dificuldade em desenvolver testes funcionais na plataforma react native teve grande impacto na sprint. Uma vez que nenhum integrante da equipe tinha total dominio sobre o assunto. Podemos perceber isso no quadro de conhecimento. O que levou à abertura de uma exceção em relação a definição de pronto. Caso o teste funcional fosse obrigatório nenhum US seria concluida. Dessa forma esses teste não foram obrigatórios, na próxima sprint devem ser realizados e serão obrigatórios.
Não foram identificados casos de duplicação de código
O valor do GPA(média de notas) ficou em 4 de uma média máxima de 4. Em um total de 48 arquivos. Isso quer dizer que a nota de cada arquivo foi A. Essa nota se basea na nota do numero de linhas, churn e issues dentro de cada página. Uma vez que estamos utilizando um framework em JS, também estamos utilizando eslint para a análise ciclomática do código e percebemos que a complexitade nos métodos de render estão altas. Isso se deve ao numero elevado de possiveis cófigurações de telas dependendo dos resultados, isto é, o método render é responsável por manipular os diferentes estados da view do app. Contudo esse método é o responsável por isso e não foi encontrado um solução alternativa no framework react.
Essa sprint se mostrou bem positiva no que tange os custos devido a equipe conseguir entregar tudo aquilo que foi planejado. O valor agregado e o planejado se igualaram, porém o valor acumulado ficou um pouco abaixo pois aquilo que foi entregue corresponde a uma proporção inferior ao esperado (uma vez que as sprints seguintes tendem a ter uma pontuação maior e no ideal as mesmas possuam pontuações mais homôgeneas).
Quanto aos índices de variação, eles foram não foram tão ruins, mas poderiam ser melhor uma vez que o CV (cost variance) foi negativo já que o valor agregado (EV) foi inferior ao custo real (AC) e o SV (Schedule Variance) manteve-se zerado visto que não houve variação entre o valor agregado (EV) e o planejado (PV). Já o CPI (Cost Performance Index) deixou um pouco a desejar por ficar abaixo de 1 e o motivo é justamente ter um custo real inferior ao que de fato foi agregado, demonstrando portanto que os recursos não foram alocados da forma mais eficiente nesse sentido. Por fim, o SPI (Schedule Performance Index) se manteve em 1 o que significa que o cronograma foi respeitado e que as funcionalidades foram entregues no período correto.