Relatório de Desempenho da Sprint 1 Release 3

1. Relatório de Desempenho da Sprint 1 Release 3

1.1 Identificadores da Sprint

• Número da Sprint: 1
• Planejamento da Sprint: Planejamento
• Data: 19/06/2018 até 26/06/2018
• Resultados de Coleta de Métricas: Resultados

1.1.1 Responsáveis

Harrison Pedro
Guilherme Sant'Ana

1.2 Desempenho na Sprint

1.2.1 GQM do Processo

O Plano GQM define, que o objetivo da realização do GQM do Processo é manter o controle e fazer melhorias no processo.

A adesão da equipe de desenvolvimento ao processo foi muito boa, de 100%, o que é considerado ÓTIMO segundo os indicadores da métrica. Isso se dá pelo fato do processo ter sido alterado no final da Release passada, logo é a primeira Sprint em que o novo processo foi executado e uma nova equipe de desenvolvimento que assumiu. Como a adesão foi excelente, o esperado do Percentual de artefatos planejados concluídos por sprint foi ÓTIMO, com 100%.

Com relação ao percentual de métricas coletadas, foram coletadas todas as métricas planejadas, logo de acordo com a análise do GQM, o resultado dessa métrica foi ÓTIMO. Já o percentual de melhoria das mesmas foi regular, com um percentual de 66.66%, mas ainda melhorou em comparação a sprint anterior que teve um percentual de 55%.

1.2.2 GQM do Produto

O Plano GQM define que o objetivo da realização do GQM do projeto é garantir que o software atenda as necessidades do cliente, além de garantir a manutenibilidade do código.

Em relação ao que foi entregue durante a semana, um total de 0% das histórias planejadas foram concluídas. A explicação para esse valor, segundo a equipe de desenvolvimento, ocorreu pois algumas issues não poderiam ser concluídas nesta sprint devido a falta de tempo e a tecnologia envolvida no projeto. Outro fator determinante para o baixo rendimento foi a dificuldade da equipe com a nova tecnologia, o que é esperado tendo em vista que essa é a primeira vez que os membros trabalham no projeto. Pelo que é possível inferir sobre o documento de retrospectiva o replanejamento feito devido a inviabilidade da issue 68 foi a adição das issues 63, 64 e 71. Contudo foi informado pela equipe de desenvolvimento em seu relatório de retrospectiva é que houveram progressos técnicos nas issues, 63, 64, 71 e 62 sendo esta última apenas com os testes faltando.

Pelas medições aferidas no dia 25/6/18 a cobertura de código da api encontrava-se em 88%. Outras métricas como erro de folha de estilo, duplicação de código permaneceram com os mesmos valores de 0% e algumas métricas como end-point documentados e complexidade ciclomática apresentaram melhoras desde a última sprint. A melhora nas métricas ocorreu pois havia no repositório contribuições da última equipe de desenvolvimento que ainda não haviam sido analisadas. Dessa forma as métricas apresentadas não refletem o desempenho do time atual de desenvolvimento

Em relação ao app, as métricas de complexidade ciclomática, a padronização código com folha de estilo e a duplicação estão em bons níveis, porém é notável a dificuldade da equipe com as tecnologias aqui empregadas. A cobertura de testes neste repositório é de 35%, o que apresenta um grande avanço quando comparado com os 23,96% da última coleta. Outras métricas como complexidade ciclomática e percentual de comentários no código possuíram pequenas melhoras.

Houve uma pequena diminuição na documentação da api saindo de 88,46% para 85,19%.

1.2.3 GQM da Equipe

O GQM da equipe busca verificar qual o nível de desempenho da equipe de desenvolvimento na empresa.

Não houve registro de Burndown pela equipe de desenvolvimento, pois não houve entrega de nenhuma história.

Já o velocity despencou em relação as sprints da release passada, totalizando 0 pontos, tendo como principal justificativa a dificuldade que a equipe encontrou com as tecnologias.

1.3 Melhorias Propostas

Métrica	Melhoria Proposta
Percentual de aderência ao processo	Manter o trabalho que está sendo feito
Percentual de artefatos planejados concluídos por sprint	Manter o trabalho que está sendo feito
Percentual de métricas coletadas	Manter o trabalho que está sendo feito
Percentual de melhoria de métricas	Relacionado a todas as outras métricas.
Percentual de critérios de aceitação concluídos por feature	Identificar no pull request quais foram os critérios de aceitação atendidos da feature naquele incremento de software.
Percentual de histórias entregues por sprints	Foi um cenário esperado pois este foi o primeiro contato da equipe com a tecnologia. E como mencionado pela equipe de desenvolvimento houveram avanços técnicos em algumas issues, o que mostra que a equipe está se familiarizando com a tecnologia.
Percentual de código testado	Busca dar mais enfoque nos testes do front-end da aplicação.
Complexidade Ciclomática	Esta métrica também apresentou melhoras desde a última coleta. Sugere-se que a nova equipe de desenvolvimento observe as contribuições realizadas pela última equipe.
Número de erros referentes a folha de estilo proposta	Continuar o trabalho feito no repositório do app. No repositório da api, recomenda-se realizar a configuração de uma folha de estilo na integração contínua.
Duplicação de código	Revisar o código para eliminar blocos duplicados.
Percentual de endpoints documentados	Documentar os endpoints que estão faltando.
Percentual de comentários no código	Acrescente apenas quando necessário.
Burndown	Evidenciar a existência do Burndown da Sprint.