FastInBox | Sprint governance
Sprint 1 Review
Periodo analisado: Sprint 1 | Status: Encerrada com aceite funcional para apresentacao academica
Documento de review consolidando o que foi construido, as evidencias apresentadas, os bloqueios enfrentados, os pontos fortes mantidos e os ajustes que viram backlog formal da Sprint 2.
1. Objetivo da revisao
A Sprint 1 teve como foco transformar o conceito do FastInBox em um MVP navegavel, com jornadas demonstraveis para nutricionista, paciente e fabrica. Esta review valida se a equipe entregou valor visivel, registrou evidencias concretas e deixou a proxima sprint preparada com backlog claro e rastreavel.
2. Escopo comprometido
- Autenticacao e cadastro por perfil: nutricionista, paciente e fabrica.
- Criacao de pedido vinculado a paciente com codigo unico.
- Fluxo de pagamento simplificado e mudanca de status transacional.
- Painel da fabrica em formato kanban com drag-and-drop.
- Dashboards por perfil e acompanhamento em cards.
3. Entregaveis efetivamente concluidos
| Entregavel | Resultado | Valor entregue |
|---|---|---|
| Login e cadastro por perfil | Concluido | Permite demonstrar perfis distintos e jornadas separadas dentro do MVP. |
| Fluxo do nutricionista | Concluido | Cadastro de paciente e criacao de pedido com visao de acompanhamento. |
| Fluxo do paciente | Concluido | Painel de acompanhamento, pagamento e consulta de status do pedido. |
| Fluxo da fabrica | Concluido | Kanban operacional para movimentar pedidos ao longo da producao. |
| Biblioteca de documentos | Concluido | Base publica de artefatos para banca, professores e continuidade da equipe. |
| Aplicacao publicada | Concluido | Demonstra o produto em ambiente externo, sem depender apenas de execucao local. |
4. Evidencias consolidadas da Sprint 1
| Tipo de evidencia | O que comprova | Status |
|---|---|---|
| Prints e navegacao do front | Existencia das telas principais e coerencia entre os perfis do sistema | Disponivel |
| Deploy publico na Vercel | Acessibilidade do MVP para apresentacao externa | Disponivel |
| GitHub Pages com documentos | Governanca do projeto, registro formal e apoio para avaliacao academica | Disponivel |
| Commits por repositorio | Rastreabilidade de quem mudou o que e em qual camada | Disponivel |
| Fluxo E2E demonstravel | Prova de que o pedido percorre criacao, pagamento e producao | Disponivel |
A review da Sprint 1 foi estruturada para ser objetiva: o foco nao e apenas afirmar que algo foi feito, mas mostrar evidencias de que a entrega pode ser demonstrada e auditada.
5. Validacao de qualidade
5.1 Indicadores de conformidade
- Build front e back executados com sucesso no baseline de entrega.
- Repositorios sincronizados em main sem conflitos abertos.
- Deploy Vercel e GitHub Pages respondendo HTTP 200.
- Fluxo E2E validado em ambiente de apresentacao.
5.2 Evidencia de rastreabilidade
Os commits da sprint foram organizados por repositorio e por escopo funcional, permitindo ligar entregaveis do front, back e docs a evidencias concretas. Isso reduz ambiguidade na avaliacao e facilita a montagem do historico do projeto.
6. Dificuldades enfrentadas e como a equipe respondeu
| Dificuldade | Impacto na sprint | Resposta adotada |
|---|---|---|
| Persistencia ainda apoiada em estado local | Limitou a confianca para cenarios multiusuario | Equipe priorizou a demonstracao funcional e carregou a migracao para a Sprint 2. |
| Necessidade de alinhar layout, demo e documentacao ao mesmo tempo | Aumentou o esforco de consolidacao perto do fechamento | Foi criada uma base publica de docs para centralizar a narrativa tecnica. |
| Validacao majoritariamente manual | Maior risco de regressao em ajustes finais | Foi mantido foco na jornada principal e aberta acao de automacao para a proxima sprint. |
| Dependencia de ajustes finos na apresentacao publica | Poderia comprometer a clareza perante banca e stakeholders | Layout e copy foram refinados para reduzir ruido tecnico na versao demonstravel. |
7. Pontos fortes mantidos pela equipe
- Entrega orientada por fluxo principal, sem dispersar em features perifericas.
- Capacidade de publicar artefatos reais, e nao apenas mockups ou promessas de implementacao.
- Separacao dos repositorios por responsabilidade, facilitando manutencao e auditoria.
- Documentacao paralela ao desenvolvimento, reduzindo retrabalho no fechamento da sprint.
8. Melhorias identificadas para a proxima iteracao
| Melhoria | Motivo | Prioridade |
|---|---|---|
| Migrar dados sensiveis para API e banco | Diminuir dependencia de estado local e aumentar confiabilidade | Alta |
| Automatizar smoke tests da jornada critica | Reduzir risco de regressao a cada ajuste de interface | Alta |
| Instrumentar eventos de pagamento e status | Dar visibilidade operacional e gerar base para indicadores | Media |
| Reforcar feedbacks de interface ao paciente | Melhorar compreensao de cada etapa do pedido | Media |
9. Impedimentos e plano de contingencia
| Impedimento | Severidade | Plano de contingencia |
|---|---|---|
| Persistencia local nao colaborativa | Media | Priorizar integracao com API na Sprint 2 e manter fluxo demo estavel ate a migracao. |
| Ausencia de telemetria funcional | Media | Adicionar eventos criticos de jornada antes de ampliar escopo funcional. |
| Cobertura de testes automatizados insuficiente | Alta | Definir smoke test minimo como criterio de pronto para itens da Sprint 2. |
| Dependencia de ajustes manuais perto das apresentacoes | Baixa | Centralizar backlog, docs e evidencias em um fluxo unico de acompanhamento. |
10. Decisoes aprovadas ao encerrar a Sprint 1
- Priorizar estabilidade operacional durante a fase academica inicial.
- Preservar backend no repositorio para evolucao planejada e reuso de modelagem.
- Priorizar evidencias visiveis de fluxo de negocio sobre features perifericas.
- Concentrar documentacao formal no GitHub Pages para facilitar avaliacao da banca.
11. Desvios observados vs planejamento
| Item | Planejado | Realizado | Impacto |
|---|---|---|---|
| Persistencia transacional | Migracao parcial para API | Mantida em baseline local da sprint | Postergacao controlada para Sprint 2 |
| Telemetria de produto | Eventos minimos de jornada | Escopo reduzido para priorizar fluxo principal | Necessidade de instrumentacao imediata na proxima fase |
| Cobertura de teste automatizado | Baseline de regressao inicial | Validacao majoritariamente manual | Aumento de risco de regressao cumulativa |
12. Feedback sintetico dos stakeholders
| Stakeholder | Percepcao predominante | Implicacao para a proxima sprint |
|---|---|---|
| Nutricionista | Fluxo de criacao esta claro, mas depende de persistencia real para ganhar confianca total | Priorizar API e estabilidade de sessao |
| Paciente | Jornada e compreensivel quando o pedido chega estruturado | Refinar feedback de pagamento e status |
| Cozinha | Fila qualificada melhora a operacao, mas precisa historico mais robusto | Persistir eventos de producao |
| Gestao | Visao geral existe, porem relatorios ainda estao em baseline inicial | Evoluir camada de indicadores |
13. Licoes aprendidas
- Fechamento antecipado de escopo melhora previsibilidade da entrega final.
- Evidencias publicas de deploy e docs reduzem risco na avaliacao academica.
- A centralizacao de estado acelera MVP, mas exige plano claro de migracao.
- Padrao visual unificado reduz custo de manutencao entre jornadas.
- Documentacao atualizada em paralelo evita retrabalho de consolidacao tardia.
14. Plano recomendado para Sprint 2
- Integrar API real para autenticar e persistir pedidos em banco relacional.
- Criar camada de auditoria para eventos sensiveis, como pagamento e mudancas de status.
- Introduzir testes automatizados de smoke e regressao nos fluxos por perfil.
- Melhorar feedbacks visuais e mensagens em pontos criticos da jornada do paciente.
- Publicar backlog da sprint no GitHub Project com rastreabilidade por issue.
Conclusao da review: a Sprint 1 foi aprovada como MVP funcional, com valor demonstravel e backlog tecnico bem definido para a fase seguinte.
15. Plano de acao imediato
| Acao | Owner sugerido | Prioridade | Objetivo |
|---|---|---|---|
| Definir contratos da API de pedidos | Engenharia back | Alta | Eliminar ambiguidade de integracao com front |
| Instrumentar eventos de pagamento e status | Engenharia fullstack | Alta | Dar visibilidade de funil e gargalos |
| Automatizar smoke test de jornada critica | QA/Engenharia | Media | Reduzir regressao em releases frequentes |
| Atualizar artefatos de conformidade | Documentacao tecnica | Media | Manter rastreabilidade de decisao |
16. Snapshot de metricas e evidencias
| Dimensao | Status da sprint | Evidencia |
|---|---|---|
| Fluxo E2E | Disponivel para demonstracao | Aplicacao publicada e jornada navegavel |
| Repositorios | Sincronizados em main | Commits semanticos e artefatos por repo |
| Docs | Biblioteca publica ativa | GitHub Pages com documentos navegaveis |
| Build baseline | Compilacao viavel | Front e back com scripts de build definidos |
17. Backlog remanescente e carry-over
- Migracao de persistencia local para camada server-side.
- Automacao de testes de smoke e regressao por jornada.
- Auditoria persistente de pagamento e mudancas operacionais.
- Relatorios administrativos com leitura financeira e de SLA.