⚡ 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
- 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 Integrador | Como o conceito deste capítulo é aplicado no PI |
|---|---|
| PI-04: ShopFlow | Organização das User Stories do checkout no backlog do produto e entrega em 2 marcos. |
| PI-06: ServiceFlow | Aplicaçã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
🧪 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
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).