Relatório de Desempenho da Sprint 1

1. Relatório de Desempenho da Sprint 1

1.1 Identificadores da Sprint

Exemplo:

• Número da Sprint: 1
• Planejamento da Sprint: Planejamento
• Data: 8/05/2018 até 15/05/2018
• Resultados de Coleta de Métricas: Resultados

2.1.1 Responsáveis

Roger Lenke

2.2 Desempenho na Sprint

2.1.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. Como as métricas do ciclo passado não foram retirados, o objetivo fica defasado em relação a melhoria, já que não é possível realizar comparações e descobrir onde o projeto melhorou. No entanto, ainda é possível identificar os pontos ruins com a intenção de proporcionar melhorias futuras.

A adesão da equipe de desenvolvimento ao processo foi alta, atingindo 90%, o que é considerado BOM segundo os indicadores da métrica. Este é um ótimo valor, já que o processo não teve uma boa adesão com a equipe anterior. No entanto, as atividades de teste não foram realizadas, o que prejudica a qualidade do produto, que será analisada posteriormente. O fato dos testes não serem realizados também é evidenciado na métrica de artefatos concluídos por sprint, na qual os testes são o único "artefato" não realizado.

Em relação às métricas, foram coletadas 92% do que foi planejado. Este número é um bom número, considerando que nenhuma métrica foi retirada no ciclo passado e que o [Plano de Medição] e o Plano GQM não possuiam algumas informações que são necessárias para a realização da medição, como quais ferramentas utilizar. No entanto, não foi possível avaliar a melhoria das métricas, já que, como atestado anteriormente, não existem métricas do ciclo anterior.

Por estes motivos, o autor deste relatório considera BOM o desempenho da equipe de desenvolvimento no âmbito do processo, e também considera que a equipe está conseguindo conseguindo executar as atividades propostas.

2.1.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 manutenabilidade do código. Apesar deste objetivo só poder ser bem definido com o fim da release, ainda é possível analisar o sucesso da equipe em direção a ele.

Em relação ao que foi entregue durante a semana, um total de 30% das histórias planejadas foram realizadas. Apesar do número não ser ideal, a equipe de desenvolvimento teve grandes avanções em outros requisitos técnicos e na organização do trabalho em geral, apesar destes avanços não estarem descritos no planejamento.

Um grande problema que aconteceu nesta sprint foi a não realização dos testes no produto. Isso impacta diretamente na manutebilidade do código, que é um dos objetivos do GQM do produto. A cobertura de testes, tanto no repositório da API quanto no repositório do APP está abaixo de 40%, considerada RUIM. Por isso, deve ser seguida a recomendação descrita no Plano GQM que é a refatoração e elaboração dos testes unitários.

Em relação a complexidade ciclomática, folha de estilo, e duplicação de código, os resultado das métricas trás um resultado considerado ÓTIMO. No entanto, é relevante citar que não existe folha de estilo configurada para o repositório da API, de maneira que não foi possível avaliar a métrica de número de erros neste repositório.

A documentação da API está num nível BOM. Porém, isto se deve ao fato de que a equipe de desenvolvimento do ciclo 1 realizou à documentação, já que o autor deste relatório foi informado que a atual equipe de desenvolvimento não realizou nenhuma documentação a mais. Portanto, é importante realizar a documentação dos endpoints restantes para a próxima sprint, assim como documentar possíveis novos endpoints.

Por conta da não realização de testes, mas os bons avanços em relação a requisitos técnicos, o autor deste documento considera RAZOÁVEL o desempenho da equipe de desenvolvimento em relação ao produto.

2.1.2 GQM da Equipe

O GQM da equipe busca verificar qual o nível de desempenho da equipe de desenvolvimento na empresa. O gráfico Burndown registra, para este GQM, que todas as entregas que foram realizadas foram feitas nos últimos dias da sprint. Isto pode significar que a equipe não está conseguindo entregar durante a semana, seja pelo fato das histórias serem muito grandes ou porque não é possível trabalhar de maneira periódica. É necessário verificar a fonte deste problema, e, caso sejam as histórias com pontuação elevada, dividí-las para melhor acompanhamento do trabalho.

O velocity não será analisado, já que não existem fatores de comparação de sprints anteriores.

Como existem poucas métricas do GQM da equipe, e uma delas não foi analisada por falta de base história, o autor resolveu não indicar um parecer final em relação a este GQM.