Backlog da Sprint
| ID | História | Status | Pontos |
|---|---|---|---|
| ISSUE | #124 Configurar informações do bot no Rocketchat | Fechado | 1 |
| ISSUE | #125 Elaborar documento de levantamento de métricas | Fechado | 3 |
| ISSUE | #127 Definir testes de acordo com a arquitetura | Fechado | 5 |
| ISSUE | #128 Elaborar NFR | Fechado | 3 |
| ISSUE | #129 Adicionar tópico com exemplos de utilização de estruturas de repetição | Fechado | 2 |
| ISSUE | #130 Adicionar tópico com linkagem estática para conteúdo extra sobre estruturas de repetição | Fechado | 1 |
| ISSUE | #131 Adicionar tópico com linkagem estática para sugestão de exercício sobre uso de estruturas de repetição | Fechado | 1 |
| ISSUE | #132 Adicionar tópico de Fallback | Fechado | 1 |
| ISSUE | #133 Documentar Sprint 3 | Fechado | 2 |
| ISSUE | #135 Atualizar README | Fechado | 1 |
| ISSUE | #136 Integrar a Aix ao Telegram | Fechado | 8 |
Pontuação Final
- Pontuação Total: 33 Pontos Planejados
- Débitos Técnicos Adicionados: 0 Pontos
- Pontos Concluídos: 33 Pontos Concluídos
Débitos Técnicos de Sprints Anteriores
- Não houveram débitos técnicos para pagar nesta sprint
Débitos Técnicos Gerados
Retrospectiva
Pontos Positivos
- Conseguiram integrar com telegram
- Aprendeu bastante de Flask
- O bot do telegram responde
- Actions vai parar de dar ruim
- O bot dá feedback da busca
- NFR foi feito rápido
- MDS conseguiu fechar as issues e conseguiu ver um erro que o arquiteto falou pra fazer
- Conseguiu integrar com Telegram
- Arrumamos muitos bugs
- A galera se esforçou bastante na issue da API
- Revisão do docker pelo Yoshida
- A execução das issues do telegram e do stackoverflow
- Meu MDS é top
- A gente recebeu review de muita gente, então vamos conseguir arrumar bastante coisa na sprint
- Boa documentação e site
Pontos Negativos
- Não vai mais usar Flask, rasa atrapalhou essa parte
- Falta de autonomia no bot
- Passou muito tempo tentando integrar Telegram com Flask, e não usou
- Docker tem que mudar toda hora
- Boilerplate atrapalhou bastante
- NFR tem muito artigo (?)
- Arquiteto só começou a trabalhar na sexta
- O Guilherme só passa coisa errada pra gente fazer
- O pareamento não funcionou bem (alguns miguelaram)
- Rasa com Flask não deu certo
- O docker ferrou com a Gabi
- Iuri passou muito tempo pra rodar a parte de custom actions
- Gabi não fechou as issues por ficar travada com o Docker
- Aplicação dos slots
Melhorias
- Ter o nosso docker, e não o do boilerplate (em progresso)
- Saúde do Andrezingameplays69
- Arquiteto se programar melhor para as outras materias
- Parear de forma mais eficiente
Burndown
Velocity
Quadro de Conhecimento
Riscos
| Risco | Ação Preventiva | Ação Reativa |
|---|---|---|
| Problemas de saúde em integrante da equipe | Issues pequenas e executáveis dentro do tempo da sprint, o que permite replanejamento de horas | Planejamento de pareamento por sprint |
| Maior dificuldade para a equipe de desenvolvimento | Indicação de material de apoio para facilitar o desenvolvimento das atividades | Pareamento em grupo para resolução de grandes empecilhos |
| Arquiteto e DevOps com provas na semana | Sprint mais leve para esses papéis | Substituição desses papéis pelo Scrum Master e P.O |
Burndown de Riscos
Resumo pelo Scrum Master
A sprint foi crucial para o projeto, com integração com Telegram e busca na API do stackOverflow. Que são issues de extrema importância para demonstrar a viabilidade do projeto. A busca na API do stackOverflow não foi concluída, apesar de ter chegado próxima a isso.
Em resumo, a sprint foi falha em entregar todos os pontos planejadas, e as dívidas serão mapeadas e replanejadas para a próxima Sprint.