-
Notifications
You must be signed in to change notification settings - Fork 2
Relatório de Desempenho da Sprint 1 Release 3
- Número da Sprint: 1
- Planejamento da Sprint: Planejamento
- Data: 19/06/2018 até 26/06/2018
- Resultados de Coleta de Métricas: Resultados
Harrison Pedro
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%.
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%.
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.
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.
- Template do Plano de Medição
- Template para Resultado de Métricas Coletadas por Sprint
- Diretrizes e template para Objetivos GQM