FastInBox | Sprint governance
Sprint 2 Planning
Periodo planejado: Sprint 2 | Status: Planejada com backlog estruturado
Documento de planejamento voltado para execucao: define objetivo central, entregaveis, tarefas detalhadas, responsaveis sugeridos, evidencias esperadas e criterio de pronto para acompanhamento no GitHub Project.
1. Contexto da sprint
A Sprint 2 parte de um MVP funcional entregue na Sprint 1. O foco agora deixa de ser apenas comprovar navegacao e passa a consolidar confiabilidade: persistencia real, rastreabilidade operacional, validacao automatizada e maior maturidade de apresentacao para banca e stakeholders.
2. Objetivo central
Transformar o fluxo demonstravel da Sprint 1 em uma base mais consistente para continuidade do projeto, conectando front, back e documentacao a um backlog rastreavel e com evidencias claras de execucao.
- Consolidar dados criticos fora da camada puramente local.
- Reduzir risco de regressao nas jornadas principais.
- Melhorar feedbacks de uso e leitura do status do pedido.
- Estruturar a sprint com tarefas, owners e criterios de aceite visiveis no Project da organizacao.
3. Entregaveis prioritarios
| Entregavel | Descricao | Resultado esperado |
|---|---|---|
| Persistencia server-side | Integracao progressiva de autenticacao, pacientes e pedidos com API e banco | Fluxos deixam de depender exclusivamente de estado local |
| Kanban sincronizado | Atualizacao de status com origem em dados reais e nao apenas na interface | Fabrica opera com fila mais confiavel |
| Observabilidade minima | Registro de eventos de pagamento e mudanca de status | Equipe passa a medir o fluxo critico |
| Smoke tests E2E | Automacao minima para validar a jornada principal | Menor risco de quebrar o MVP em ajustes rapidos |
| Governanca da sprint | Issues, backlog e evidencias centralizados no GitHub Project | Maior transparencia para equipe e avaliadores |
4. Backlog detalhado da Sprint 2
| Item | Tarefa acionavel | Owner sugerido | Dependencia | Criterio de aceite |
|---|---|---|---|---|
| Autenticacao integrada | Conectar login e sessao do front a endpoints reais do backend | Front + Back | Contrato de autenticacao definido | Usuario autentica sem depender apenas de fixtures locais |
| Persistencia de pacientes | Salvar e listar pacientes por nutricionista com origem no servidor | Back | Modelo de paciente e rotas CRUD | Paciente criado reaparece apos recarga e segue vinculado ao owner correto |
| Persistencia de pedidos | Salvar pedido, itens e fabrica responsavel em banco relacional | Back + Front | Entidades e payloads alinhados | Pedido pode ser recuperado por nutricionista, paciente e fabrica |
| Kanban operacional sincronizado | Atualizar colunas e status com base em dados do servidor | Front | API de leitura e mudanca de status | Mudanca de coluna persiste apos refresh e fica visivel aos perfis corretos |
| Eventos criticos | Registrar pagamento, confirmacao e mudanca de etapa operacional | Fullstack | Definicao dos eventos minimos | Historico dos eventos principais fica rastreavel |
| Smoke tests | Automatizar o caminho criar pedido -> pagar -> acompanhar status | QA + Fullstack | Ambiente minimamente previsivel | Teste executa com sucesso no baseline da sprint |
| Feedbacks de interface | Reforcar mensagens de sucesso, erro e andamento para o paciente | Front | Mapeamento dos estados criticos | Usuario entende claramente o que aconteceu e qual o proximo passo |
| Evidencias e documentacao | Atualizar docs, review e backlog publico com o progresso da sprint | Docs | Executar os itens anteriores | Artefatos publicados e coerentes com a execucao real |
5. Estrutura de acompanhamento
5.1 To Do
- Itens que ja possuem descricao, owner sugerido e criterio de aceite definido.
- Bloqueadores ainda nao resolvidos devem estar explicitos na issue.
5.2 Doing
- Item em execucao deve apontar o que esta sendo desenvolvido e o que falta validar.
- Evidencias parciais podem ser anexadas ao longo da implementacao.
5.3 Done
- So entra em concluido o item que entregar o criterio de aceite e registrar evidencia.
- A conclusao deve refletir o estado real publicado no repositorio e, quando aplicavel, em ambiente publico.
6. Definition of Done da sprint
- Codigo versionado e sincronizado no repositorio correto.
- Sem regressao aparente na jornada principal do FastInBox.
- Evidencia minima registrada: print, deploy, video curto ou descricao objetiva de validacao.
- Issue atualizada no GitHub Project com status coerente.
- Documento publico refletindo o estado real da entrega.
7. Evidencias esperadas
| Entrega | Evidencia minima | Finalidade academica |
|---|---|---|
| Persistencia integrada | Print ou video mostrando dados mantidos apos nova sessao | Comprovar evolucao tecnica real |
| Kanban sincronizado | Registro da mudanca de status refletida em mais de uma tela | Demonstrar consistencia operacional |
| Smoke tests | Execucao com sucesso e saida resumida do teste | Comprovar preocupacao com qualidade |
| Documentacao da sprint | Pages atualizado com backlog e review correspondente | Facilitar banca e continuidade do projeto |
8. Riscos e plano de contingencia
| Risco | Possivel impacto | Contingencia |
|---|---|---|
| Atraso na integracao entre front e back | Postergar persistencia real | Fechar primeiro contrato minimo e validar por partes, sem travar toda a sprint. |
| Dados inconsistentes entre telas | Comprometer a demonstracao do fluxo | Priorizar pedidos e status como fonte unica de verdade antes de ampliar escopo. |
| Falta de evidencias ao final da sprint | Enfraquecer apresentacao academica | Registrar entregas semanalmente e nao apenas no encerramento. |
| Regressao por ajustes rapidos de interface | Quebrar jornadas ja aprovadas | Executar smoke test e checklist manual minimo antes de publicar. |
9. Ritmo de acompanhamento
- Atualizacao diaria do Project para refletir o estado real das issues.
- Revisao de bloqueios no meio da sprint, evitando acumulacao no fechamento.
- Consolidacao continua de evidencias para facilitar a Sprint Review seguinte.
- Uso do backlog publico como referencia unica para o que esta planejado, em andamento e concluido.
10. Resultado esperado ao fim da Sprint 2
Ao final desta sprint, o FastInBox deve manter a clareza visual e a demonstrabilidade conquistadas na Sprint 1, mas com mais confiabilidade tecnica, melhor rastreabilidade e menor dependencia de fluxos puramente simulados.
Este documento deve ser lido em conjunto com a review da Sprint 1 e com o backlog publicado em issues no GitHub Project da organizacao.