Cheatsheet — Guia Ágil
Decisão: qual ciclo de vida escolher?
| Incerteza de requisitos | Incerteza técnica | Ciclo de vida indicado |
|---|
| Baixa | Baixa | Preditivo |
| Alta | Baixa | Iterativo |
| Baixa | Alta | Incremental |
| Alta | Alta | Ágil |
| Mistura (só parte do projeto é incerta) | — | Híbrido — isole a parte incerta como ilha ágil dentro de um projeto preditivo, ou vice-versa |
Decisão: iteração ou fluxo?
- Cadência de trabalho estável, time quer pontos fixos de planejamento/revisão → ágil baseado em iteração (Scrum-like).
- Fluxo de trabalho irregular, chegada imprevisível de itens → ágil baseado em fluxo (Kanban), gerenciando WIP em vez de timebox.
Regras de decisão (if/then)
- Se a organização não consegue entregar valor intermediário → então ágil pode não ajudar; não force por rótulo.
- Se o time nunca praticou a abordagem "de manual" com sucesso → então não faça tailoring ainda (nível Shu antes de Ha).
- Se for remover uma prática ágil → então primeiro identifique o que ela contrabalança.
- Se o refinamento de backlog passar de ~1h/semana → então o dono do produto está sobre-preparando ou falta habilidade crítica no time.
- Se o standup virar reunião de status → então troque o facilitador (não deve ser o líder/PM) e mande problemas pro parking lot.
- Se houver membros com dedicação parcial (<100%) → então trate como risco explícito de projeto (perda de 20-40% de produtividade por troca de contexto).
- Se o time tem pouca experiência técnica → então não basta declarar "somos ágeis agora" — direcione ativamente até ganharem habilidade.
- Se ágil já falhou numa única equipe → então não escale; resolva os impedimentos organizacionais primeiro.
Thresholds & defaults citados no guia
| Métrica | Valor de referência |
|---|
| Tamanho de equipe ágil eficaz | 3–9 pessoas |
| Duração de sprint (Scrum) | ≤ 1 mês |
| Timebox de standup | ≤ 15 min |
| Cadência mínima de demo | pelo menos a cada 2 semanas |
| Refinamento de backlog | ≤ ~1h/semana |
| Iterações até velocidade estável | 4 a 8 |
| Perda de produtividade por troca de tarefa | 20–40% por troca |
| Meta de refinamento por dia (referência) | pelo menos 1 história completável/dia |
Tells & smells (heurísticas de reconhecimento rápido)
- Projeto "melancia" (verde por fora, vermelho por dentro) → confiar em "% pronto" em vez de medida empírica.
- Minicascata dentro da iteração → time faz todos os requisitos, depois todo design, depois toda construção, em vez de fatiar por funcionalidade.
- "Retrospectivas foram impopulares, então abandonamos" → sintoma de problema mais fundamental no time, não motivo válido pra cortar a prática.
- Silos com métricas de eficiência individual → sinal de que a organização ainda não está pronta pra equipes multifuncionais reais.
- EGP que exige uniformidade pra "ganhos rápidos" → orientado a mandato, não a convite; tende a não pegar.
Trade-off: técnicas de contratação ágil
| Técnica | Protege mais |
|---|
| Preço fixo por incremento | Cliente (risco financeiro previsível) |
| T&M com teto | Cliente (flexibilidade de escopo, orçamento travado) |
| T&M gradativo (bônus/multa por prazo) | Ambos (risco compartilhado) |
| Opção de cancelamento antecipado | Cliente (sai sem pagar o resto se não precisar) |
| Aumento de equipe (fornecedor incorporado) | Colaboração máxima, menor rigidez de escopo |
Diagnóstico rápido de adequação ágil (3 eixos, ver Cap 12)
Cultura (aceitação + confiança + autonomia) + Equipe (tamanho + experiência + acesso ao cliente) + Projeto (mudança + criticidade + viabilidade incremental) → agrupado no centro = ágil, espalhado nas bordas = preditivo, misto = híbrido. Critério de desempate: consenso das partes interessadas sempre pode sobrepor o resultado numérico.