Capítulo 5: Implementando Ágil — Entregando em um Ambiente Ágil

Core Idea

Entregar em ágil é um ciclo contínuo de "planejar um pouco → entregar → aprender → replanejar", sustentado por um pequeno conjunto de práticas recorrentes (retrospectiva, refinamento de backlog, standup, demo) e medido com métricas empíricas (o que foi de fato entregue), não preditivas (o que se planejou entregar).

Frameworks Introduzidos

Termo de abertura ágil + termo de nomeação da equipe: o termo de abertura responde "por que estamos fazendo isso", "quem se beneficia", "o que significa 'pronto'" e "como vamos trabalhar juntos"; o termo de nomeação da equipe é o "contrato social" — valores, ritmo sustentável, definição de "preparado"/"pronto", regras básicas de reunião.
- Quando usar: no início de qualquer projeto ágil, mesmo sem processo formal — o mínimo indispensável é a visão do projeto e acordos de trabalho explícitos.
8 práticas ágeis comuns: retrospectiva, preparação de backlog (roadmap), refinamento de backlog, reunião diária em pé, demonstração/revisão, planejamento de iteração, práticas técnicas de execução (XP), e o ciclo iteração→incremento.
- Como usar cada uma: retrospectiva reflete sobre processo (não é sobre culpa); refinamento prepara histórias com antecedência suficiente pra próxima iteração (não mais que ~1h/semana); standup detecta impedimentos (não resolve); demo entrega feedback real sobre o produto.
Medição empírica vs. preditiva: mede-se o que a equipe entregou (funcionalidades concluídas), não o que ela previu entregar (% pronto). Ferramentas: velocidade (pontos de história por iteração), burndown/burnup, lead time/tempo de ciclo/tempo de resposta (fluxo), diagrama de fluxo cumulativo (WIP acumulado).
- Quando usar cada métrica: velocidade e burndown/burnup servem ágil baseado em iteração; lead time/tempo de ciclo servem ágil baseado em fluxo; diagrama de fluxo cumulativo detecta acúmulo de trabalho em qualquer um dos dois.

Key Concepts

Reunião diária em pé (standup): timebox de até 15 min; baseada em iteração usa 3 perguntas em rodízio (o que concluí / o que vou concluir / quais impedimentos); baseada em fluxo lê o quadro da direita pra esquerda perguntando o que precisa avançar.
Definição de Preparado (DoR) e Definição de Pronto (DoD): critérios explícitos de quando uma história está pronta pra entrar na iteração (DoR) e de quando está de fato concluída (DoD) — reduzem ambiguidade de "trabalho concluído" que não está de fato concluído.
Spike: pesquisa ou experimento em timebox, usado pra aprender algo crítico (técnico ou funcional) antes de comprometer a equipe com uma estimativa.
Projeto "melancia": status reportado como verde por fora (ex. "90% pronto") mas vermelho por dentro — sintoma clássico de medição preditiva que não reflete a realidade até ser tarde demais.
Velocidade: soma dos pontos de história de funcionalidades de fato concluídas numa iteração — usada pra prever capacidade futura, não comparável entre equipes diferentes (cada equipe tem sua própria unidade de medida).
Lead time / Tempo de ciclo / Tempo de resposta: lead time = do momento em que o item entra no quadro até a entrega; tempo de ciclo = do início do trabalho até a conclusão; tempo de resposta = do momento "preparado" até o início do trabalho — métricas centrais em fluxo, onde não há iteração fixa.
Diagrama de fluxo cumulativo: visualiza o WIP acumulado por etapa do fluxo (fila, análise, dev, teste, implantação) — uma faixa que engorda sinaliza gargalo.
IDP/IDC em contexto ágil: métricas de valor agregado tradicionais (índice de desempenho de prazo / de custo) podem ser recalculadas com pontos de história — ex. planejou 30, entregou 25 → IDP = 25/30 = 0,83.

Mental Models

"Percentual pronto" é uma medida de substituição, não de valor — prefira sempre medidas empíricas (funcionalidade de fato concluída) a estimativas de progresso.
Retrospectiva não é sobre apontar culpados — é sobre coletar dados qualitativos (sentimento) e quantitativos (medição), achar causa-raiz, e limitar as melhorias escolhidas à capacidade real da equipe de executá-las na próxima iteração (menos itens concluídos com sucesso > muitos itens abandonados pela metade).
A equipe planeja pouco de cada vez, de propósito — não é imaturidade de planejamento, é reconhecimento de que aprendizagem é parte do trabalho, e granularidade pequena reduz o custo de errar.

Anti-patterns

Standup virar reunião de status: sintoma comum em equipes vindas de ambiente preditivo — a correção é deixar qualquer membro (não o líder/PM) facilitar, e mandar problemas pra um "parking lot" resolvido depois, não durante o standup.
Medir só pontos de história, não funcionalidades concluídas: viola o princípio "a principal medida de progresso é o produto funcionando" — pontos de história medem capacidade, não valor entregue.
Excesso de refinamento de backlog: se passar de ~1h/semana, é sinal de que o dono do produto está sobre-preparando ou a equipe tem lacuna de habilidade crítica pra avaliar/refinar trabalho — não é "cuidado extra", é desperdício de tempo que devia ir pra execução.
Tentar resolver todos os problemas de uma retrospectiva ao mesmo tempo: capturar mais itens de melhoria do que a equipe consegue executar na próxima iteração é pior que escolher poucos e concluir todos.

Worked Example

A Tabela de Problemas Críticos e Soluções do capítulo mapeia sintomas comuns a intervenções concretas — por exemplo: "requisitos pouco claros" → construir um roteiro de produto com especificação por exemplo/mapeamento de história/mapeamento de impacto, decompondo progressivamente em itens menores de backlog; "estimativa imprecisa" → reduzir o tamanho da história, estimar com estimativa relativa em grupo, usar spikes pra entender a história; "débito técnico" → refatoração, modelagem ágil, teste ubíquo, análise automatizada de qualidade e uma Definição de Pronto sólida. O padrão por trás de todas as linhas da tabela: cada problema tem uma raiz estrutural (falta de clareza, falta de fatiamento, falta de definição explícita de "pronto") — a solução quase sempre é tornar algo implícito em explícito, e reduzir o tamanho do lote de trabalho.

Key Takeaways

As 8 práticas comuns (retro, backlog roadmap, refinamento, standup, demo, planejamento de iteração, práticas técnicas XP, ciclo iteração/incremento) não são um pacote obrigatório — mas cada uma resolve um problema específico e recorrente, então descartar uma sem substituto costuma reintroduzir o problema que ela resolvia.
Escolha as métricas pelo tipo de ágil: velocidade/burndown/burnup pra baseado em iteração, lead time/tempo de ciclo/fluxo cumulativo pra baseado em fluxo.
Nunca confie em "% pronto" reportado — ele mascara a realidade até estar perto demais do prazo pra reagir (o padrão "melancia").
Práticas técnicas (integração contínua, testes em todos os níveis, ATDD/TDD/BDD, spikes) não são luxo de time maduro — são o que sustenta a velocidade de entrega no médio prazo; negligenciá-las cobra retrabalho depois.
Todo problema recorrente de execução ágil (requisitos vagos, estimativa ruim, débito técnico, silos) tem um padrão de solução conhecido — antes de inventar uma solução nova, verifique se não é um dos casos já mapeados no capítulo.

Connects To

Cap 4: a equipe e a liderança servidora formadas lá são quem executa as práticas descritas aqui.
Cap 2: o princípio "software funcionando é a principal medida de progresso" (citado no Cap 2) é a base de por que medidas empíricas > medidas preditivas.
Cap 12 / Apêndice X3: ferramentas de roadmap e mapeamento de impacto citadas na preparação de backlog.