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: 22/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

Métrica	Melhoria Proposta
Percentual de aderência ao processo	Documentar de maneira correta a finalização das sprints. Se possível documentar também as atividades realizadas, de maneira a facilitar o trabalho de medição. Caso uma atividade não seja feita, documentar a razão.
Percentual de artefatos planejados concluídos por sprint	Documentar de maneira correta a finalização das sprints. Se possível documentar também os artefatos produzidos, de maneira a facilitar o trabalho de medição. Caso um artefato não seja feito, documentar a razão.
Percentual de métricas coletadas	Tentar contornar quaisquer problemas na coleta das métricas mais difíceis e não automáticas, se possível entrevistando os membros da equipe de desenvolvimento e os stakeholders. Realizar a coleta no dia correto para que a métrica seja mais próxima da realidade.
Percentual de melhoria de métricas	Relacionado a todas as outras métricas.
Percentual de critérios de aceitação concluídos por feature	Produzir uma lista dos critérios de aceitação de todas as features, para que seja possível observar quais são os critérios planejados por sprint e realizar a coleta desta métrica.
Percentual de histórias entregues por sprints	Identificar qual é o real problema da produtividade na equipe. Negociar com os stakeholders a realização de spikes e diminuição do escopo para trabalhar melhor no produto. Alocar mais pessoas no front-end que parece ser a maior dificuldade da equipe.
Percentual de código testado	Focar os testes no app, que é o repositório menos testado.
Complexidade Ciclomática	Manter o trabalho que está sendo feito.
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	Manter o trabalho que está sendo feito.
Percentual de endpoints documentados	Documentar os endpoints que estão faltando.
Percentual de comentários no código*	--
Burndown	Continuar o trabalho que está sendo feito, se possível diminuindo as histórias em histórias e tasks para que seja possível visualizar as entregas durante a semana e a continuidade do trabalho.

* = Como a realização de comentários no código é muito situacional, não foi feita sugestão para esta métrica.