Kickoff do projeto Tempo Açores

No fim desta aula consegues

• Definir o MVP do Tempo Açores e distinguir cortar funcionalidades de cortar qualidade.
• Escrever issues com título, critérios de aceitação e estimativa grosseira.
• Aplicar a definição de pronto a cada pull request do grupo.
• Seguir o fluxo issue → branch → PR → revisão → merge sem ninguém fazer push para main.
• Sair da aula com grupo, repositório, client-id da API e backlog da sprint 1.

MVP: o mínimo que se instala e se usa

• O produto mínimo viável é a versão mais pequena que alguém instala e usa com proveito. Não é um protótipo, nem uma demo.
• No Tempo Açores: lista de localidades, previsão de uma localidade, favoritos, e continuar a funcionar sem rede com dados antigos.
• Cortar funcionalidades, não qualidade. Um ecrã com os quatro estados tratados vale mais do que três ecrãs meio feitos.
• Pergunta por funcionalidade: "se isto não existir, a app é inútil?" Se a resposta é não, vai para a lista "depois".
• Exemplos reais: o Instagram v1 só tinha fotos com filtro e um feed; o WhatsApp v1 era uma app de estados. Cresceram depois.

Para os testes: o MVP corta âmbito, nunca qualidade; cada funcionalidade que fica, fica completa.

Backlog em issues

• Título: verbo + objeto. "Mostrar previsão a 5 dias da localidade", não "Previsão".
• Corpo: contexto em uma frase e critérios de aceitação em checklist, no formato "dado X, quando Y, então Z".
• Estimativa grosseira: P (meio dia), M (um dia), G (dois ou mais). Uma issue G divide-se em duas M antes de entrar na sprint.
• Labels e responsável: sprint-1, ui, dados, bug; uma pessoa por issue; ligada ao board do projeto.
• Exemplo de critério: "Sem rede, o ecrã mostra a última previsão guardada e a hora a que foi obtida."

Para os testes: uma issue boa tem título com verbo, critérios de aceitação verificáveis e uma estimativa.

Definição de pronto

Uma issue está pronta quando o PR que a fecha cumpre tudo isto. Se falha um ponto, não está pronta, por muito que "funcione no meu portátil".

• Corre no telemóvel, não só no emulador.
• flutter analyze sem avisos e flutter test verde.
• PR revisto e aprovado por outro membro do grupo.
• Estados loading, erro, vazio e dados tratados em cada ecrã tocado.
• Sem segredos no código (aula 18) e a issue fechada pelo PR (Closes #12).

Para os testes: "pronto" é uma lista objetiva, não uma opinião.

Fluxo: issue → branch → PR → revisão → merge

1. Issue atribuída a uma pessoa, na coluna "Em curso" do board.
2. Branch a partir de main atualizado: git switch -c feat/12-previsao-5-dias. O número da issue no nome.
3. Commits pequenos com conventional commits: feat(previsao): mostrar 5 dias, fix(api): tratar 429.
4. PR pequeno (menos de 300 linhas), com descrição, screenshot do telemóvel e Closes #12.
5. Revisão por um colega: pelo menos um comentário útil; o autor responde ou corrige.
6. Merge (squash) feito pelo revisor; branch apagada. main está protegido: ninguém faz push direto.

Para os testes: main protegido, PR pequeno e revisão de um colega é o fluxo mínimo de uma equipa.

Sprints e reviews

• O que se mostra numa review: 5 minutos por grupo, a app no telemóvel projetado, o que ficou por fazer e porquê. Sem slides.
• Retrospetiva de 15 minutos: começar, parar, continuar. Muda-se o processo, não se procuram culpados.

Para os testes: a review mostra software a funcionar no dispositivo; a retro melhora o processo da sprint seguinte.

Hoje: enunciado, grupos, repositórios, backlog

• Objetivo da aula: cada grupo sai com repositório criado, app template a correr no telemóvel com dados da API, e backlog da sprint 1 no board.
• Enunciado e rubrica (15 min): leitura em conjunto da página Projeto. Requisitos mínimos, extras, o que a rubrica valoriza na app, no processo e na defesa. Perguntas no fim de cada secção.
• Sprint 1 (até 02/11): lista de localidades da API, detalhe com 5 dias, navegação e tema, estados tratados em todos os ecrãs, favoritos locais.
• O que não entra na sprint 1: cache em disco (aula 16), autenticação com renovação (aula 17), mapa e notificações (sprints 2 e 3).

Grupos, GitHub Classroom e client-id

1. Grupos de 2 a 3. Nome do grupo e membros no formulário do Moodle. Sem grupos de 1 nem de 4.
2. Aceitar o assignment no GitHub Classroom (link no Moodle). O primeiro membro cria a equipa, os outros juntam-se. O repositório nasce a partir do template tempo-acores-template.
3. Clonar e correr. O template já tem ApiClient, tema, navegação e os widgets de estado das aulas 12 a 14.

   git clone https://github.com/pdm-daw-2026/tempo-acores-grupo-07.git
   cd tempo-acores-grupo-07
   flutter pub get
   flutter run --dart-define=PDM_CLIENT_ID=grupo-07 --dart-define=PDM_SECRET=segredo-do-envelope

4. Receber o client-id e o segredo do grupo, em mão. O segredo nunca entra no repositório: passa por --dart-define ou por um .env.json ignorado pelo git.
5. Primeiro pedido: a app template mostra a lista de localidades vinda de GET /v1/locations com o token do grupo. Se aparecer 401, o segredo está mal escrito.

Backlog da sprint 1 e board

• Board do projeto com as colunas Backlog, Sprint 1, Em curso, Em revisão, Feito.
• Entre 6 e 10 issues na sprint 1, cada uma com critérios de aceitação e estimativa P/M/G. Os mínimos primeiro.
• Sugestão de divisão: lista de localidades e pesquisa · detalhe com 5 dias · navegação, tema e definições · favoritos locais · estados de erro e mensagens · README e CI básico.
• Cada membro responsável por 2 a 3 issues. Ninguém fica só com "UI" nem só com "dados": todos tocam nas duas camadas.
• Uma issue "Auditoria de segurança" vazia, para a aula 18.

Primeira PR e o que o docente faz

• Primeira PR do grupo: README.md com nomes, divisão inicial de trabalho e um screenshot do template a correr no telemóvel. Aberta por um membro, revista e feita merge por outro. Serve para testar o fluxo antes de haver código.
• Branch protection em main: o docente ativa em todos os repositórios até amanhã. A partir daí só entra código por PR aprovado.
• O docente hoje: valida grupos e repositórios, entrega client-ids, passa por cada grupo para ver o backlog e o primeiro pedido à API no telemóvel.
• O docente durante a sprint: comenta PRs, acompanha a telemetria da API por grupo, responde no fórum do Moodle. Não faz código pelo grupo.

Até segunda