Módulo 07

Boas Práticas e Padronização

A bíblia de padrões do time — hierarquia do backlog, nomenclaturas, vocabulário, antipadrões, regras de ouro do Gherkin e padrão de entrega ao DEV.

padrãonomenclaturaGherkinqualidade

Hierarquia do backlog

TEMA
  └── ÉPICO
        └── FEATURE
              └── USER STORY
                    └── TAREFA (nível do DEV)
NívelO que éExemploQuem escreve
TemaÁrea estratégica do produtoGestão de VendasPO / Gerência
ÉpicoConjunto de funcionalidades que entregam valor maiorRegistro e aprovação de pedidosAnalista + PO
FeatureFuncionalidade específica dentro do épicoRegistrar pedido manualAnalista
User StoryComportamento do ponto de vista do usuárioValidar desconto ao registrar pedidoAnalista
TarefaTrabalho técnico para implementar a USCriar endpoint POST /pedidosDEV
⚠️
Quando quebrar uma US? Mais de 8 critérios de aceite → provavelmente é uma feature. Não pode ser entregue em 1 sprint → grande demais. Não tem valor sozinha → pode ser uma tarefa.

Convenções de nomenclatura

ArtefatoFormatoExemplo
ÉpicoEP-[3 dígitos]EP-012
User StoryUS-[4 dígitos]US-0047
Caso de UsoUC-[3 dígitos]UC-023
Regra de NegócioRN-[3 dígitos]RN-008
Bug ReportBUG-[ano]-[4 dígitos]BUG-2025-0134
Req. Não FuncionalRNF-[3 dígitos]RNF-005

Títulos de User Story

✓ Correto

Registrar pedido de venda manual

Validar desconto aplicado por vendedor

Notificar gestor sobre pedido aguardando aprovação

✗ Evitar

"Pedido" — sem verbo, sem contexto

"O sistema deve permitir que o vendedor faça pedidos" — longo demais

"Tela de pedidos" — nome de tela, não comportamento

Vocabulário padrão

UsarNão usarPor quê
Critério de aceiteRequisito de aceite, regra de validaçãoTermo padrão em agilidade
Fluxo principalCaminho feliz, fluxo idealMais formal e preciso
Fluxo de exceçãoCaso de erro, cenário de falhaReservado para falhas técnicas
PersonaTipo de usuário, perfilTermo padrão em UX e agilidade
ÉpicoGrande história, feature grandeTermo padrão Scrum/SAFe
Definition of DoneCritério de conclusãoTermo padrão Scrum

Antipadrões — o que NÃO fazer

✗ US sem persona específica

Como usuário, quero fazer login.
"Usuário" não diz nada — cada DEV vai interpretar diferente.

✗ Critério de aceite não testável

Então o sistema funciona corretamente.
O QA não sabe o que testar.

✗ US que mistura funcionalidades

Como vendedor, quero registrar pedidos, consultar histórico, emitir relatórios e cancelar pedidos.
Impossível implementar e testar de forma incremental.

✗ Fluxo principal com condicionais

O fluxo principal é o caminho feliz, sem desvios. Condicionais vão nos fluxos alternativos.

Regras de ouro do Gherkin

Guia de escrita — clareza e precisão

💡
Escreva para quem não sabe nada do seu contexto. Revise com esta pergunta: "Se eu não soubesse nada deste sistema, conseguiria implementar só lendo este documento?"
✗ Vago

O sistema deve responder rapidamente

O campo aceita textos longos

Enviar notificação em breve após a ação

✓ Preciso

O sistema deve responder em até 2 segundos (95% das requisições)

O campo aceita até 500 caracteres

Enviar notificação em até 5 minutos após a confirmação

Padrão de versionamento

---
ID: US-0047
Título: Registrar pedido de venda manual
Versão: 1.2
Status: Aprovado   ← [Rascunho | Em revisão | Aprovado | Obsoleto]
Autor: [Nome]
Revisado por: [Nome]
Data de criação: 15/01/2025
Última atualização: 22/01/2025
Módulo: Gestão de Vendas
Épico: EP-003 — Registro e aprovação de pedidos
---

## Histórico de alterações
| Versão | Data | Autor | O que mudou |
|---|---|---|---|
| 1.0 | 15/01/2025 | Ana | Criação inicial |
| 1.1 | 18/01/2025 | Ana | Adicionado cenário de estoque insuficiente |
| 1.2 | 22/01/2025 | Ana | Regra RN-05 ajustada após reunião com comercial |

Pacote mínimo por tipo de demanda

TipoObrigatórioRecomendado
Correção de bugBug ReportPrint / log de evidência
Feature pequenaUser Story completaWireframe (se houver tela)
Feature média/grandeUS + Caso de Uso + FluxoDiagrama de sequência se integração
Novo móduloÉpicos + todas USs + UCs principais + FluxosSchema de banco