Resultados S5
Pontos Concluídos: 41
-
A retrospectiva foi muito positiva pela participação e compreensão de todos quanto a importância da retrospectiva.
-
Conscientização dos membros da equipe sobre importância da reunião de retrospectiva e planejamento.
-
As dailys foram bem utilizadas como indicadores para que acontecesse uma maior integração e ajuda entre a própria equipe.
-
Estórias foram validadas pelo Product Owner na semana, para que o merge possa ser realizado antes da retrospectiva com o objetivo de fazer o melhor uso do tempo durante a reunião.
-
Conscientizar membros da equipe sobre importância da reunião de retrospectiva e planejamento.
-
Visitar e atualizar o cliente quanto a situação do projeto, com pelo menos a presença do PO.
-
Resolver dívidas de sprints anteriores.
| Integrante | Dom | Seg | Ter | Qua | Qui | Sex |
|---|---|---|---|---|---|---|
| André | - | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Emanoel | - | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Filipe | - | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Guilherme | - | ✔️ | ✔️ | ✔️ | ❌ | ❌ |
| Igor | - | ❌ | ✔️ | ✔️ | ✔️ | ❌ |
| Leonardo | - | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
| Lucas | - | ✔️ | ✔️ | ✔️ | ❌ | ✔️ |
| Batista | - | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Figueiredo | - | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| Naiara | - | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Victor | - | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
| Vinícius | - | ❌ | ❌ | ✔️ | ✔️ | ❌ |
Obs: A Daily não ocorreu no dia 28/05/2017 por uma decisão do Scrum Master da semana, devido ao baixo rendimento das dailys no domingo.
Houve um aumento significativo da produtividade da equipe, por conta disso todas as estórias foram entregues. Dívidas críticas de sprints anteriores foram pagas ou replanejadas. Testes automatizados foram implementados para garantir maior qualidade ao produto. Equipe amadureceu na resolução de problemas que surgem durante a sprint, tendo agora uma resposta rápida aos impedimentos. As dailys tornaram-se mais eficientes, pois os objetivos do evento ficaram claros para todos os membros, porém uma parte do time ainda não compreendeu a importância das reuniões de retrospectiva e planejamento. Houve uma mudança de requisitos por parte do cliente, o que dificulta a entrega do produto por conta da limitação de tempo.
Todos os critérios de aceitação foram feitos e validados com o cliente. Levando em consideração as semanas anteriores, os critérios foram bem entendidos pela maioria dos integrantes, o que evitou o retrabalho de algumas funcionalidades. Houve uma estória retirada, já que a mesma
Segundo o Relatório de Métricas, o valor máximo recomendado pela ferramenta rubocop para a métrica ABC metric é 15, arquivos que apresentem resultado maior que 15 estarão ofendendo a qualidade do código. Segundo a saída da ferramenta nessa sprint 11 arquivos estão ofendendo a qualidade.No gráfico comparativo é possível ver o percentual de arquivos bons diminuiu em relação à sprint passada, as devidas medidas devem ser tomadas para melhorar os números desta métrica.
Segundo o Relatório de Métricas, para um arquivo ser considerado como excelente o seu valor de complexidade ciclomática deve ser no máximo 3. A saída da ferramenta indica que 17 arquivos estão ofendidos, ou seja, com complexidade ciclomática maior que 3. No gráfico comparativo é possível ver que a qualidade relacionada complexidade ciclomática diminuiu em relação à sprint passada. Para melhorar a quantidade de caminhos que o código percorre e melhorar a complexidade ciclomática será necessário modularizar mais os métodos.
Segundo o Relatório de Métricas, para um arquivo ser considerado pelo rubocop como bom em relação à quantidade de linhas por classe, ele deve conter no máximo 100 linhas. Segundo a saída da ferramenta, 3 arquivos estão ofendendo a métrica de tamanho de classes. O gráfico comparativo mostra o percentual dos arquivos que estão com a qualidade boa em relação à tamanho de classes, é possível ver que os resultados pioraram em relação à sprint anterior.
Segundo o Relatório de Métricas o projeto deve ter cobertura maior que 90%. A partir da saída da ferramenta é possível ver que a cobertura é de 94%. A partir do gráfico comparativo é possível ver que a cobertura diminuiu em relação à sprint passada, porém ainda permanece maior que 90%.
As métricas coletadas pelas ferramentas foram ABC metric, Complexidade ciclomática, Tamanho das classes e Cobertura de teste. Todas as métricas coletadas caíram da sprint passada para essa semana. A cobertura de testes continua dentro da faixa aceitação especificada pela disciplina. Para a próxima sprint a equipe concentrará em não diminuir a qualidade do código.
Na Sprint 5 foram planejados 59 pontos, incluindo 29 pontos de Sprints anteriores. Foram entregues 41 pontos ao final da Sprint. Na visão do cliente, o projeto deveria estar com 62,50% concluído e para a equipe já foram feitos 92,04% do projeto. Essa diferença é dada por acréscimos de funcionalidades por parte do cliente, então naturalmente o projeto passará dos 100% por acréscimos das funcionalidades.
- Sprint 0
- Sprint 1
- Sprint 2
- Sprint 3
- Sprint 4
- Sprint 5
- Sprint 6
- Sprint 7
- Sprint 8
- Termo de Abertura do Projeto
- Plano de Gerenciamento do Projeto
- Plano de Gerenciamento de Escopo
- Plano de Gerenciamento de Tempo
- Plano de Gerenciamento de Riscos
- Plano de Gerenciamento de Custos
- Plano de Gerenciamento de Qualidade
- Plano de Gerenciamento dos Recursos Humanos
- Planos das Iterações
- Plano de Gerenciamento de Configuração
- Plano de Gerenciamento de Comunicação
- Plano de Gerenciamento de Integração
- Plano de Gerenciamento de Aquisicões
- Plano de Gerenciamento das Partes Interessadas