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

1 Indicadores de Qualidade do Processo

1.1 Fechamento da Sprint

A sprint teve seu fechamento no dia 24/06 conforme planejado na cerimônia de de finalização/review de sprint. Além disso houve a o review da release como um todo uma vez que está é a ultima sprint.

1.2 Burndown

1.3 Velocity

1.4 Retrospectiva

  • Bom

    • Funcionalidade planejadas no roadmap foram todas finalizadas
    • Adição de alguma funcionalidade extras

  • Ruim

    • Falta de tempo por causa do fim do semestre
    • Apatia de alguns no final
    • Complexidade técnica

  • A Melhorar

    • Contato/compromisso do cliente
    • Testes

1.5 Quadro de Conhecimento

1.6 Análise do Scrum Master

A equipe conseguiu, pela análise do burndown e pelas TS concluidas, finalizar todo o trabalho planjeado para essa sprint. Isso inclui a US procedente do sprint 6 além das correções e melhoramentos(TS) planejados para essa sprint. Com isso finalizamos o desenvolvimento da release 2 com um aplicativo funcional e com as funcionalidades desejadas pelo cliente.

Contudo, o time passou por um sprint apertada no quisito de tempo devido à dificuldade no sinal do semestre. Como podemos ver pelo burndown e pelas TS concluidas, o trabalho foi realizado perto do prazo final da sprint. Podemos atribuir também o fator de motivação e conhecimento técnico para esse comportamento. Uma vez que no review parte do time mostrou interesse e outra não.

2 Indicadores de Qualidade do Código

2.1 Métricas

GPA

  • APP

  • API

Complexidade Ciclomática

  • APP

Duplicação

  • API

Cobertura de Testes

  • APP

  • API

2.2 Análise do Scrum Master

No APP há, em todas as sprint, uma notificação de complexidade, sendo ela em relação a função render do react, onde o código é um JSX, ou seja, a complexidade se da ao fato do jslinter não analisar de forma ideal um códifo JSX. Onde há um mixin de js com XML causando assim a complecidade.

A cobertura de código não foi elevado no aplicativo pela grande dificuldade da equipe no apredizado da plataforma de test, como podemos ver pelo quadro de conhecimento. Seja realizado apenas test de aceitação de funcionalidades. Em contra partida a cobertura na parte server side foi bem sucedida, onde quase todas as funcionalidades estão cobertas por teste.

Houve um duplicação encontrada na api. Contudo essa duplicação é necessaria uma vez que estão em arquivos de configuração de ambientes diferentes. A configuração é a mesma, porém devemos configurar tanto no arquivo de ambiente de desenvolvimento quando de produção.

3 EVM

3.1 Análise do Scrum Master

A sprint de forma geral foi positiva em relação aos custos. Isto se deve ao fato de ser uma sprint voltada para correção de bugs, ou seja, uma release com muitas TS e poucos pontos. Tudo o que foi planejado foi entrege e o valor agredado igual ao planejano mostra essa entrega. Contudo o valor real ficou abaixo do esperado pelo fato de ser um sprint com baixa pontuação.

Quanto aos índices, o de variação de custo mostrou um valor positivo o que mostra que o rendimento da Sprint foi favorável, uma vez que o valor agregado acabou sendo maior que o real e a variação de prazo se manteve zerado pois o que foi planejado foi de fato entregue o que impactou diretamente no indice de desempenho de prazo, que se manteve no valor ideal. O CPI deu um grande salto pelo fato do que o valor agregado ser maior que o custo real, levando a conclusão de que esses últimos pontos foram super valorizados.