Relatório de Desempenho da Sprint 3

1. Relatório de Desempenho da Sprint 3

1.1 Identificadores da Sprint

• Número da Sprint: 3
• Planejamento da Sprint: Planejamento
• Data: 29/05/2018 até 29/05/2018
• Resultados de Coleta de Métricas: Resultados

1.1.1 Responsáveis

Roger Lenke

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 baixa, de 33.33%, o que é um retrocesso em relação à sprint anterior. Uma das justificativas para a métrica ruim é o fato de que um novo processo de desenvolvimento passou a ser executado durante a sprint, o que pode ter atrapalhado o desenvolvimento. No entanto, neste caso, a métrica ruim está mais atrelada a falta de informação, já que não existe documentação e não há indícios da finalização da sprint. Desta maneira, muitas atividades não puderam ser auditadas quanto a realização, o que abaixou a métrica. Este fato também prejudicou a métrica de artefatos planejados concluídos por sprint, que regrediu para 66.66%.

Em relação à coleta de métricas, foram coletadas 94% do planejado. Este valor é um pequeno regresso em relação às sprints anteriores, e aconteceu porque na sprint 3 se planejava coletar a métrica percentual de critérios de aceitação concluídos por feature. A coleta dessa métrica não foi possível porque o autor não conseguiu informações atualizadas sobre quais são as features e seus critérios de aceitação.

A melhoria de métricas foi afetada pela falta de informações em relação à finalização da sprint, atingindo apenas 55.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 manutenabilidade do código.

Em relação ao que foi entregue durante a semana, um total de 30.76% das histórias planejadas foram realizadas. Este é um valor melhor do que o da sprint anterior, porém continua sendo um valor ruim. Não se sabe ao certo quais foram os motivos pelos quais a produtividade está ruim, já que não há documento de revisão/retrospectiva. Um fato que é possível observar com as entregas é que a equipe de desenvolvimento parece ter muita dificuldade com o front-end e sua tecnologia, já que normalmente as histórias relacionadas ao repositório do app não são entregues.

A cobertura de testes no repositório da api continuou a aumentar, atingindo 87.405%, o que mostra que a equipe está com um bom domínio da tecnologia e está conseguindo manter um bom nível de manutenabilidade neste módulo do sistema, o que é confirmado com outras métricas, como a complexidade ciclomática, que está num nível ótimo, e a duplicação de código, que também está num nível excelente. O número de erros na folha de estilo novamente não pode ser avaliado, porque a equipe não passou a usar nenhuma folha de estilo neste repositório.

Em relação ao app as métricas de complexidade ciclomática, a padronização código com folha de esitlo 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 apenas 23.96% e, portanto, novamente, recomenda-se que a equipe empregue um esforço neste lado do sistema para conseguir atingir o objetivo de medição dele.

A documentação da API continua num bom nível, tendo um acrécimo em relação a sprint anterior, atingindo 88.46%.

1.2.3 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, novamente, que a equipe foi capaz de realizar entregas parciais durante a semana, o que manteve a métrica num bom nível.

O velocity da equipe caiu dois pontos, o que indicaria um retrocesso na produtividade dela. No entanto, o autor atribui a diminuição desta métrica à falta de documentação correta para as histórias, já que não é possível identificar a pontuação de algumas das histórias concluídas.

1.3 Melhorias Propostas