Backlog prioridades e pronto
Nesta aula
Da vontade ao trabalho verificável
Backlog é a lista organizada do trabalho considerado para o produto. Uma vontade como melhorar o catálogo ainda não define uma alteração executável. O item precisa dizer por que existe, qual comportamento mudará, do que depende, quem responde por ele e como reconhecer sua conclusão. A ordem pode mudar quando surgem evidências, desde que o motivo permaneça visível.
Prioridade expressa importância relativa dentro de um contexto e uma versão. Não substitui dependência: um item P1 pode precisar de uma definição de contrato antes de ser implementado. O contrato necessário pode ser acordado cedo, permitindo que código e interface avancem em paralelo com dados de teste; não é preciso esperar uma tecnologia de armazenamento inexistente no projeto.
| Prioridade | Significado adotado na Oficina Caracol | Exemplo contextual |
|---|---|---|
| P1 | Bloqueio de segurança ou de funcionalidade essencial | Impedir que um inativo seja entregue ao público |
| P2 | Capacidade necessária da versão definida | Feedback acessível exigido no incremento |
| P3 | Melhoria reversível sem impedir os critérios atuais | Refinar espaçamento mantendo comportamento aprovado |
| P4 | Exploração ou futuro fora do compromisso atual | Pesquisar busca avançada ainda não incluída no escopo |
As categorias não são propriedades eternas de um recurso. Se o feedback acessível falhar de modo que bloqueie o uso essencial, sua correção passa a P1 naquele contexto. Se uma animação se tornar um requisito necessário de uma demonstração específica, sua classificação deve ser renegociada com o escopo, sem reduzir exigências essenciais para acomodá-la.
Cinco desejos transformados
Entrada do exercício trabalhado: esconder os inativos, mostrar mensagem quando não há casos, garantir uso por teclado, deixar cartões mais bonitos e estudar busca. O responsável do exemplo é quem mantém a Oficina; a classificação é uma decisão didática que deverá ser revista se o contexto mudar.
| Item e prioridade | Aceite específico | Dependência e evidência |
|---|---|---|
| BL-01 P1 Ocultar inativos | API pública não inclui o registro inativo conhecido | Contrato ativo; teste do módulo e servidor |
| BL-02 P2 Tratar vazio | Lista válida sem ativos produz mensagem distinta de erro | Seleção e apresentação; teste e inspeção |
| BL-03 P2 Verificar teclado | Percurso e feedback previstos são operáveis e registrados | Interface integrada; verificação manual |
| BL-04 P3 Refinar cartões | Melhorar espaçamento sem perder foco ou conteúdo | Interface estável; comparação e regressão pertinente |
| BL-05 P4 Explorar busca | Registrar alternativas, limites e decisão de escopo | Tempo de investigação; nota de decisão, sem prometer implementação |
Cada linha diferencia resultado e atividade. BL-05 pode concluir uma investigação sem criar a busca, porque esse é seu aceite. BL-01 não conclui ao escrever o teste: precisa obter resultado aceitável na implementação integrada. Uma tarefa de teste pode existir como unidade do trabalho, mas a capacidade depende do comportamento demonstrado.
Aceite e definição de pronto
Critério de aceite descreve o comportamento particular de um item. Definição de pronto reúne condições comuns à entrega, como revisão do impacto, verificação aplicável aprovada, integração e atualização de documentação necessária. Nenhuma das duas deve ser apenas marcar uma caixa. Para BL-01, ter um teste escrito é insuficiente se ele falha ou se o servidor contorna a seleção.
- Vincule o item a um objetivo ou requisito.
- Defina resultado e exemplos de aceite; elimine verbos vagos sem complemento.
- Identifique dependências reais e responsáveis.
- Atribua prioridade com motivo e revise a ordem conforme risco e aprendizado.
- Ao concluir, ligue evidência, versão e consequência; conserve os itens adiados de maneira explícita.
Erros e reparos
| Erro | Reparo |
|---|---|
| Tudo marcado como P1 | Reavaliar bloqueio real e compromisso da versão; ordenar dependências e impacto |
| Item chamado melhorar | Escrever comportamento observável e limites |
| Fechamento sem integração | Manter a capacidade aberta até a prova de seu percurso |
| Prioridade usada para ignorar dependência | Antecipar o contrato necessário e ajustar a ordem executável |
Exercício resolvido e gate
Dados: BL-01 foi implementado, teste do módulo passou em um cenário didático, mas o servidor ainda retorna o inativo. BL-04 está pronto visualmente. O responsável quer concluir a versão e deixar a falha para depois. Qual a decisão?
Ver solução comentada
Solução: não concluir BL-01 nem a versão que exige REQ-002. A falha integrada mantém um bloqueio P1, mesmo com teste local aprovado. Revisar a formação da resposta do servidor, repetir a verificação da fronteira HTTP e a regressão pertinente. BL-04 pode manter sua conclusão local, mas não compensa o requisito essencial ausente.
- Rubrica: reconhecer a falha integrada, manter P1 e indicar a prova que falta; não calcular uma média entre melhoria visual e requisito essencial.
- Gate: itens ativos têm escopo, prioridade justificada, dependências e aceite; os itens necessários à versão só são concluídos com resultado aceitável e integração comprovada.
Leitura relacionada
S01, áreas de requisitos e gestão de engenharia, e S16, planejamento e monitoramento de testes, ajudam a relacionar compromisso, risco e evidência. A escala P1–P4 acima é a convenção contextual do projeto, não uma norma universal.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S01 S16Tente o exercício antes de consultar a solução. Marque a aula para organizar sua leitura.
A conclusão desta leitura não equivale a certificação ou aceite de um projeto real. Teste os exemplos no escopo indicado e registre as limitações.