Resultados Sprint 03 - fga-eps-mds/2017.1-Cadernos-API GitHub Wiki

1 Indicadores de Qualidade do Processo

1.1 Fechamento da Sprint

A sprint foi abortada no dia 25/05, conforme explicado nas mudanças do planejamento. E uma mini-sprint (3.1) foi realizada até o restante da sprint 3 com um novo objetivo. A Cerimônia de de finalização/review de sprint 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.

1.2 Burndown

1.3 Velocity

1.4 Retrospectiva

  • Bom

    • Decisão de mudança de estratégia de US
  • Ruim

    • Seleção de US que dependiam de uma da outra causando um block geral no time
    • Compromisso do time nas reuniões de final de semana.
    • Poucos tomando a frente do projeto, outros parados.
    • Motivação do time
    • Falta de compromisso
  • A Melhorar

    • Crescer em conhecimento e distribuir entre o time
    • Balanceamento do trabalho no time

1.5 Quadro de Conhecimento

1.6 TS realizadas na sprint 3.1

As TS finalizadas na sprint 3.1 foram:

  • Tarefas Usuário
  • Drawer
  • Ver caderno
  • Home screen

Por sua natureza de Technical Story não houve alteração no burndown.

1.7 Análise do Scrum Master

Um dos riscos lenvatados na release 01 era o conhecimento da plataforma react native. Esse risco foi contornado na realização de um pequeno protótipo funcional em react por um integrante do grupo, mostrando assim a capacidade do grupo de realizar o aplicativo. Contudo na época da release 1 não foi contornado o risco da distribuição de conhecimento. O que produziu uma dependencia enorme desse integrante. O que vemos nessa sprint é o colapso desse fato. Onde o mesmo ficou sobrecarregado e o time não conseguiu desenvolver o esperado sem a colaboração desse membro dedivo a grende dificuldade no conhecimento da plataforma.

As atividades realizadas na sprint 3.1 foram satisfatórias, isto é, para alguns interessados o objetivo de apenas desevolver telas no react funcionou. Contúdo a outra parte não interessada do projeto não aproveitou. O desenvolvimento das telas do aplicativo foram realizadas ficando a integração ao backend para a sprint 4.

2 Indicadores de Qualidade do Código

2.1 Métricas

GPA

Complexidade Ciclomática

Duplicação

Não foram identificados casos de duplicação de código

Cobertura de Testes

2.2 Análise do Scrum Master

O valor do GPA(média de notas) ficou em 4 de uma média máxima de 4. Em um total de 78 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. Em relação a complexidade cinclomática, apenas um método se mostrou deficiente, contudo a prioridade do time era o desenvolvimento das principais funcionalidades do projeto. Ou seja, a equipe está ciente de onde deve atuar para melhorar a qualidade do código porém não há espaço ocioso para essa melhoria, assim, quando ouver, a equipe focará seus esforços onde se pode melhorar.

Como se pode observar pelo quadro de conheciment, o time ainda se mostra deficiênte em conhecimento de teste. Dessa forma a cobertura de teste não aumentou em relação a sprint passada.

3 EVM

3.1 Análise do Scrum Master

Se tratou de uma Sprint muito ruim em todos os sentidos o que acabou impactando nos custos. Os valores agregado e real foram nulos pelo fato das histórias serem abordadas para criar telas necessárias para o bom andamento do projeto.

Os indicadores demonstram como ela se tornou caótica pelo não cumprimento do que foi planejado. A variação de prazo por exemplo foi muito negativa pelo fato de nada que foi planejado de fato foi entregue, enquanto que os custos não variaram pelo fato de valor agregado e real serem nulos. Em relação ao índice de desempenho de custo e de prazo, se mantiveram zerados por não agregar o que se havia planejado nessa Sprint dando uma atrasada no cronograma.

Embora o resultado pareça muito negativo, a equipe reconhece que foi necessário dar esse passo atrás pra que o projeto tenha mais chances de sucesso e sabe-se que será necessário um esforço muito grande nas próximas Sprints. O cumprimento de atividades não previstas darão um melhor norteamento das próximas histórias e aumento da motivação da equipe por ela não se sentir perdida.