Resultados Sprint 12
Sprint com a segunda maior pontuação planejada da equipe, dado que o projeto está em sua fase final, foi necessário aumentar a carga de issues planejadas para a conclusão e correção das principais features da aplicação.
Fechamento da Sprint
| Issue | Status | Pontos |
|---|---|---|
| Criar Script de Popular Banco | Concluída | 1 |
| US25 - Apagar Relatório | Concluída | 2 |
| Atualizar Guia do Deploy | Concluída | 3 |
| Criar o EVM | Concluída | 8 |
| Corrigir os Fluxos da Aplicação | Concluída | 13 |
| US38 - Editar Nota | Não Concluída | 3 |
| US22 - Gerar Relatório por Categoria | Não Concluída | 5 |
| Automatizar Sistema de Troca de Ambientes | Não Concluída | 5 |
| US27 - Gerar Gráfico de Gastos Totais | Não Concluída | 8 |
| Criar Sistema de Migrations | Não Concluída | 8 |
| US36 - Associar Notas à Empresa | Não Concluída | 13 |
| Aumentar a Cobertura de Testes no Front-End | Não Concluída | 13 |
| Realizar Testes de Usabilidade | Não Concluída | 13 |
Pontos Planejados Concluídos: 6
Pontos de Dívida Concluídos: 21
Pontos Não Agregados: 68
Burndown
As issues foram iniciadas logo no começo da sprint. Esperava-se entrega de todas as issues planejadas, que, de fato, foram concluídas e respeitam os critérios de aceitação. Entretanto, com a aplicação crescendo cada vez mais, é necessário ajustar todas as rotas, tanto em homologação quanto em produção, e a equipe não conseguiu fazer os devidos ajustes em tempo hábil, logo, as issues se tornaram dívidas.
Velocity
Riscos
Não foram identificados riscos novos no decorrer da sprint.
Retrospectiva
A retrospectiva refletiu o problema da sprint: as dificuldades com a integração das histórias de usuário na aplicação, além do cansaço no final do projeto.
Quadro de Conhecimento
Registros de Presença nas Dailies
- Dailies de segunda e sexta feira são realizadas por hangouts, às 21h30 e 20h, respectivamente.
- Dailies de quarta-feira são realizadas por telegram, às 12h.
- Dailies de terça e quinta feira são realizadas presencialmente, às 15h50. (Com a ocorrência do feriado na quinta-feira, a daily foi realizada por hangouts às 21h30.)
| Nome | Segunda Feira | Terça Feira | Quarta Feira | Quinta Feira | Sexta Feira |
|---|---|---|---|---|---|
| Bernardo | ✘ | ✔ | ✘ | ✘ | ✔ |
| Clarissa | ✔ | ✔ | ✘ | ✔ | ✔ |
| Esio | ✔ | ✔ | ✔ | ✘ | ✔ |
| Felipe | ✔ | ✔ | ✔ | ✔ | ✔ |
| Lucas | ✔ | ✔ | ✔ | ✔ | ✔ |
| Mariana | ✔ | ✔ | ✔ | ✔ | ✘ |
| Pedro | ✔ | ✔ | ✔ | ✔ | ✔ |
| Saleh | ✔ | ✔ | ✔ | ✔ | ✔ |
| Youssef | ✔ | ✔ | ✔ | ✔ | ✔ |
Avaliação do Scrum Master
Sprint com níveis altíssimos de dívida e também com alta pontuação planejada visando entrega de qualidade ao final do projeto.
A equipe assumiu altos riscos planejando uma sprint com pontuação mais alta que o usual no fim do projeto. Isso ocorre porque o fluxo da aplicação ainda não era satisfatório para os usuários, e também porque ainda era esperado uma das features chave do projeto: a geração de gráficos de gastos.
O nível de dívidas foi alto porque a equipe se deparou com problemas no momento de juntar as histórias de usuário, já que existem dois ambientes com rotas diferentes, e a troca manual de todas as rotas do sistema para testes é trabalhosa, o que impediu a revisão em tempo hábil dentro da sprint corrente.
A qualidade de código no front-end ainda poderia ser melhorada, e para tanto, receberia mais uma issue para que a equipe de desenvolvimento pudesse polir o código reduzindo complexidade, duplicidade, e riscos de bugs, além de aumentar a cobertura de testes.
O produto final finalmente possui forma, resultado do empenho das equipes de EPS e MDS que, mesmo no final do semestre, ainda mantêm bom ritmo de entrega, e níveis ótimos de adesão às práticas ágeis.