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

1 Indicadores de Qualidade do Processo

1.1 Fechamento da Sprint

1.2 Burndown

1.3 Velocity

1.4 Retrospectiva

BOM
- Menos dependência do Fábio
- Burndown escadinha \o/
- Bom desenvolvimento
- Boa organização
RUIM
- Falta de pareamento de verdade
- Alguns membros com pouco commit
- Cliente desanimado
- Falta mais iniciativa do pessoal
- USs mais difíceis ainda não implementadas
MELHORAR
- Mais pareamento
- Mais iniciativa
- Manter o ritmo
- Mais commits em MDS

1.7 Análise do Scrum Master

Nessa sprint 05, eu(Fábio) fiquei como scrum master e fora do desenvolvimento, sendo que um dos pontos a melhorar da SP 04 era a dependência que o time tinha sobre minha pessoa. Mas como pode ser visto pelo burndown o time conseguiu(até para a minha surpresa) seguir com um bom ritmo de desenvolvimento. Com isso, podemos concluir que essa foi a nossa melhor sprint em termos de resultados até o momento. :blush:

2 Indicadores de Qualidade do Código

2.1 Métricas

GPA

Complexidade Ciclomática

API
- Na API não problemas de complexidade.
APP

No APP há 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 gostar de XML... É só XML linter :expressionless:

Duplicação

O rblinter do codeclimate está dando código duplicado no arquivo schema.rb que é gerado automaticamente pelo rails. Há algumas outras notificações nos controllers, mas é coisa de 2 ou 3 linhas de código que se parecem por causa da estrutura REST, logo por não ser algo que vá impactar fortemente na qualidade do código, optamos por não mexer e manter simples.

No app os problemas identificados são mais em relação ao uso de (==) e não (===) e callbacks to tipo void que logicamente não tem retorno :expressionless:, como JS não é tipado e não estamos usado o Flow(tipagem estática do facebook para o react), não tem como o codeclimate saber que os callbacks não tem retorno.

Cobertura de Testes

Como a API é a parte mais importantemente do nossa arquitetura, estamos mantendo sempre uma cobertura acima de 95%.

Sobre a cobertura do aplicativo :cold_sweat: ... Estamos focando mais em actions, reducers e componentes. Mas dessa forma, está ficando de fora as requisições assíncronas, ou seja consideramos que os dados foram requisitados com sucesso.

3 EVM

3.1 Análise do Scrum Master

Essa sprint se mostrou surpreendente pelo fato de algumas pendências serem entregues e o que foi planejado foi ded fato concluído também. O valor planejado e o agregado não se igualaram pelo fato de ter entregue mais do que o previsto, uma vez que foram resolvidas pendências de sprints anteriores.

Quanto aos índices de variação, pode-se dizer que eles foram positivos exceto pelo fato que o CV (cost variance) foi negativo já que o valor agregado (EV) foi inferior ao custo real (AC) por haver um esforço extra para acabar com pendências. O Schedule Variance (SV) foi positivo uma vez que o planejado foi inferior ao que de fato foi entregue.

O CPI (Cost Performance Index) e o SPI (Schedule Performance Index) foram diferentes um do outro. Enquanto o CPI não mostrou um bom valor pelo fato do valor agregado ser menor que o valor real, o SPI foi muito bom pois tudo aquilo que foi planejado foi entregue no tempo correto, respeitando o cronograma, e ainda foram quitadas dívidas de sprints anteriores.

A partir desses dados, acredita-se que a equipe encontrou a maneira ideal de trabalhar e as próximas sprints sejam mais tranquilas pela maturidade encontrada no processo enfim ser a necessária para o andamento de um projeto, inclusive pelo fato de faltarem poucas histórias a serem desenvolvidas.