Ficha 01 · Setup, Git, controlo · Ficha de trabalho

Aluno(a)

Turma

Nº

Data

Objectivos da ficha

Setup pro
Git workflow
Burndown
DoD

Parte I · Setup do projecto

Exercício 1 · Estrutura de pastas (10 pts)

Propõe uma estrutura de pastas para um projeto multimédia de cliente (site institucional + 1 vídeo).

restaurante-marvista/
├─ 00-brief/
│   ├─ briefing-criativo.md
│   ├─ contrato.pdf
│   └─ comms/
├─ 01-research/
│   ├─ moodboard.png
│   └─ refs/
├─ 02-design/
│   ├─ figma-link.txt
│   ├─ exports/
│   └─ tokens.json
├─ 03-content/
│   ├─ copy/
│   ├─ fotos/
│   └─ video-rough/
├─ 04-build/   (código do site)
├─ 05-qa/
│   ├─ checklist.md
│   └─ lighthouse-reports/
├─ 06-deliverables/
│   ├─ video-final.mp4
│   └─ site-build/
├─ 07-archive/  (versões antigas, takes não usadas)
└─ README.md

Padrão: numerada (ordem do workflow), nomes em inglês ou minúsculas, README como mapa.

Exercício 2 · Naming (10 pts)

Lê estes nomes de ficheiro e indica quais seguem boa convenção e o que corrigir:

a) Logo Final FINAL (2) v3.psd

b) 20260520_logo_v3.svg

c) homepage.png

d) site - novo - última versão!!!.zip

e) Aula 5/exercício 2.pdf

a) ✗ Mau — espaços, "Final FINAL", redundância, caracteres difíceis. Corrigir: 20260520_logo_v3.psd

b) ✓ Bom — data, componente, versão, sem espaços nem acentos.

c) ✗ Insuficiente — sem versão nem data. Se houver mais versões, ambíguo. Corrigir: 20260520_homepage_v1.png

d) ✗ Mau — caracteres especiais (!!!), espaços, "última" enganador. Corrigir: 20260520_site_v4.zip

e) ✗ Espaços + barra dentro do nome. Corrigir: aula05_exercicio02.pdf

Regra: aaaammdd_componente_versao.ext, sem espaços/acentos/caracteres especiais.

Parte II · Git

Exercício 3 · Branches (10 pts)

Estás a implementar 2 features em paralelo no mesmo repositório: "página de menu" e "formulário de contacto". Que branches crias e como mergeias?

A partir de main:

git checkout main
git pull
git checkout -b feature/pagina-menu
# trabalhar...
git push -u origin feature/pagina-menu
# abrir Pull Request → review → merge para main

git checkout main
git pull
git checkout -b feature/formulario-contacto
# trabalhar...
# PR → review → merge

Regras: - main sempre produzível. - Branches curtas (1-3 dias máximo). - PR + code review por outro membro antes de merge. - Apagar a branch após merge.

Exercício 4 · Conventional Commits (10 pts)

Classifica/corrige estes commits:

a) update

b) feat: adiciona página de menu

c) final final v3

d) fix: corrige contraste do CTA (WCAG 1.4.3)

e) asdfg

a) ✗ Sem informação. Corrigir: feat: adiciona página menu ou fix: corrige link header. b) ✓ Bom — tipo + descrição clara. c) ✗ Sem tipo, sem informação útil. Corrigir: chore: ajusta build de produção (ou o que for). d) ✓ Excelente — tipo + descrição + referência WCAG (contexto). e) ✗ Ruído. Esquecer, fazer commit decente.

Tipos comuns: feat, fix, docs, style, refactor, test, chore.

Parte III · Controlo

Exercício 5 · Burndown (15 pts)

Tens este burndown ao fim de 3 das 4 semanas planeadas:

sem  | plano restante | real restante
  0  | 200h           | 200h
  1  | 150h           | 170h
  2  | 100h           | 140h
  3  |  50h           | 110h
  4  |   0h           |  ?

a) Que problema vês?

b) Que ações tomar?

a) Atraso a acumular. Real está 60h acima do plano à entrada da semana 4 (110 vs 50). Para terminar a tempo, teriam de fazer 110h em 1 semana. Inviável.

b) Replanear cedo é a única saída honesta:

Comunicar ao cliente imediatamente (não na sexta da entrega).
Reduzir scope — passar Should/Could para fase 2.
Renegociar prazo — adiar 1-2 semanas.
Aumentar capacidade — horas extra (custo + risco de burnout) ou subcontratar.
Combinar — alguma redução de scope + 1 semana extra costuma ser a opção viável.

Não fazer: trabalhar 16h/dia na esperança de "milagre". Burnout + qualidade má + cliente surpreendido na entrega.

Exercício 6 · Sinais vermelhos (10 pts)

Quais destes sinais indicam projeto em risco e merecem replaneamento?

a) 80% do orçamento gasto, 50% do prazo decorrido. b) Cliente parou de responder há 5 dias. c) Caminho crítico atrasado 1 dia. d) Designer principal saiu da empresa. e) Lighthouse score 75 em vez de 90.

a) Vermelho. Vai gastar todo o orçamento e ainda falta metade do trabalho. Replanear. b) Amarelo/vermelho. Bloqueios de aprovação acumulam. Comunicar e escalar. c) Amarelo. 1 dia recuperável; monitorizar. d) Vermelho. Risco de equipa. Activar plano R2 do risk register (backup, cross-train). e) Amarelo. Abaixo do DoD definido (90). Corrigir antes de "pronto", não replanear ainda.

Resumo: a, b, d são vermelhos. c, e amarelos.

Parte IV · Definition of Done

Exercício 7 · DoD web (15 pts)

Escreve uma Definition of Done para "página de website pronta a entregar".

Página web — Definition of Done
-----------------------------------------------------------
[ ] HTML semântico válido (validator.w3.org sem erros).
[ ] Lighthouse ≥ 90 em Performance, Accessibility, SEO,
    Best Practices.
[ ] LCP < 2.5s; CLS < 0.1; INP < 200ms.
[ ] Testado em Chrome, Firefox, Safari (latest).
[ ] Mobile real (375 px) sem scroll horizontal nem texto
    cortado.
[ ] Tab por todo o conteúdo focável; foco visível.
[ ] Imagens com alt; formulários com label.
[ ] Sem console.error em produção.
[ ] Formulários funcionam (mensagem enviada + confirmação).
[ ] Páginas de erro tratadas (404 customizada).
[ ] HTTPS activo + redirect HTTP→HTTPS.
[ ] OG image + meta description preenchidos.
[ ] Code review aprovada por outro membro.
[ ] Cliente aprovou por escrito.

Exercício 8 · DoD vídeo (10 pts)

Escreve DoD para "vídeo institucional de 90s pronto a entregar".

Vídeo institucional 90s — Definition of Done
-----------------------------------------------------------
[ ] 1080p / 30 fps (ou 4K / 30 conforme briefing).
[ ] Codec H.264, MP4 (master) + versões web (720p, 1080p).
[ ] Loudness ~ −14 LUFS (web) ou −23 (TV).
[ ] Sem clipping, sem "popping".
[ ] Legendas SRT sincronizadas, sem typos.
[ ] Cor consistente entre planos (shot matching).
[ ] Música licenciada (atribuição registada).
[ ] Pessoas com autorização de imagem (RGPD).
[ ] Versão vertical 9:16 (story) para redes sociais.
[ ] Cliente aprovou por escrito.

Parte V · Mudanças

Exercício 9 · Change request (10 pts)

Cliente envia email: "Decidi que afinal queremos uma versão em espanhol também. Conseguem incluir até à entrega?"

Escreve uma resposta breve (3-5 linhas) seguindo o processo de change request.

Olá [cliente],

Obrigado pelo pedido. Posso avaliar o impacto e devolver
amanhã com 3 opções:
1. Incluir o ES no scope actual com prazo +1 semana e
   custo estimado de +X €.
2. Trocar o ES por outra feature já planeada de peso
   equivalente (sem custo extra).
3. Lançar PT+EN como planeado e adicionar ES na fase 2
   (recomendado se o prazo é crítico).

Aguardo a tua decisão para avançar.

3 opções (incluir / trocar / adiar), prazo + custo associados, decisão fica com o cliente, antes de qualquer trabalho.