Skip to content

Relatório de Desempenho da Sprint 2

Roger Lenke edited this page Jun 5, 2018 · 4 revisions

1. Relatório de Desempenho da Sprint 2

1.1 Identificadores da Sprint

  • Número da Sprint: 2
  • Planejamento da Sprint: Planejamento
  • Data: 15/05/2018 até 22/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. Desta vez, este objetivo pode ser melhor analizado, já que a maioria das métricas foi colhida na sprint passada.

A adesão da equipe de desenvolvimento ao processo foi alta, atingindo 100%, o que é considerado ÓTIMO segundo os indicadores da métrica. Este é um ótimo valor, sendo uma evolução em relação a sprint anterior. Outra importante mudança foi a realização de testes unitários durante a sprint, de maneira que 100% dos artefatos planejados foram realizados.

Em relação às métricas, foram coletadas 100% do que foi planejado. A melhoria aconteceu porque na sprint 2 foi possível medir o percentual de melhoria de métricas, comparando as métricas da sprint 1 com as da sprint 2. Além disso, as métricas de código dos diferentes repositórios foram divididas, de maneira que o número de métricas coletadas se aproxime mais da realidade. No entanto, o autor das medições notou que existem algumas métricas cuja a viabilidade de medição é muito pequena, como algumas métricas de código, que foram realizadas, mas de maneira diferente ao que foi exigido no Plano GQM.

O percentual de melhoria de métricas, que foi coletado pela primeira vez nesta sprint, é de 72.5%, o que um bom número, e mostra que a equipe está trabalhando ativamente para seguir melhor o processo e melhorar o produto. No entanto, a produtividade em relação aos entregáveis ainda está muito baixa, o que será discutido no GQM do produto.

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, apesar da produtividade ainda estar baixa.

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. 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 23.52% das histórias planejadas foram realizadas. Por ser uma métrica ruim recorrente, é necessário que a equipe de desenvolvimento se atente às possíveis causas deste problema. Segundo o documento de revisão da sprint 2, a principal causa deste problema foi a falta de conhecimento em relação as tecnologias e a realização de pareamentos entre indivíduos que não muito conhecimento sobre as linguagens utilizadas. O autor deste documento recomenda, então, que o pareamento seja realizado por nível de conhecimento. Além disso, a realização de spikes (caso o cliente acredite que seja válido) por ser útil para diminuir o risco em relação ao desenvolvimento.

Nesta sprint, foram realizados vários testes unitários no repositório da api, o que torna o objetivo relacionado a manutenabilidade mais próximo. No total, a cobertura passou de 0% para 86%, o que é um grande salto. A cobertura no repositório do app continua muito baixa, então, se recomenda que se faça um esforço maior neste lado do sistema em relação 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 ainda 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, apresentando melhoria em relação a sprint anterior. Alguns endpoints foram removidos, de maneira que o percentual total de documentação aumentou. No entanto, ainda é necessário realizar a documentação de alguns endpoints, que não são documentados desde o ciclo 1.

Apesar da falta de produtividade, e considerando o grande avanço na realização de testes, o autor considera RAZOÁVEL o desempenho da equipe de desenvolvimento em relação ao produto.

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, para este GQM, que as entregas foram feitas durante o decorrer da sprint, o que é uma melhoria em relação à sprint anterior. O velocity da equipe também aumentou em um ponto, porém com a quantidade de histórias não produzidas, essa melhoria se torna pouco relevante.

Como existem poucas métricas do GQM da equipe, o autor resolveu não indicar um parecer final em relação a este GQM.

Clone this wiki locally