📝 ATIVIDADE 04: USER STORIES E BACKLOG

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria ágil, mudando o foco do "O Quê" para o "Por Quê". 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

• Converter Requisitos Funcionais tradicionais em User Stories (Histórias de Usuário).
• Redigir histórias no padrão internacional da agilidade: "Como [Persona], Eu quero [Ação], Para que [Valor]".
• Criar Critérios de Aceite testáveis para definir o que significa uma tarefa "Pronta" (DoD).
• Priorizar e organizar um Product Backlog.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, você entregou a lista de Requisitos Funcionais (Atividade 03) para a equipe de programadores. Um dos requisitos era: "RF01: O sistema deve ter uma barra de busca na tela inicial".

Os programadores criaram uma barra de busca linda, mas ela só buscava clientes pelo CPF. Quando os motoristas tentaram usar, ficaram furiosos, pois eles queriam buscar o endereço do cliente, não o CPF! O requisito foi cumprido tecnicamente, mas falhou comercialmente por falta de empatia e contexto.

"Seu desafio como Product Owner / Analista é impedir que isso aconteça novamente. Você deve pegar seus requisitos frios e reescrevê-los como User Stories, colocando o desenvolvedor na 'pele' da Persona, e escrevendo Critérios de Aceite que não deixem margem para dúvidas sobre como a funcionalidade deve se comportar."

🧠 Fundamentos: A Teoria Traduzida

Na agilidade, nós não escrevemos ordens genéricas, escrevemos "histórias" curtas que justificam o esforço do programador.

O Padrão da User Story

Uma boa história deve caber em um post-it. Ela tem 3 partes:

1. Como [Papel/Persona]: Quem precisa disso?
2. Eu quero [Ação]: O que o sistema tem que fazer?
3. Para que [Valor/Benefício]: Por que isso é importante? Qual a dor que resolve?

📊 Visualizando a Lógica

[!TIP] Uma User Story sem Critérios de Aceite é apenas um desejo abstrato. O Critério de Aceite é o "Contrato" que o desenvolvedor assina dizendo: "Se o sistema passar nestes testes, a história está pronta".

flowchart TD
    A["RF01: O sistema deve ter uma busca"] --> B{"Lente Ágil"}
    B --> C["História:<br/>COMO Motorista...<br/>QUERO buscar por endereço...<br/>PARA evitar usar outro GPS."]
    C --> D["Critério de Aceite 1:<br/>A busca deve aceitar CEP."]
    C --> E["Critério de Aceite 2:<br/>Deve exibir mapa ao clicar."]

📖 Exemplo Guiado

Abaixo, veja como aplicar a técnica de User Stories e Critérios de Aceite no contexto da TecProExpress.

📊 Decomposição Ágil: Do Épico aos Critérios de Aceite

flowchart TD
    EP["Épico: Logística Last-Mile"] --> F1["Feature: Rastreamento em Tempo Real"]
    EP --> F2["Feature: Painel de Gestão Comercial"]
    F1 --> US1["US01: Atualização de Status da Carga"]
    F1 --> US2["US02: Geolocalização de Motoristas"]
    US1 --> CA1["Critério 1: Status 'Entregue' exige comprovante"]
    US1 --> CA2["Critério 2: Notificar cliente em < 5s"]

    style EP fill:#eceff1,stroke:#607d8b,stroke-width:2px
    style F1 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style F2 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style US1 fill:#fffde7,stroke:#fbc02d,stroke-width:2px
    style US2 fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Estrutura do Backlog

# Product Backlog (Priorizado)

## US01: Destaque de Pedidos Atrasados
**Como** Dona Silvana,
**Quero** ver os pedidos com prazo vencido destacados na cor vermelha,
**Para que** eu possa focar nas cobranças mais urgentes assim que abrir o sistema.

**Critérios de Aceite:**
1. Pedidos com data de vencimento < Data de Hoje devem ter a cor de fundo #FF0000.
2. A tela deve apresentar um botão no topo "Filtrar apenas atrasados".
3. Se não houver pedidos atrasados, exibir mensagem: "Tudo em dia!".

## US02: ...

🔍 Detalhamento da Documentação:

• Ao ler a US01, o programador entende a dor da Dona Silvana. Ele não fará apenas um "IF", ele entenderá o valor do negócio.
• Os Critérios de Aceite são o roteiro que o testador de QA (Quality Assurance) usará para aprovar ou reprovar a entrega da equipe.
• O documento completo forma o Product Backlog, que deve sempre estar organizado de cima para baixo (do mais importante para o menos importante).

🛠️ Prática Obrigatória: Construindo o Backlog

Cenário: O projeto semestral da sua equipe.

1. Selecione os 5 Requisitos Funcionais Essenciais da sua Atividade 03.
2. Transforme cada um desses 5 requisitos em uma User Story completa (Como/Quero/Para).
3. Abaixo de cada história, escreva pelo menos 2 Critérios de Aceite exatos e testáveis.
4. Organize as 5 histórias em ordem de prioridade (A número 1 é a primeira que os desenvolvedores começariam a programar na segunda-feira).

🏁 Resultado Esperado (Para sua Referência)

Um documento Markdown listando seu Backlog Ágil inicial, contendo as 5 histórias detalhadas. Isso servirá de insumo para todas as modelagens UML das próximas aulas.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seu Backlog Ágil:

1. Salve o arquivo de documentação com o nome Atividade_04.md na pasta es-atv-04-backlog/ do seu repositório GitHub.
2. Certifique-se de fazer o commit e push para o repositório público.
3. Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Imagine uma história que diz: "Como usuário, quero me cadastrar no sistema, para acessar minha conta". Há dois erros gravíssimos nessa história. O primeiro é escrever "Como usuário" (um termo vago que destrói o propósito da Persona). O segundo é o "Para acessar minha conta" (Isso não é o benefício real do cadastro, é apenas uma obviedade do sistema. O real benefício de se cadastrar na Netflix, por exemplo, é 'salvar meus filmes favoritos'). Nunca escreva obviedades, descubra o valor de negócio! 🧠🛡️