Documentar e demonstrar um projeto
Visão, relatório de desenvolvimento, evidência, pitch e demonstração com um cenário concreto.
Uma equipa nova recebe o repositório em setembro. Precisa de perceber o produto, executar a aplicação e alterar regras. A documentação permite essa continuação. A apresentação, por sua vez, ajuda uma audiência a avaliar o problema, a solução e a evidência do resultado.
Visão e âmbito
A visão descreve utilizadores, problema e valor pretendido. Para a aplicação de salas:
Estudantes que precisam de um espaço de grupo conseguem encontrar e reservar uma sala disponível, sem depender de deslocações para confirmar horários.
O roadmap delimita o que cada versão permite fazer:
- Versão zero: consultar disponibilidade real de uma sala.
- Versão um: reservar atomicamente e cancelar.
- Versão dois: pedir equipamento, como extensão futura.
O plano pressupõe que a escola fornece horários fiáveis. Entrevistamos dois estudantes para esclarecer necessidades e comparamos a API com os horários afixados para avaliar os dados. Se a fonte falhar, revemos o âmbito para usar importação manual.
Um elevator pitch é uma explicação curta do problema e da proposta que deve permitir a outra pessoa repetir o que o produto faz. Um nome e um slogan não substituem essa explicação.
Relatório de desenvolvimento
O relatório liga as atividades e as decisões:
| Parte | O que deve permitir compreender |
|---|---|
| Visão | Problema, utilizadores, valor e limites |
| Requisitos | Histórias, regras, critérios e prioridades |
| Modelos | Conceitos e cenários do domínio |
| Arquitetura e desenho | Responsabilidades, interfaces e razões das escolhas |
| Construção e testes | Como executar e que evidência existe |
| Gestão | Planos, resultados e alterações de prioridade |
| Aprendizagem | Problemas observados e melhorias experimentadas |
Não copies todos os slides da cadeira. Explica a solução concreta. Um diagrama sem relação com o código pode enganar mais do que a ausência do diagrama.
As instruções de execução devem identificar versões, configuração, construção, testes e dados de exemplo. Não publiques credenciais nem informação pessoal de colegas.
A evidência de cada release indica versão, histórias fechadas e resultado dos testes. Assim não confundes o estado final com capturas antigas. O protótipo vertical escolhido permite reservar uma sala com servidor e dados de teste. Para estudar concorrência, precisamos ainda de provocar pedidos simultâneos e conferir o estado final.
Um protótipo vertical
Um protótipo vertical atravessa partes da solução para estudar uma capacidade de ponta a ponta. No nosso caso, o estudante escolhe uma sala, o servidor avalia a reserva, o armazenamento regista o resultado e o ecrã apresenta a confirmação.
Pode ser estreito em funcionalidades e continuar a testar integração real, enquanto um conjunto de ecrãs com dados fictícios é útil para validar interação, mas não prova que essa sequência técnica funciona. Escolhe o protótipo conforme a incerteza: se a dúvida é usabilidade, testa o percurso; se é concorrência, testa o mecanismo de confirmação; se é integração, atravessa os componentes reais relevantes.
Preparar um pitch
Começa por quem tem o problema e mostra um exemplo. Explica a proposta, as alternativas existentes e a diferença concreta. Apresenta o que foi alcançado e o próximo objetivo com evidência.
Na aplicação, o exemplo pode ser um grupo que precisa de uma sala amanhã das 14h às 15h. A apresentação mostra como encontra uma sala e obtém confirmação. Não promete “resolver todos os problemas da universidade”.
Escolhe informação para a audiência. Uma pessoa que avalia o produto precisa de perceber benefício e limitações; uma equipa técnica também precisa de decisões e condições de execução. Evita métricas sem origem e afirmações como “mais rápido” sem comparação definida.
Demonstrar comportamento
Uma demonstração percorre um cenário observável. Prepara o estado inicial, dados de exemplo e resultado esperado:
- Mostrar uma sala livre num intervalo.
- Confirmar uma reserva nesse intervalo.
- Consultar a disponibilidade novamente.
- Tentar uma reserva sobreposta e mostrar a recusa.
- Cancelar a reserva e confirmar que o intervalo fica livre.
Estes passos demonstram sucesso, alteração de estado e uma restrição. Explica qualquer parte simulada. Se a notificação ainda não estiver implementada, um desenho mostra a intenção, mas não prova que foi enviada.
Prepara uma alternativa para uma falha externa, como uma gravação da mesma versão e cenário. Permite explicar o trabalho, desde que identifiques que é uma execução gravada. Mantém clara a diferença entre demonstração, teste e promessa.
Refletir sobre o trabalho
Uma reflexão útil liga observação e aprendizagem. “Trabalhámos bem” não explica o que aconteceu. “Integrámos tarde e descobrimos uma incompatibilidade de datas; no Sprint seguinte integramos alterações pequenas diariamente” identifica problema e ação.
Ao usar IA, explica o que a ferramenta sugeriu, o que a equipa verificou e que decisões alterou. Não atribuas correção à ferramenta apenas porque o código compilou. A capacidade de justificar a solução continua a pertencer à equipa.
Uma reflexão sobre uma ferramenta também precisa de evidência. «Usámos controlo de versões» apenas a nomeia. «Uma colega conseguiu integrar a correção da autorização sem apagar a pesquisa em curso» mostra valor. «O primeiro merge compilou, mas cada ramo interpretava um estado de forma diferente; acrescentámos um cenário de integração e um glossário comum» identifica dificuldade, resposta e resultado. A mesma ferramenta pode ser útil e continuar a exigir aprendizagem; instalar uma ferramenta não demonstra que resolveu o problema.
Exercícios
Ecrãs ou integração?
Um protótipo mostra todos os ecrãs com dados fictícios. Outro permite reservar uma única sala com servidor e dados reais de teste. Qual responde melhor ao risco de integração? A criação de uma reserva isolada também demonstra que o sistema impede duas reservas concorrentes?
Pista
Solução
O segundo é um protótipo vertical adequado para estudar integração: atravessa ecrã, serviço e dados com uma sala de teste. Uma execução isolada não prova concorrência: precisamos de provocar duas tentativas sobrepostas em simultâneo e conferir respostas e estado final. O primeiro pode ajudar a validar navegação e informação com estudantes, mas não demonstra que o servidor e os dados respeitam as regras.
Confere a tua resposta:
- Escolhi o segundo para integração.
- Expliquei que atravessa as partes da solução.
- Reconheci a utilidade do primeiro para interação.
- Distingui atravessar componentes de demonstrar a regra de concorrência.
Erros frequentes
Não classifiques um protótipo só pela quantidade de ecrãs. Não uses dados reais pessoais para tornar a demonstração convincente.
Uma demonstração honesta
Planeia uma demonstração da reserva e de uma recusa. As notificações ainda não existem. O que mostras e o que explicas?
Pista
Solução
Mostramos a versão e os dados de teste. Depois sala livre, criação da reserva, nova consulta e tentativa sobreposta recusada, com estado final conferido nos dados. Explicamos que as notificações ainda não estão implementadas, sem apresentar um desenho como envio real.
Confere a tua resposta:
- Preparei estado, versão e dados de exemplo.
- Incluí confirmação e recusa com estado final.
- Identifiquei notificações como não implementadas.
Erros frequentes
Não confundas mockups com execução. Uma falha externa e uma gravação preparada devem ser identificadas, não escondidas.
Uma ferramenta instalada e uma dificuldade resolvida
Uma equipa escreve: «Git foi muito útil; fizemos muitos commits e tudo ficou integrado». O registo mostra um merge sem conflitos e seis testes isolados a passar, mas o cliente interpreta «pendente» como não pago e o servidor como pago, à espera de validação. A equipa acordou um glossário, corrigiu os consumidores e repetiu o cenário de compra completo com o estado final conferido. Reescreve a reflexão: finalidade da ferramenta, valor que o registo sustenta, dificuldade encontrada e resposta. Que parte da frase inicial excede a evidência?
Solução
Git regista alterações e permite combinar linhas de trabalho. O registo mostra que a equipa conseguiu integrar os ficheiros sem conflito textual; não mostra que essa integração estava semanticamente correta. A dificuldade foi a interpretação incompatível de «pendente», que os testes isolados não detetaram. A resposta foi acordar o glossário, corrigir o uso do estado e verificar o cenário completo, incluindo o estado final.
«Tudo ficou integrado» sugere correção que o merge e os seis testes não demonstram. A evidência posterior sustenta a correção do cenário observado, não de todos os comportamentos. Quantidade de commits não mede valor nem qualidade das alterações.
Confere a tua resposta:
- Separei finalidade, valor observado, dificuldade e resposta.
- Usei o erro de interpretação como evidência de integração insuficiente.
- Não atribuí garantia de correção ao merge nem a seis testes isolados.