LIM-134 — Análise do Backlog Priorizado

1. Identificação

Issue	LIM-134 — Criar artigo acadêmico analisando o backlog do projeto
Data	2026-05-21
Agente	Documentador Acadêmico Free (f1b0f6c7)
Tipo	Estudo preparatório para artigo acadêmico
Status	Concluído
Referência	BACKLOG_PRIORITIZACAO.md

2. Objetivo

Analisar academicamente o backlog priorizado do projeto Laboratório de Hardware 2025, aplicando a Matriz de Impacto vs Esforço como metodologia de priorização. O resultado será incorporado como seção do artigo acadêmico principal (docs/artigo.html).

3. Metodologia Aplicada

A priorização do backlog utilizou a Matriz de Impacto vs Esforço, técnica clássica de gestão de produtos que classifica tarefas em quatro quadrantes:

4. Distribuição Quantitativa

Nota: A soma das porcentagens excede 100% porque as categorias Fill-ins e Quick Wins têm o mesmo número de itens (3) e os 2 Time Sinks são contados separadamente. O total é de 10 tarefas (considerando que o backlog lista 10 itens, sendo 2 Time Sinks a evitar).

5. Análise Crítica por Categoria

5.1 Quick Wins — Acertos e Oportunidades

Acertos: As três Quick Wins são tarefas de baixíssimo risco e alto retorno. A correção de Root Path evita execução em contexto incorreto; a limpeza de issues duplicadas reduz ruído no board; a correção de keyword melhora a qualidade acadêmica do abstract.

Oportunidade: Adicionar validação automatizada de consistência (ex.: linter para AGENTS.md) como extensão da Quick Win #1.

5.2 Major Projects — Planejamento Necessário

Módulo de Empréstimos: Maior prioridade entre os projetos complexos. Já foi implementado conforme commits recentes (85f5e31). A priorização original está correta — era a funcionalidade mais crítica pendente.

Segurança: A auditoria LIM-201 já identificou e corrigiu vulnerabilidades XSS em flash messages. A correção de CSRF e bcrypt já está aplicada, o que reduz o risco deste Major Project.

5.3 Fill-ins — Baixo Risco, Valor Moderado

As três tarefas de preenchimento são adequadas para intervalos entre sprints. A documentação de APIs internas é a mais relevante entre elas, pois contribui para a manutenibilidade do sistema.

5.4 Time Sinks — Risco de Escopo Creep

Refatoração CSS: A justificativa está correta — o layout é funcional e não justifica retrabalho. Deve ser evitada até que haja demanda explícita de usabilidade.

Funcionalidades Não-Solicitadas: Risco real de escopo creep. A classificação como Time Sink é acertada.

6. Análise de Riscos da Priorização

Risco	Categoria	Probabilidade	Mitigação
Dependência técnica entre Quick Wins e Major Projects	Processo	Média	Quick Wins são independentes — podem ser executadas em paralelo
Major Projects bloquearem sprints seguintes	Agenda	Média	Dividir em fases (básico, avançado) conforme já planejado
Despriorização de testes automatizados	Qualidade	Alta	Testes aparecem apenas no BL-12 (S12) — podem chegar tarde demais
Time Sinks consumirem atenção mesmo com classificação baixa	Gestão	Média	Bloquear explicitamente no board com label "time-sink"

7. Recomendações

1. Manter a priorização atual: A Matriz de Impacto vs Esforço está bem aplicada. As Quick Wins devem ser executadas primeiro.
2. Antecipar testes automatizados: O BL-12 está previsto para a Sprint 12, mas testes desde o início reduzem dívida técnica.
3. Criar label "time-sink" no board: Para evitar que essas tarefas sejam acidentalmente priorizadas.
4. Adicionar validação automatizada: Como extensão das Quick Wins, criar um script de validação de consistência do AGENTS.md.
5. Revisar periodicamente: Conforme documentado no próprio backlog, revisar a cada sprint planning.

8. Referências

• BACKLOG_PRIORITIZACAO.md — Documento original de priorização
• docs/artigo.html — Artigo acadêmico principal
• Auditoria LIM-134 — Série histórica da análise
• Issue LIM-134 — Issue original