Guia Extra: Engenharia de Software e Modelagem UML • Bloco 1: Processo de Software

🗺️ Mapa Conceitual do Capítulo

flowchart TD
    MAN["Manifesto Ágil (2001)\n4 Valores Fundamentais · 12 Princípios"] --> MET["Abordagens Ágeis Complementares"]
    
    MET --> SCR["Scrum (Ken Schwaber & Jeff Sutherland)\nGestão Iterativa em Sprints de 1 a 4 semanas"]
    MET --> KAN["Kanban (David J. Anderson)\nGestão de Fluxo Contínuo e Limites de WIP"]
    MET --> XP["Extreme Programming - XP (Kent Beck)\nExcelência em Práticas Técnicas de Engenharia"]

    subgraph SCRUM_CORE["Estrutura Canônica do Scrum (Guia 2020)"]
        S_RESP["3 Responsabilidades: PO · Scrum Master · Developers"]
        S_EVEN["5 Eventos: Sprint · Planning · Daily · Review · Retrospective"]
        S_ARTE["3 Artefatos & Compromissos: Backlog (Meta) · Sprint Backlog (Meta) · Incremento (DoD)"]
        S_RESP --- S_EVEN --- S_ARTE
    end
    SCR --> SCRUM_CORE

    subgraph KANBAN_CORE["Métricas de Eficiência de Fluxo"]
        K_METR["Lead Time (Visão do Cliente) · Cycle Time (Visão Técnica) · CFD"]
        K_LEI["Lei de Little: WIP = Throughput × Lead Time"]
        K_METR --- K_LEI
    end
    KAN --> KANBAN_CORE

    subgraph XP_CORE["Práticas Técnicas do XP"]
        X_PRAT["TDD · Programação em Par · Integração Contínua · Refatoração"]
    end
    XP --> XP_CORE

    style MAN fill:#ede7f6,stroke:#512da8,stroke-width:2px
    style MET fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style SCR fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
    style KAN fill:#fff3e0,stroke:#ff9800,stroke-width:2px
    style XP fill:#fce4ec,stroke:#e91e63,stroke-width:2px

📜 1. O Manifesto Ágil (2001) e sua Filosofia

Em fevereiro de 2001, no resort The Lodge at Snowbird, em Utah, 17 líderes e pensadores do desenvolvimento de software (incluindo Kent Beck, Martin Fowler, Robert C. Martin, Jeff Sutherland e Ken Schwaber) redigiram o Manifesto para o Desenvolvimento Ágil de Software.

O Manifesto não propôs a abolição da disciplina ou da documentação, mas sim uma mudança profunda de prioridades através de quatro pilares axiomáticos:

Valorizamos Mais… (Esquerda) …Do Que (Direita) Justificativa Arquitetural e de Negócio
Indivíduos e interações Processos e ferramentas Ferramentas sofisticadas não salvam equipes com comunicação fragmentada.
Software em funcionamento Documentação abrangente A única medida real de progresso técnico é código executável entregando valor.
Colaboração com o cliente Negociação de contratos Contratos rígidos incentivam disputas jurídicas; parcerias geram produtos melhores.
Responder a mudanças Seguir um plano cego Em mercados dinâmicos, a capacidade de pivotar supera planos feitos com dados incertos.

🎯 Princípio Vital: “Mesmo havendo valor nos itens da direita, valorizamos mais os itens da esquerda.” O manifesto nunca disse “não faça documentação”, e sim que a documentação deve ser enxuta e a serviço do produto.

🔁 2. Scrum: O Framework de Gestão Empírica

O Scrum é um framework deliberadamente incompleto fundado no Empirismo (o conhecimento vem da experiência e as decisões são tomadas com base no que é observado) e no pensamento Lean (redução de desperdícios). Ele se sustenta em três pilares: Transparência, Inspeção e Adaptação.

Conforme o Scrum Guide oficial (versão 2020), a estrutura é composta rigorosamente por:

As 3 Responsabilidades (Papéis)

  1. Product Owner (PO): Responsável por maximizar o valor do produto resultante do trabalho do time. É o único proprietário do Product Backlog, definindo prioridades de negócio.
  2. Scrum Master (SM): Líder servidor que garante que o time compreenda e aplique o Scrum. Remove impedimentos organizacionais e protege o time de interferências externas.
  3. Developers (Desenvolvedores): Profissionais multidisciplinares comprometidos em criar qualquer aspecto de um Incremento utilizável a cada Sprint.

Os 3 Artefatos e Seus Respectivos Compromissos

Para manter foco e transparência absoluta, cada artefato possui um compromisso explícito associado:

Artefato Scrum Compromisso Associado Definição do Compromisso
Product Backlog Meta do Produto (Product Goal) O estado futuro do produto que serve como alvo de longo prazo para a equipe.
Sprint Backlog Meta da Sprint (Sprint Goal) O objetivo único e negociável a ser alcançado durante a iteração corrente.
Incremento Definição de Pronto (Definition of Done - DoD) Lista formal e compartilhada de critérios de qualidade que o código deve cumprir.

Os 5 Eventos Formais (Time-boxed)

  • Sprint: O container para todos os outros eventos (duração fixa de 1 a 4 semanas).
  • Sprint Planning: O time define Por que a Sprint é valiosa, O que pode ser feito e Como o trabalho será executado.
  • Daily Scrum: Reunião diária de 15 minutos para os desenvolvedores inspecionarem o progresso rumo à Meta da Sprint.
  • Sprint Review: Sessão de demonstração do incremento funcional aos stakeholders para coleta de feedback.
  • Sprint Retrospective: Reunião interna do time para inspecionar pessoas, processos e ferramentas, planejando melhorias contínuas.

📋 3. Kanban: Gestão de Fluxo Contínuo e a Lei de Little

Originado no Sistema Toyota de Produção e adaptado para o trabalho do conhecimento por David J. Anderson, o Kanban não trabalha com caixas de tempo (time-boxes) ou iterações fixas, mas com Fluxo Contínuo:

graph LR
    B["Backlog"] --> A["Análise (WIP: 2)"] --> D["Desenvolvimento (WIP: 3)"] --> T["Testes (WIP: 2)"] --> P["Pronto (Deploy)"]

Princípios Fundamentais do Kanban

  1. Visualizar o Fluxo de Valor: Mapear todas as etapas reais em um quadro visível.
  2. Limitar o Trabalho em Progresso (WIP Limits): O princípio central é “Pare de começar e comece a terminar”. Limitar a quantidade de tarefas simultâneas em cada coluna evita a sobrecarga cognitiva da alternância de contexto (context switching).
  3. Métricas de Fluxo:
    • Lead Time: Tempo total decorrido desde a solicitação do cliente até a entrega final em produção.
    • Cycle Time: Tempo decorrido desde o momento em que a equipe começa ativamente a trabalhar no item até sua conclusão.
    • Throughput (Vazão): Quantidade de itens de trabalho entregues por unidade de tempo (ex: 8 histórias por semana).

📐 A Lei de Little Aplicada ao Software: \(\text{Lead Time Médio} = \frac{\text{Trabalho em Progresso (WIP)}}{\text{Throughput (Vazão)}}\) A matemática prova que, mantendo a vazão da equipe constante, a única maneira sustentável de reduzir o tempo de entrega aos clientes é diminuir o limite de WIP.

🛠️ 4. Extreme Programming (XP): Engenharia de Alta Disciplina

Enquanto o Scrum foca na gestão do projeto, o XP (Extreme Programming), concebido por Kent Beck, foca nas práticas técnicas de engenharia de software que tornam as mudanças de código baratas e seguras:

  1. Desenvolvimento Guiado por Testes (TDD): Escrever o teste unitário automatizado que falha antes de escrever a linha de código de produção.
  2. Programação em Par (Pair Programming): Dois engenheiros trabalham no mesmo código (Piloto e Copiloto), garantindo revisão contínua e disseminação de conhecimento.
  3. Refatoração Contínua: Melhorar a estrutura interna do código sem alterar seu comportamento observável, eliminando dívida técnica precocemente.
  4. Integração Contínua (CI): Integrar e testar o código na branch principal múltiplas vezes ao dia.
  5. Design Simples: Implementar a solução mais simples que faça os testes passarem, sem abstrações especulativas prévias (YAGNI - You Aren’t Gonna Need It).