Aula 35 · Semana 14 · Quarta, 9 de dezembro de 2026 · 16:30 às 18:30
Como defender um projeto, freeze e ensaio
Teoria: estrutura de uma apresentação de dez minutos, demonstração ao vivo no telemóvel, plano B, e as perguntas em que cada membro responde pelo que fez. Prática: freeze do projeto com a tag v1.0.0 às 18:30, sorteio da ordem das defesas e ensaio com feedback dos colegas.
Freeze às 18:30
No fim desta aula consegues
Estruturar uma apresentação técnica de 10 minutos com três slides e uma demo ao vivo.
Projetar o telemóvel na sala e ter um plano B que arranca em 20 segundos.
Antecipar as perguntas típicas de uma defesa e responder pelo código que assinaste.
Fechar o projeto com a tag v1.0.0 e saber o que ainda pode mudar depois.
Dar e receber feedback útil num ensaio de 5 minutos.
Estrutura: dez minutos, cinco partes
Minuto
Parte
O que dizer
0 a 1
Problema
Para quem é a app e o que resolve. Uma frase. Não é "fizemos uma app de meteorologia": é "quem vive na Horta quer saber se amanhã há barco".
1 a 2
O que construíram
Os mínimos, os extras, o que ficou de fora e porquê. Honestidade aqui evita perguntas más depois.
2 a 6
Demo
Um utilizador real a usar a app: pesquisa, previsão, favorito noutro telemóvel, modo avião, um erro tratado. Quatro minutos, ensaiados ao segundo.
6 a 9
Decisões técnicas
Três decisões e o porquê: arquitetura, cache, o que fizeram quando a API mudou. Com um diagrama, não com código no ecrã.
9 a 10
O que fariam diferente
Uma coisa concreta que aprenderam. Fecha bem e mostra maturidade.
Três slides no máximo
Slide 1: a app. Nome, os membros, um screenshot por ecrã principal. Fica no ecrã enquanto contas o problema e o que construíram.
Slide 2: a arquitetura. Um diagrama de caixas: UI → notifier → repository → API e cache. Setas com nomes. É o slide que sustenta as decisões técnicas e as respostas às perguntas.
Slide 3: o que aprenderam. Três bullets: o que fariam diferente, o que ficou para depois, o que cada um levou. Fica projetado durante as perguntas.
Sem slides de código. Se uma pergunta pedir código, abre o editor e mostra o ficheiro: é mais credível e prova que sabes onde está.
Sem ler. Quem lê slides está a dizer ao júri que não sabe o que fez. Palavras-chave no slide, frases na tua boca.
Para os testes: não há. Isto é para a vida: em entrevistas técnicas vão pedir-te exatamente isto, "fala-me de um projeto teu em cinco minutos".
Demo ao vivo: telemóvel projetado
Android:scrcpy no portátil, telemóvel por cabo com depuração USB ligada. Mostra o ecrã do telemóvel numa janela que projetas. Instala-o hoje e testa-o hoje, não segunda.
iPhone: num Mac, QuickTime → Novo filme → escolher o iPhone como câmara; ou espelhamento AirPlay se a sala o tiver. Em Windows não há caminho fiável: grava vídeo.
Dados preparados: favoritos já escolhidos, cache já preenchida, a localidade da demo escolhida à partida. Ninguém quer ver-te escrever "Ponta Delgada" com o teclado a tremer.
Modo avião ensaiado: sabe exatamente que ecrã mostra "dados de há 12 min" e quanto tempo demora a aparecer.
Notificações e chamadas desligadas no telemóvel da demo. Modo Não incomodar. Brilho no máximo.
Quem faz a demo não é quem fala: um mexe no telemóvel, o outro narra. Ensaiem a coreografia.
Plano B: o vídeo
Grava hoje ou amanhã, com a app já no freeze, o mesmo percurso da demo: 3 a 4 minutos, com o ecrã do telemóvel gravado (Android: gravação de ecrã nativa ou scrcpy --record demo.mp4; iPhone: gravação de ecrã do Centro de Controlo).
Sem som ambiente. Quem apresenta narra por cima do vídeo, como faria com a demo real.
Fica no portátil e numa pen e num link. O dia em que o projetor não reconhece o portátil é o dia da defesa.
Se a demo ao vivo falhar, não insistas mais do que 20 segundos: "vou passar ao vídeo" e continua. O júri valoriza quem gere o problema, não quem se atrapalha.
Ter plano B não é sinal de fraqueza; é o que uma equipa profissional faz antes de qualquer apresentação a um cliente.
O emulador não é plano B Mostrar a app no emulador do portátil não conta como demonstração. A rubrica pede a app no telemóvel; o vídeo é do telemóvel.
Perguntas típicas (1 de 2)
Pergunta
Uma boa resposta inclui
Porquê esta arquitetura?
O que ganharam (testar sem rede, trocar fonte), o que custou (mais ficheiros), e que alternativa consideraram.
O que acontece sem rede?
Cache-first, o que se mostra, como se marca a antiguidade, o que acontece a um favorito adicionado offline.
Onde está o token?
flutter_secure_storage, Keychain e Keystore, porque não em shared_preferences, como se renova em 401.
Como testaram?
Quantos testes, de que tipo, com que fakes, o que o CI corre em cada PR, e o que não está testado.
Mostra-me onde isso está no código.
Abrir o ficheiro certo em menos de 15 segundos. Se hesitas, não sabes onde vive.
Perguntas típicas (2 de 2): como responder
Cada membro responde pelo que fez. As perguntas são dirigidas a uma pessoa pelo nome, com base nos PRs dela. Se o colega responder por ti, conta contra os dois.
Resposta curta primeiro, detalhe depois. "Cache-first com drift; mostro os dados antigos com a hora e atualizo em segundo plano" e depois, se pedirem, o resto.
"Não sei" é aceitável uma vez, seguido de "mas sei onde ia ver" ou "o que faria era". Inventar não é aceitável nenhuma vez.
Perguntas sobre o que não fizeram: "não fizemos porque X; se tivéssemos mais uma sprint faríamos Y assim". Sem desculpas, com plano.
Perguntas do teste 2 aplicadas ao projeto: conta com elas. "Que permissão de localização pedem e porquê?", "O que garante o vosso WorkManager?", "O que acontece se reutilizarem o versionCode?".
O júri não está a tentar apanhar-te; está a tentar perceber quanto do código é teu. Facilita-lhe a vida.
O que a rubrica valoriza e penaliza na defesa
Valoriza
App a correr no telemóvel, build de release, sem banner de debug.
Decisões técnicas explicadas com o porquê e a alternativa.
Cada membro a responder pelo seu código, com o histórico de PRs a confirmar.
Estados de erro e offline mostrados sem que o júri peça.
Honestidade sobre o que falta e o que fariam diferente.
Penaliza
Ler slides. Slides com código. Mais de três slides.
Um membro a falar por todos, ou a responder pelos outros.
Passar dos 10 minutos: a demo é cortada onde estiver.
Não saber onde está uma coisa no próprio código.
Demo no emulador, ou build de debug "porque o de release não instalava".
A distribuição e apresentação valem 10 % do projeto; a defesa individual ajusta a nota de cada um. Está tudo em Avaliação.
Freeze: tag v1.0.0 às 18:30
Até às 18:15: todos os PRs da milestone "Freeze v1.0.0" merged ou fechados. O que não entra vai para "Depois" e para o README.
CI verde em main. Sem isso não há tag; corrige o que falha ou reverte o PR.
Versão:version: 1.0.0+N no pubspec.yaml, com o N do último build distribuído.
Cria e publica a tag a partir de main atualizado. O docente verifica a hora do commit apontado pela tag.
git checkout main
git pull
git tag -a v1.0.0 -m "Tempo Açores v1.0.0: entrega para defesa"
git push origin v1.0.0
A partir das 18:30 só o README.md pode mudar (screenshots, links, retrospetiva). Qualquer outro commit depois da tag não é avaliado e conta como tentativa de contornar o prazo.
Tarefa Tag publicada e link do release no Moodle até às 18:30. Confirma com git ls-remote --tags origin que a tag está no GitHub, não só no portátil.
Sorteio da ordem das defesas
Os grupos são sorteados agora, na sala, com um gerador de números aleatórios projetado. A ordem fica no Moodle hoje.
Segunda 14/12, 16:00 às 18:00: primeira metade dos grupos. Quarta 16/12, 08:30 às 10:30: restantes, seguidos do encerramento.
Cada grupo tem 10 minutos de apresentação, 5 de perguntas e 2 de feedback. Entre grupos, 1 minuto para trocar o telemóvel no projetor.
Todos os membros presentes na sua defesa, e todos os grupos presentes nos dois dias: ver os outros defender faz parte da aprendizagem, e há feedback dos colegas.
Trocas de posição só por acordo entre dois grupos, comunicado ao docente até sexta.
Ordem Quem vai primeiro tem menos tempo de espera e um júri mais fresco. Não é castigo.
Ensaio: cinco minutos por grupo
Versão comprimida da defesa: 1 minuto de problema e o que construíram, 2 minutos de demo no telemóvel projetado, 1 minuto de uma decisão técnica, 1 minuto de perguntas de um colega de outro grupo.
Cronómetro visível. Aos 5 minutos o docente corta, mesmo a meio de uma frase. É isso que vai acontecer segunda aos 10.
Projeção real: o telemóvel ligado ao projetor da sala, não ao portátil do grupo. Se falhar agora, ótimo: falha hoje e não segunda.
Um colega de outro grupo faz uma pergunta da lista de perguntas típicas, dirigida a um membro à escolha.
Feedback de 2 minutos com a grelha do slide seguinte, por escrito, entregue ao grupo.
Tarefa Todos os grupos ensaiam hoje, pela ordem do sorteio. Quem tiver a demo a falhar na projeção resolve isso antes de sair da sala, com a ajuda do docente.
Grelha de feedback dos colegas
Critério
1
3
5
Clareza do problema e do que fizeram
Não percebi para que serve a app
Percebi, com esforço
Percebi na primeira frase
Demo
Não correu ou não se viu
Correu, mas com hesitações
Fluida, com estados de erro e offline mostrados
Decisão técnica
Descreveram o que fizeram
Explicaram porquê
Explicaram porquê e o que rejeitaram
Resposta à pergunta
Outro membro respondeu
Respondeu, vago
Respondeu curto, concreto e com o ficheiro à mão
Tempo e postura
Leram, passaram do tempo
Dentro do tempo, a ler pouco
Dentro do tempo, a olhar para a sala
Escreve também uma frase: a coisa mais útil que o grupo pode mudar até segunda. É essa que vale.
Até à próxima aula
Para fazer
Preparar a apresentação: três slides, guião de 10 minutos com quem diz o quê, e a demo ensaiada ao segundo pelo menos três vezes.
Plano B gravado: vídeo de 3 a 4 minutos da app no telemóvel, no portátil, numa pen e num link.
Cada membro relê os seus PRs e sabe explicar cada ficheiro que tocou.
README atualizado com o link do release e a retrospetiva. É a única coisa que ainda pode mudar.
Para ler
Android Debug Bridge: a autorização USB e o adb devices de que o scrcpy depende.
Flutter build modes: porque a demo é em release e o que muda em relação a debug.