⚡ CAPÍTULO 04: METODOLOGIAS ÁGEIS (SCRUM, KANBAN E XP)


🎯 1. Objetivos de Aprendizagem & Competências

Estimativa de Dedicação: 2 horas de estudo autoguiado.
Ao final deste capítulo, você será capaz de:

  • 🔹 Compreender os 4 valores e os 12 princípios do Manifesto Ágil de 2001 e sua aplicação na engenharia moderna.
  • 🔹 Dominar a tríade de papéis (Product Owner, Scrum Master, Developers), eventos e artefatos do framework Scrum.
  • 🔹 Aplicar os princípios de fluxo puxado, visibilidade e limites de trabalho em progresso (WIP) do método Kanban.
  • 🔹 Implementar práticas de engenharia de software do Extreme Programming (XP), incluindo Test-Driven Development (TDD) e Refatoração contínua.

🏢 2. Cenário Corporativo & Estudo de Caso (TecProExpress)

Na TecProExpress, a diretoria precisa lançar o novo portal de Autoatendimento e Rastreamento de Encomendas em apenas 8 semanas para atender à demanda da Black Friday. O modelo tradicional em cascata levaria 6 meses apenas na fase de especificação.

O Desafio: Sua equipe foi organizada em um Squad Ágil Multidisciplinar. Você aplicará Scrum para a governança de entregas em Sprints quinzenais, Kanban para controlar o fluxo de tarefas no board e práticas de XP (TDD com Pytest) para garantir código sustentável e sem regressões.


🧠 3. Fundamentação Teórica & Modelos Visuais

3.1. Os 4 Valores do Manifesto Ágil (2001)

Em 2001, 17 líderes de software reuniram-se em Utah e sintetizaram os pilares da agilidade:

flowchart TD
    subgraph MANIFESTO ["OS 4 VALORES DO MANIFESTO ÁGIL"]
        V1["👥 Indivíduos e interações<br>MAIS QUE processos e ferramentas"]
        V2["💻 Software em funcionamento<br>MAIS QUE documentação abrangente"]
        V3["🤝 Colaboração com o cliente<br>MAIS QUE negociação de contratos"]
        V4["🔄 Responder a mudanças<br>MAIS QUE seguir um plano rígido"]
    end
    
    style MANIFESTO fill:#f0fdf4,stroke:#16a34a
    style V1 fill:#dcfce7,stroke:#15803d
    style V2 fill:#dcfce7,stroke:#15803d
    style V3 fill:#dcfce7,stroke:#15803d
    style V4 fill:#dcfce7,stroke:#15803d

3.2. Ciclo de Vida do Scrum

O Scrum estrutura o desenvolvimento em iterações curtas chamadas Sprints (1 a 4 semanas), gerando um incremento de produto potencialmente publicável:

flowchart LR
    PB["📋 Product Backlog<br>(Priorizado pelo PO)"] --> SP["🎯 Sprint Planning<br>(Seleção do Time)"]
    SP --> SB["📝 Sprint Backlog"]
    SB --> SPRINT["🏃 Sprint (2 Semanas)<br>Daily Scrum (15 min)"]
    SPRINT --> INC["🚀 Incremento de Produto<br>(Definition of Done)"]
    INC --> REV["🔍 Sprint Review<br>(Feedback do Cliente)"]
    REV --> RET["💡 Retrospectiva<br>(Melhoria Contínua)"]
    RET --> SP
    
    style PB fill:#e0f2fe,stroke:#0284c7
    style SP fill:#ede7f6,stroke:#5e35b1
    style SPRINT fill:#fef3c7,stroke:#d97706
    style INC fill:#dcfce7,stroke:#16a34a
    style REV fill:#fce4ec,stroke:#c2185b
    style RET fill:#f3e5f5,stroke:#7b1fa2

3.3. Kanban e Limites de WIP (Work in Progress)

O Kanban foca em otimizar o fluxo de entrega visualizando o trabalho e limitando o número de tarefas simultâneas:

flowchart LR
    subgraph KANBAN ["QUADRO KANBAN COM LIMITES DE WIP"]
        direction LR
        B["Backlog<br>(Sem limite)"] --> A["A Fazer<br>(WIP: 5)"]
        A --> DEV["Em Dev<br>(WIP: 3)"]
        DEV --> TEST["Em Testes<br>(WIP: 2)"]
        TEST --> DONE["Concluído<br>(Done)"]
    end
    style KANBAN fill:#f8fafc,stroke:#64748b
    style DEV fill:#fee2e2,stroke:#ef4444
    style TEST fill:#fef3c7,stroke:#d97706
    style DONE fill:#dcfce7,stroke:#16a34a

💻 4. Aplicação Prática & Código Executável (Python 3.11+)

Implementação do ciclo TDD (Test-Driven Development) do Extreme Programming (Red ➔ Green ➔ Refactor).

📋 Pré-requisitos e Instalação

No terminal do seu ambiente virtual, instale o executor de testes Pytest:

pip install pytest

💻 Código Completo e Autocontido (calculador_frete_tdd.py)

Crie o arquivo calculador_frete_tdd.py e insira o código abaixo integralmente:

"""
Módulo: calculador_frete_tdd.py
Prática XP: Desenvolvimento guiado por testes com Pytest.
Stack: Python 3.11+ | Pytest
"""
from decimal import Decimal
import pytest

# --- PASSO 1: RED -> GREEN (Implementação que atende a especificação) ---
def calcular_taxa_urgencia(peso_kg: Decimal, expressa: bool) -> Decimal:
    """Calcula taxa adicional para fretes prioritários."""
    if peso_kg <= Decimal("0.0"):
        raise ValueError("O peso deve ser maior que zero.")

    taxa_base = peso_kg * Decimal("5.00")
    if expressa:
        return taxa_base * Decimal("1.50")
    return taxa_base

# --- SUÍTE DE TESTES UNITÁRIOS COM PYTEST ---
def test_frete_convencional():
    resultado = calcular_taxa_urgencia(peso_kg=Decimal("2.0"), expressa=False)
    assert resultado == Decimal("10.00")

def test_frete_expresso_com_adicional():
    resultado = calcular_taxa_urgencia(peso_kg=Decimal("2.0"), expressa=True)
    assert resultado == Decimal("15.00")

def test_peso_invalido_deve_lancar_excecao():
    with pytest.raises(ValueError, match="maior que zero"):
        calcular_taxa_urgencia(peso_kg=Decimal("-1.0"), expressa=True)

if __name__ == "__main__":
    print("🚀 Executando lógica de frete demonstrativa:")
    val = calcular_taxa_urgencia(Decimal("4.0"), True)
    print(f"Taxa calculada: R$ {val:.2f}")

    print("\n🧪 Disparando suíte automatizada do Pytest:")
    pytest.main(["-v", __file__])

🚀 Como Executar

Você pode executar diretamente com o interpretador Python ou através do runner do Pytest:

# Execução direta com Python (dispara a lógica e a suíte interna)
python calculador_frete_tdd.py

# Ou execução formal pelo CLI do Pytest
pytest -v calculador_frete_tdd.py

🖥️ Saída Esperada no Terminal

🚀 Executando lógica de frete demonstrativa:
Taxa calculada: R$ 30.00

🧪 Disparando suíte automatizada do Pytest:
============================= test session starts =============================
calculador_frete_tdd.py::test_frete_convencional PASSED                  [ 33%]
calculador_frete_tdd.py::test_frete_expresso_com_adicional PASSED        [ 66%]
calculador_frete_tdd.py::test_peso_invalido_deve_lancar_excecao PASSED   [100%]
============================== 3 passed in 0.05s ==============================

💡 5. Checkpoint de Engenharia & Boas Práticas

Boas Práticas & Anti-Patterns

  • Definition of Done (DoD): Uma história de usuário só está pronta quando o código foi revisado (Code Review), os testes automatizados passaram no CI e a documentação técnica foi atualizada.
  • Anti-Pattern Zombie Scrum: Realizar as reuniões (Daily, Review) de forma mecânica sem de fato empoderar o time para tomar decisões ou adaptar o plano de release.

🔗 6. Conexão com os Projetos Integradores

Projeto IntegradorComo o conceito deste capítulo é aplicado no PI
PI-04: ShopFlowOrganização das User Stories do checkout no backlog do produto e entrega em 2 marcos.
PI-06: ServiceFlowAplicação de quadro Kanban para acompanhar o fluxo de atendimento das ordens de serviço.

🧪 7. Quiz de Fixação e Autoavaliação (Formative Assessment)

🧪 Quiz de Autoavaliação — Capítulo 04

1. Qual é a responsabilidade central do papel de Product Owner (PO) no framework Scrum?

  • A) Definir a arquitetura técnica de microsserviços e o banco de dados.
  • B) Maximizar o valor do produto e gerenciar ativamente o Product Backlog priorizado.
  • C) Conduzir diariamente as reuniões de 15 minutos e remover impedimentos operacionais.
  • D) Escrever os testes unitários da aplicação.
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: O Product Owner é o responsável por representar os stakeholders, definir a visão do produto e garantir que o backlog esteja priorizado pelo maior valor de negócio.


2. No método Kanban, por que é fundamental estabelecer limites de Trabalho em Progresso (WIP - Work in Progress)?

  • A) Para impedir que os desenvolvedores façam pausas durante o dia.
  • B) Para evitar gargalos, reduzir a sobrecarga e acelerar o tempo de ciclo (Lead Time) das entregas.
  • C) Para forçar a contratação de novos gerentes de projeto.
  • D) Para desativar a esteira de integração contínua (CI).
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: Limitar o WIP força a equipe a terminar tarefas em andamento antes de iniciar novas ("Pare de começar, comece a terminar"), reduzindo gargalos e melhorando a previsibilidade do fluxo.


3. Qual é a sequência correta do ciclo TDD (Test-Driven Development) preconizado pelo Extreme Programming (XP)?

  • A) Refactor ➔ Green ➔ Red
  • B) Red (Escrever teste que falha) ➔ Green (Escrever código mínimo para passar) ➔ Refactor (Melhorar o design do código)
  • C) Deploy ➔ Teste Manual ➔ Correção de Bugs
  • D) Documentação ➔ Compilação ➔ Teste de Carga
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: O ciclo clássico do TDD é Red-Green-Refactor: primeiro escreve-se o teste que falha, implementa-se a solução mais simples para torná-lo verde e, por fim, refatora-se o código mantendo os testes passando.


🛠️ 8. Ponte para a Ação: Laboratório Prático

🎯 Próximo Passo Prático

Coloque esta teoria em prática executando o roteiro de laboratório autoguiado:
👉 ATIVIDADE 04: USER STORIES E BACKLOG


📌 9. Resumo Executivo & Key Takeaways

  • Manifesto Ágil: Valoriza pessoas, software funcional, colaboração e resposta a mudanças acima de planos inflexíveis.
  • Scrum: Framework iterativo-incremental baseado em papéis (PO, SM, Devs), eventos (Planning, Daily, Review, Retrospective) e artefatos.
  • Kanban: Gestão visual do fluxo de trabalho com limites explícitos de WIP para evitar sobrecarga e eliminar gargalos.
  • XP & TDD: Excelência técnica com testes automatizados escritos antes do código de produção (Red-Green-Refactor).