Informações Básicas da Sprint
| Sprint | 4 |
|---|---|
| Início | 12/09/2018 |
| Término | 18/09/2018 |
| Duração | 7 dias |
| Pontuação Total | 31 |
| Pontuação Concluída | 17 |
Resumo da Sprint
| Total de Pontos Planejados | 9 |
|---|---|
| Total de Pontos Planejados e Concluídos | 3 |
| Total de Pontos de dívida passada | 22 |
| Total de Pontos de dívida concluídos | 14 |
| Total de Pontos Adicionados | 0 |
| Total de Pontos Adicionados e Concluídos | 0 |
| Total de Pontos Concluídos | 17 |
| Dívida para a próxima Sprint | 14 |
Presença na Sprint Review e Retroscpective
| Membro | Presença |
|---|---|
| Iasmin Mendes | |
| Renato Valério | Justificado |
| Gabriel Davi | |
| Heron Rodrigues | |
| João Lucas Zarbiélli | |
| Lucas Maciel | |
| Matheus Gomes | |
| Weiller Fernandes |
Papéis
| Papel | Responsável |
|---|---|
| Scrum Master | Iasmin Mendes |
| Product Owner | Renato Valério |
| Arquiteto | Iasmin Mendes |
| DevOps | Gabriel Valério |
| Time de Desenvolvimento |
Gabriel Davi Silva Pereira Heron Rodrigues Sousa João Lucas Fragoso Zarbiélli Lucas Maciel Aguiar Matheus Gomes Ferreira Weiller Fernandes Pereira |
Sprint Backlog
| Issue | Descrição | Pontos | Responsáveis | Status | |
|---|---|---|---|---|---|
| P L A N E J A D A S |
#115 | Configurar arquivos de teste | 1 |
Iasmin Mendes |
Concluída |
| #54 | US2 - Avaliar local (Backend) | 3 |
João Lucas Gabriel Davi |
Não Concluída | |
| #107 | US6 - Favoritar local (Backend) | 3 |
Lucas Maciel Weiller Fernandes |
Não Concluída | |
| #114 | Treinamento de testes | 2 |
Iasmin Mendes |
Concluída | |
| D Í V I D A S |
#80 | Fazer protótipo do projeto | 8 |
Matheus Gomes Heron Souza |
Não Concluída |
| #83 | Atualizar RoadMap Geral com as histórias de usuário | 2 |
Iasmin Mendes |
Concluída | |
| #81 | Configurar ambiente de desenvolvimento do frontend | 5 |
Renato Valério Equipe do FGAApp |
Concluída | |
| #79 | Elaborar identidade visual | 5 |
Iasmin Mendes Renato Valério |
Concluída | |
| #33 | Construir burndown de riscos | 2 |
Iasmin Mendes Renato Valério |
Concluído |
Retrospectiva da Sprint
Pontos Positivos
- Mudou a cor do nosso módulo de aplicativo e a equipe ficou mais satisfeita
- Toda a equipe começou a mecher com o código
- Treinamento de teste foi top
Pontos Negativos
- Indecisão do cliente
- Muita prova de outras matérias durante a sprint
- Testes foram difíceis: Ninguém terminou as issues
- Issue do protótipo estava muito grande
Melhorias
- Estudar mais testes
- Separar os dias da Sprint Review e da Sprint Planning
Pareamentos
Feedback
- Nessa sprint foi identificado que houve falha no planejamento. Até então nossos rituais - sprint review, sprint retrospective e sprint planning - aconteciam um em sequência do outro toda terça-feira. Isso acarretou que o planning era elaborado sem o Scrum Master ter analisado com calma as métricas e os resultados do final da sprint. Dessa forma, a issues de
Confeccionar Protótipo, que deveria ter sido quebrada em issues menores depois de ter ficado como débito da sprint 3, passou para a sprint 4 ainda como uma única história. O que implicou novamente em uma issue grande que não foi entregue dentro do tempo da sprint apesar da equipe ter avançado bastante no seu desenvolvimento. O problema só foi identificado quando o Scrum Master estava transpondo os dados da sprint para a documentação do projeto. Mediante essa situação, a equipe optou por dividir os rituais em dois dias. Na terça-feira será o fechamento da sprint realizando os rituais de review e retrospective, e na Quarta-feira será realizado o planning, com o Scrum Master já tendo avaliado todos os fatores referentes ao fechamento da sprint passada. - Também foi notável nessa sprint a dificuldade da equipe com a elaboração de testes, portanto deve-se na próxima sprint promover treinamento, pareamentos com EPS ou dojos que visem sanar o quanto antes esse obstáculo.
- Outro problema identificado pelo Scrum Master refere-se aos stand-ups. Até então os stand-ups estavam sendo realizados de terça a sexta-feira, que são os dias que a equipe tem maior disponibilidade presencial. Contudo, durante o final de semana e a segunda-feira - que é o período que a equipe mais produz - não há a realização de stand-ups, e o time de desenvolvimento somente mandava as dúvidas pelo Telegram caso precisassem. Isso acarretou que a dificuldade com testes que a equipe estava somente foi identificada no último dia da sprint, que era quando ocorria stand-up de novo. Dessa forma não foi mais possível corrigir o problema antes que a sprint acabasse.
- Além da questão do stand-up não estar sendo realizado todos os dias, ainda há a ocorrência de ausência de membros durante o stand-up. O que implica no desalinhamento da equipe sobre as atividades em andamento.
- O time de desenvolvimento tem relatado que os pareamentos tem sido bastante produtivos.
Burndown
- Esta sprint trouxe de débito da sprint passada a issue de confeção do protótipo. No planning desta sprint não foi identificado que essa issue deveria ser quebrada, e o resultado foi que essa issue atrapalhou o burndown novamente. Por ser uma issue grande - de 8 pontos - mais uma vez ela não foi entregue.
- Dos outros 6 pontos que ficaram de débito nessa sprint, ambos são referente a implementação de user stories. E a falta de entrega desses pontos refere-se a dificuldade da equipe em fazer os testes. Assim, as funcionalidades foram implementadas, mas os pull requests não foram aprovados pela falta de testes.
- A entrega contínua apresentada no burndown refere-se a atividades de gerência e documentação do projeto.
Velocity
- Nessa sprint, EPS conseguiu sanar todos os pontos que estavam de dívida da sprint anterior. Contudo, como já explicado na análide no Burndown, O time de desenvolvimento teve dificuldade para entregas as histórias testadas e o protótipo finalizado. O que implicou diretamente na queda do velocity.
Commits por Dia
- Como percebe-se no gráfico, essa sprint houve uma queda na produtividade da equipe. Atribuisse isso ao fato da equipe como um todo estar sobrecarregada com provas de outras disciplinas.
- Outro motivo que também atrapalhou a produtividade da equipe foi a dificuldade na realização dos testes. O time de desenvolvimento conseguiu implementar com certa facilidade as funcionalidades, contudo, ficou travado para confeccionar os testes depois.
Quadro de Conhecimentos
Acompanhe mais dessa métrcia aqui.
Gráfico de Conhecimentos
Acompanhe mais dessa métrcia aqui.
- A equipe melhorou principalmente em testes devido ao treinamento aplicado nesta sprint, contudo, o conhecimento em testes ainda se mostrou um obstáculo para a equipe.
Número de Pareamentos
- Nesta sprint o pareamento, os membros de EPS não conseguiram parear como havia sido planejado devido a falta de organização da dupla e dificuldade para encontrar horários compatíveis.
Cobertura de Testes
Veja o relatório completo sobre a cobertura de testes do final desta sprint aqui.
- A cobertura subiu nessa sprint, pois o treinamento de testes usou o próprio código que havia sido elaborado pelo time de desenvolvimento na Sprint 3 para busca de locais como exemplo. Assim, ao final do treinamento, o código testado foi submetido para a
develcom o objetivo de ser usado como exemplo para os testes futuros.
Folha de Estilo
- As issues da sprint passada, apresentadas no CodeClimate, referente a aplicação da folha de estilo nos arquivos auto-gerados pelo Rails, ainda não foram solucionadas nessa sprint.
