Fechamento da Sprint 11
1. Resumo da Sprint
Pontos Planejados: 23 pontos
Pontos concluídos: 23 pontos
Dívidas técnicas: 0 pontos
Histórias entregues:
- TS98 - Refatorar o frontend em busca de uma usabilidade melhor
- US99 - Fila de espera
- US100 - Gerar PDF do prontuário
- TS101 - Documentação da sprint 10
- TS102 - Integração contínua do micro serviço
2. Retrospectiva da Sprint
| Pontos Positivos | Pontos Negativos | Sugestão de Melhoria |
|---|---|---|
| solução alternativa para a história | muitos commits feitos mais ao fim da sprint | componentes costumam dar problemas e gerar atrasos na histórias |
| aprendizados de membros da equipe | componente utilizado em uma das histórias apresentou problemas | voltar o ritmo da equipe para como estava antes |
| ganho de experiência de membros da equipe com front-end | doença de um dos membros | evitar ao máximo faltar a eventos presenciais da equipe |
| pontualidade de todos na reunião de sábado | perda de ritmo nas sprints | - |
| boa distribuição da carga de trabalho ao longo da sprint | front-end precisar ser mudado com frequência | - |
| finalização do microsserviço | atraso na resposta das dailys não presenciais | - |
| o nosso grupo está trabalhando bem | centralização em alguns membros do review das histórias | - |
| o devops estável facilitou a implementação do microsserviço | greve atrapalhando o andamento das atividades do grupo | - |
3. Quadro de Conhecimento
5. Gráfico do Burndown
6. Velocity
7. Gráfico de Commits
8. EVM
9. Análise do Scrum Master
No geral, a sprint ocorreu bem, sem que tenhamos tidos dívidas técnicas, com os membros ainda aprendendo com as histórias e pareamentos e com o DevOps bem implementado colaborando positivamente para o sucesso do nosso microsserviço.
Quanto à questão do atraso na resposta das dailys não presenciais, da perda de ritmo nas sprints e da centralização dos reviews em alguns membros do grupo, conversamos sobre isso e levantamos que é preciso ter mais compromisso e tomarmos cuidado para que o nosso bom trabalho enquanto grupo não se perca nessa fase final. Por isso, procuraremos tomar mais cuidado com esses pontos levantados para que eles não se repitam ou sejam ao menos reduzidos.
Sobre os componentes que apresentaram problemas, vimos que costumam ser os que mexem com front-end. Por isso, decidimos que não iremos mais utilizá-los sempre que possível, usando apenas aqueles que trabalhem com o back-end.
Por fim, conversamos que a questão do front-end constantemente alterado é natural dele, pois ele é um ponto que costuma receber bastante atenção e feedback sobre. Por isso, é esperado que de tempos em tempos ele acabe sofrendo alterações.