Roteiro de Apresentação – Release 1

Duração total: 5 minutos
Objetivo: Mostrar como a equipe enfrentou o desafio proposto e entregou implementação inicial, comprovando a viabilidade do escopo, arquitetura e tecnologias em 2 meses.

1. Abertura (30 segundos)

  • Quem fala: 1 pessoa
  • Apresentar a equipe.
  • Explicar objetivo da Release 1:

    “Nesta Release, nosso foco foi validar se o escopo, a arquitetura e as tecnologias escolhidas eram viáveis, começando pela implementação inicial.”

2. Desafio Proposto (40 segundos)

  • Quem fala: 1 pessoa
  • Explicar o desafio do time no início:
    • Explorar o problema e entender os temas.
    • Definir escopo de forma clara e aprová-lo.
    • Estruturar a arquitetura para sustentar a solução.
    • Escolher e validar tecnologias que realmente funcionem.
  • Concluir:

    “Nosso desafio foi transformar essas incertezas em entregas concretas.”

3. Implementação Realizada (2 minutos)

  • Quem fala: 2 pessoas (cada uma cobre um ponto).
  • Mostrar o que foi de fato implementado:
    • Protótipo inicial aprovado (escopo validado).
    • Documento de arquitetura + primeiras decisões.
    • Tecnologias testadas com código funcional.
    • Implementação inicial (ex.: endpoints, banco, integração, pipeline, ou outra parte já rodando).
  • Exibir prints, trechos de código ou tela do protótipo.

4. Evidências de Viabilidade (1 minuto)

  • Quem fala: 1 pessoa
  • Relacionar implementação com o desafio:
    • Story Map + issues concluídas mostram processo funcionando.
    • Documentação OSS publicada e Release Notes registram a entrega.
    • Protótipo rodando comprova que a arquitetura e tecnologias escolhidas são viáveis.

5. Encerramento (30 segundos)

  • Quem fala: mesma pessoa da abertura
  • Conclusão:

    “Com a Release 1, transformamos o desafio inicial em entregas concretas. Agora seguimos para evoluir a solução e consolidar a Release 2.”

  • Agradecer.

Checklist de Apresentação – Release 1 (5 minutos)

1. Abertura (30s)

  • Apresentar a equipe (nome do time + integrantes).
  • Explicar objetivo da release: validar escopo, arquitetura e tecnologias.

2. Desafio Proposto (40s)

  • Mostrar o desafio inicial:
    • Explorar o problema.
    • Definir e aprovar escopo.
    • Estruturar arquitetura.
    • Escolher e validar tecnologias.
  • Frase de transição: “O desafio era transformar incertezas em entregas concretas.”

3. Implementação Realizada (2min)

  • Protótipo inicial aprovado.
  • Documento de arquitetura criado.
  • Tecnologias testadas com código funcional.
  • Implementação inicial (ex.: endpoints, banco, pipeline etc).
  • Mostrar prints / repositório / protótipo.

4. Evidências de Viabilidade (1min)

  • Story Map + issues entregues.
  • Documentação OSS publicada.
  • Release Notes registrados.
  • Protótipo funcionando = viabilidade comprovada.

5. Encerramento (30s)

  • Concluir: “Transformamos o desafio inicial em entregas concretas.”
  • Próximos passos: evoluir funcionalidades e preparar Release 2.
  • Agradecer.

Dicas Rápidas

  • Falem do desafio inicial como motivação.
  • Mostrem a implementação feita (mesmo se pequena).
  • Usem prints ou exemplos reais do repositório.
  • Dividam o tempo para caber nos 5 minutos.
  • Cada pessoa fala uma parte → mostra colaboração.
  • Usar prints e exemplos reais.
  • Ser objetivo, sem ler os slides.
  • Treinar para não passar de 5 minutos.

Roteiro de Apresentação – Release 2

ROTEIRO DE APRESENTAÇÃO (7 MINUTOS)

Tempo total: 7 minutos Abertura “Boa tarde, somos o grupo X e vamos apresentar o resultado final do nosso projeto.Vamos mostrar nossa solução, o que foi entregue, aprendizados e impactos.”

Contexto e Problema

  • Qual problema o projeto resolve
  • Para quem
  • Por que é relevante “O problema identificado foi […]. Nosso objetivo foi desenvolver uma solução que […] para atender […].”

A Solução Desenvolvida

  • Demonstração conceitual do produto
  • Arquitetura geral (alto nível)
  • Principais funcionalidades Fala exemplo: “Construímos uma aplicação composta por […]As principais features entregues foram: […].” ( 10–15 segundos de demonstração.)

Qualidade, Testes e DevOps

  • Pipeline CI/CD
  • Linter e análise estática
  • Testes unitários e de integração
  • Qualidade das PRs Fala exemplo: “Implementamos práticas de XP e DevOps, incluindo pipeline de integração contínua, linter automático e testes com cobertura de X%. Isso garantiu maior estabilidade e rapidez nas entregas.”

Gestão, Agile e Produção

  • Sprints, retros, planning
  • Quantidade de issues, ritmo e rastreabilidade
  • GitPage e release notes “Seguimos práticas ágeis com sprints semanais, retrospectivas e planning. Mantivemos rastreabilidade de épicos → features → US → issues, além de documentação no GitPage.”

Lições Aprendidas

  • Técnicas
  • Trabalho em equipe
  • Processos
  • Ferramentas Fala exemplo: “Entre as principais lições aprendidas estão: melhor divisão de tarefas, commits mais atômicos, uso eficiente de pipelines e importância dos testes automatizados.”

Conclusão e Encerramento

  • Impacto final do projeto
  • O que foi alcançado
  • Possíveis evoluções futuras “O projeto cumpriu o escopo planejado e entregamos um produto funcional que […]. Como próximos passos, recomendamos […]. Obrigada!”

Checklist

  1. Preparação do Conteúdo ✔ Problema e Contexto
    • Explica claramente o problema que o projeto resolve
    • Mostra para quem a solução foi desenvolvida
    • Justifica a relevância do projeto ✔ Solução Desenvolvida
    • Resumo da solução em 2–3 frases
    • Arquitetura geral apresentada (alto nível)
    • Principais funcionalidades destacadas
    • Demonstração rápida preparada (se houver) ✔ Implementação e Qualidade
    • Apresentar o pipeline de CI/CD
    • Mostrar uso de linter e análise estática
    • Destacar testes unitários (cobertura, exemplos)
    • Mostrar testes de integração
    • Evidenciar qualidade dos PRs e rastreabilidade ✔ Práticas Ágeis / XP
    • Commits atômicos exemplificados
    • Issues bem documentadas com critérios de aceitação
    • Sprints documentadas
    • Retros com melhorias reais entre sprints
    • Velocity estável ou justificativa para variação
    • Fluxo épico → feature → US → issue → PR mostrado ✔ GitPage / Release Notes
    • Página do produto atualizada
    • Explicação centrada no usuário
    • Release notes claras e organizadas ✔ Lições Aprendidas
    • Pelo menos 3 aprendizados técnicos
    • Pelo menos 2 aprendizados de equipe/processo
    • Algo que o time faria diferente numa próxima entrega ✔ Conclusão
    • O que foi alcançado
    • Impacto do projeto
    • Próximos passos sugeridos
  2. Preparação dos Slides
    • Slides limpos, pouco texto
    • Fonte legível
    • Títulos claros e numerados
    • Tempo de cada slide definido (média 35–45 segundos)
    • Prints ou GIFs do sistema funcionando
    • Diagramas simples (arquitetura, fluxo)
    • Cores consistentes
    • Nenhum slide cheio demais
  3. Preparação Técnica
    • Links de demo/teste funcionando
    • Repositórios públicos/visíveis
    • Página GitPage acessível
    • Pipeline CI funcionando (print de backup no slide)
    • Código está rodando localmente
    • Internet testada
    • Cabo HDMI/adaptador pronto (caso presencial)
  4. Preparação da Equipe
    • Quem fala cada parte definido
    • Falas ensaiadas
    • Tempo total cronometrado (6:45 a 7:00)
    • Backup: caso alguém falte, outro sabe falar a parte
    • Entradas entre falas suaves (“Agora passo para…”)
  5. Preparação Pessoal
    • Apresentação começa com uma frase forte (ex: “Nosso projeto resolve…”)
    • Linguagem clara, voz firme
    • Postura profissional
    • Slide de abertura ensaiado (sempre o mais importante)
    • Agradecimento final preparado
  6. Itens de Risco (Mitigação)
    • Se demo falhar → print/gif nos slides
    • Se internet cair → vídeo offline
    • Se faltar tempo → cortar detalhes técnicos e focar solução
    • Se alguém esquecer a fala → ter bullets visíveis nos slides

Release II

CHECKLIST PARA APRESENTAÇÃO FINAL (7 minutos)

✔ Problema e Contexto

  • Explica claramente o problema que o projeto resolve
  • Mostra para quem a solução foi desenvolvida
  • Justifica a relevância do projeto

✔ Solução Desenvolvida

  • Resumo da solução em 2–3 frases
  • Arquitetura geral apresentada (alto nível)
  • Principais funcionalidades destacadas
  • Demonstração rápida preparada (se houver)

✔ Implementação e Qualidade

  • Apresentar o pipeline de CI/CD
  • Mostrar uso de linter e análise estática
  • Destacar testes unitários (cobertura, exemplos)
  • Mostrar testes de integração
  • Evidenciar qualidade dos PRs e rastreabilidade

✔ Práticas Ágeis / XP

  • Commits atômicos exemplificados
  • Issues bem documentadas com critérios de aceitação
  • Sprints documentadas
  • Retros com melhorias reais entre sprints
  • Velocity estável ou justificativa para variação
  • Fluxo épico → feature → US → issue → PR mostrado

✔ GitPage / Release Notes

  • Página do produto atualizada
  • Explicação centrada no usuário
  • Release notes claras e organizadas

✔ Lições Aprendidas

  • Pelo menos 3 aprendizados técnicos
  • Pelo menos 2 aprendizados de equipe/processo
  • Algo que o time faria diferente numa próxima entrega

✔ Conclusão

  • O que foi alcançado
  • Impacto do projeto
  • Próximos passos sugeridos

2. Preparação dos Slides

  • Slides limpos, pouco texto
  • Fonte legível
  • Títulos claros e numerados
  • Tempo de cada slide definido (média 35–45 segundos)
  • Prints ou GIFs do sistema funcionando
  • Diagramas simples (arquitetura, fluxo)
  • Cores consistentes
  • Nenhum slide cheio demais

3. Preparação Técnica

  • Links de demo/teste funcionando
  • Repositórios públicos/visíveis
  • Página GitPage acessível
  • Pipeline CI funcionando (print de backup no slide)
  • Código está rodando localmente
  • Internet testada
  • Cabo HDMI/adaptador pronto (caso presencial)

4. Preparação da Equipe

  • Quem fala cada parte definido
  • Falas ensaiadas
  • Tempo total cronometrado (6:45 a 7:00)
  • Backup: caso alguém falte, outro sabe falar a parte
  • Entradas entre falas suaves (“Agora passo para…”)

5. Preparação Pessoal

  • Apresentação começa com uma frase forte (ex: “Nosso projeto resolve…”)
  • Linguagem clara, voz firme
  • Postura profissional
  • Slide de abertura ensaiado (sempre o mais importante)
  • Agradecimento final preparado

6. Itens de Risco (Mitigação)

  • Se demo falhar → print/gif nos slides
  • Se internet cair → vídeo offline
  • Se faltar tempo → cortar detalhes técnicos e focar solução
  • Se alguém esquecer a fala → ter bullets visíveis nos slides

Versão super rápida (cola final)

Antes de apresentar, confirme:

  • Problema explicado
  • Solução demonstrada
  • Arquitetura citada
  • CI/Linter/Testes mostrados
  • Práticas ágeis provadas
  • Lições aprendidas
  • Conclusão forte
  • Tudo dentro de 7 minutos

CHECKLIST DE DOCUMENTAÇÃO DO PROJETO

1. Documentação de Visão e Produto

  • README principal completo, contendo:

    • O que é o projeto
    • Problema que resolve / motivação
    • Público-alvo
    • Arquitetura geral (alto nível)
    • Tecnologias utilizadas
    • Como rodar o projeto (passo a passo)
    • Como contribuir
    • Licença

  • Visão de Produto (GitPage):

    • Explicação centrada no usuário
    • Prints ou GIFs da aplicação
    • Fluxo de navegação
    • Releases visíveis

2. Documentação de Arquitetura

  • Diagrama de arquitetura (alto nível)
  • Descrição dos componentes / módulos
  • Fluxo de dados (sequência ou dataflow)
  • Decisões Arquiteturais (ADRs)
  • Justificativa das tecnologias
  • Estrutura de pastas explicada
  • Dependências principais listadas

3. Documentação de Desenvolvimento

  • Guia de instalação
  • Guia de configuração do ambiente
  • Dependências e versões (ex: Node, Python, Docker etc.)
  • Scripts disponíveis (run, test, lint…)
  • Explicação do pipeline CI/CD
  • Documentação de integrações externas (APIs, serviços)

4. Documentação de Qualidade

  • Linter configurado (arquivo .eslintrc, .flake8 etc.)
  • Documentação das regras de estilo
  • Critérios de qualidade estática aplicados
  • Cobertura de testes relatada

  • Relatório dos testes:

    • Testes unitários
    • Testes de integração
    • Testes de aceitação (se houver)

5. Documentação de Projeto e Gestão Ágil

  • Story Map
  • Épicos → Features → User Stories (com critérios de aceitação)
  • Rastreabilidade entre histórias → issues → PRs

  • Documentação das sprints:

    • Planning
    • Review
    • Retrospectivas
    • Métricas analisadas pelo time
  • Velocity e curva de commits
  • Políticas de branch (Git Flow / trunk-based)
  • Checklist de PR (Pull Request Template)

6. Documentação DevOps

  • Arquivo de ambiente exemplo (.env.example)
  • Configuração de CI/CD documentada
  • Estratégia de deploy

7. Documentação de Release

  • Release Notes completas contendo:
    • Novas funcionalidades
    • Melhorias
    • Bugs corrigidos
    • Quebras de compatibilidade (breaking changes)
  • Histórico de versões (CHANGELOG.md)
  • Versão estável marcada como release
  • Link para demo ou deploy

9. Documentação de Contribuição

  • Guia do Contribuidor (CONTRIBUTING.md):
    • Como abrir issues
    • Como enviar PR
    • Padrões de commit (ex: Conventional Commits)
    • Estilo de código
  • Código de Conduta (CODE_OF_CONDUCT.md)
  • Templates:
    • Template de issue
    • Template de PR

10. Documentação Final para Entrega

  • Relatório Final do Projeto
  • Slides da apresentação
  • Repositórios organizados e acessíveis
  • GitPage publicado e atualizado
  • Links diretos para tudo
  • Versão final do produto ou protótipo

Checklist ultrarrápido de bolso (para revisar antes de entregar)

  • README completo
  • Arquitetura documentada
  • Manual de instalação
  • Pipeline CI/CD documentado
  • Testes + cobertura
  • Story map + rastreabilidade
  • Release notes
  • GitPage atualizado
  • Relatório final anexado
  • Links funcionando