Capítulo 3: Seleção do Ciclo de Vida

Core Idea

Existem 4 categorias de ciclo de vida (preditivo, iterativo, incremental, ágil) posicionadas num continuum, não em caixas isoladas — a maioria dos projetos reais acaba usando alguma combinação híbrida delas, e a escolha certa depende do quanto o projeto precisa de feedback frequente (→ iterações) e de valor entregue cedo (→ incrementos), não de preferência metodológica.

Frameworks Introduzidos

As 4 categorias de ciclo de vida: preditivo (planejamento no início, execução sequencial única, requisitos fixos, objetivo = gerenciar custo), iterativo (repete atividades até "estar correto", entrega única no fim, objetivo = corrigir a solução), incremental (entregas menores e frequentes, objetivo = velocidade), ágil (iterativo + incremental combinados, objetivo = valor do cliente via entregas e feedback frequentes).
- Como usar: plote o projeto no continuum perguntando duas coisas — quanto de feedback sobre trabalho inacabado eu preciso (empurra pra iterativo) e quanto preciso entregar valor utilizável cedo e com frequência (empurra pra incremental). Ágil puro é quando as duas respostas são "muito".
Continuum bidimensional (frequência de entrega × grau de mudança): em vez de tratar os 4 tipos como categorias discretas, o guia os posiciona num gráfico — preditivo no canto de baixo grau de mudança/baixa frequência de entrega, ágil no canto oposto, iterativo e incremental nos eixos intermediários.
4 padrões de combinação híbrida: (1) desenvolvimento ágil seguido de implantação preditiva (uma fase depois da outra); (2) ágil e preditivo simultâneos ao longo de todo o ciclo (mesma equipe/projeto, mistura de práticas o tempo todo); (3) predominantemente preditivo com um componente ágil isolado (só a parte de maior incerteza vira ágil); (4) predominantemente ágil com um componente preditivo isolado (só um elemento não-negociável, tipo integração de fornecedor externo, fica preditivo).
- Quando usar cada um: o padrão 1 serve quando a fase de execução é repetitiva e bem conhecida depois de um desenvolvimento incerto; o padrão 3 serve quando só um pedaço específico do projeto tem a incerteza que justificaria ágil; o padrão 4 serve quando um elemento externo é literalmente impossível de tratar de forma incremental (ex. uma entrega única de um fornecedor).
Transição híbrida como estratégia (não só como resultado acidental): times que não conseguem virar ágeis da noite pro dia devem adicionar técnicas iterativas primeiro (aprendizagem/alinhamento), testar num projeto de risco baixo/médio, e só depois acrescentar técnicas incrementais e escalar pra projetos mais complexos.

Key Concepts

Preditivo: termo escolhido pelo guia (em vez de "cascata", "serial" ou "orientado por plano") por já ser usado no Guia PMBOK® e sua Extensão de Software.
Ágil baseado em iteração vs. ágil baseado em fluxo: no baseado em iteração, o time trabalha em janelas de tempo (timeboxes) de duração fixa e entrega um conjunto de funcionalidades por iteração; no baseado em fluxo, o time puxa itens do backlog conforme capacidade disponível (não por cronograma fixo), controlando o trabalho em andamento (WIP) por coluna do quadro, sem pontos fixos de planejamento/revisão.
WIP (trabalho em andamento): limitado deliberadamente no fluxo pra identificar problemas mais cedo e reduzir retrabalho.
Tailoring: adaptar uma abordagem (ou combinação delas) aos atributos específicos do projeto — tratado aqui como prática normal e esperada, não exceção.

Mental Models

A pergunta certa não é "ágil ou preditivo?", é "como somos mais bem-sucedidos aqui?" — se a organização não consegue entregar valor intermediário, ágil pode simplesmente não ajudar, e está tudo bem.
Todo ciclo de vida tem planejamento — a diferença é quanto e quando. Preditivo planeja o máximo possível no início; ágil planeja e replaneja continuamente conforme mais informação chega pelas entregas.
Combinar frameworks é a norma, não a exceção: o exemplo mais citado é Scrum (cadência, papéis, eventos) + Método Kanban (visualização de fluxo, limite de WIP) + práticas de engenharia inspiradas em XP (integração contínua, testes automatizados, refatoração) — cada peça resolve um problema diferente, e a combinação supera qualquer uma isolada.

Anti-patterns

Chamar de "ágil" um projeto que só usa algumas cerimônias (daily, retro) mas mantém estimativa/atribuição/acompanhamento 100% preditivos — o guia é explícito: isso não é ágil (não incorpora a mentalidade plenamente) nem é preditivo — é híbrido, e deveria ser chamado assim.
Adotar ágil "porque sim" quando a organização não tem como entregar valor intermediário — nesse caso o ágil não ajuda; forçar a abordagem gera atrito sem ganho real.

Worked Example

Uma farmacêutica tinha estudos clínicos conduzidos com abordagens ágeis, mas precisava submeter o medicamento a um processo de aprovação regulatória (FDA) que só podia ser executado como fase separada no final — qualquer mudança, por menor que fosse, exigia repetir a aprovação inteira. Tentativas de integrar a aprovação de forma iterativa falharam; a solução viável foi manter a aprovação como fase preditiva isolada no fim do ciclo de vida (padrão híbrido "ágil seguido de preditivo"), mas com guias de início rápido e protocolos de teste preparados antecipadamente pra encurtar essa fase final. A lição: quando uma restrição externa (regulatória, contratual) é rígida e não-fracionável, não tente forçá-la a virar iterativa — isole-a como fase preditiva e otimize só o que dá pra otimizar dentro dela.

Key Takeaways

Pense em ciclo de vida como um continuum de duas dimensões (frequência de entrega × grau de mudança), não como 4 caixas fechadas.
A maioria dos projetos reais é híbrida — os 4 padrões de combinação (agil→preditivo em sequência, simultâneo misturado, agil com ilha preditiva, preditivo com ilha ágil) cobrem os casos mais comuns.
Ágil baseado em fluxo (Kanban) e ágil baseado em iteração (Scrum-like) não são a mesma coisa — a escolha depende de se o time tem cadência estável de trabalho (iteração) ou fluxo irregular com necessidade de gerenciar WIP (fluxo).
Transição pra ágil deve ser gradual e testada em projetos de risco baixo/médio antes de escalar — não é um interruptor binário.
Tailoring de framework é esperado — a Tabela de Fatores de Projeto (Cap 11 / Apêndice X2 tem mais detalhe) já mapeia sintomas comuns (fluxo interrompido, qualidade baixa, time sem experiência, múltiplas equipes) a opções concretas de ajuste.

Connects To

Cap 2: o Modelo de Incerteza e Complexidade explica POR QUE escolher um ponto do continuum; este capítulo explica COMO escolher.
Cap 11 / Apêndice X2: aprofunda os atributos que influenciam o tailoring, só resumidos aqui na Tabela 3-2.
Cap 12 / Apêndice X3: filtros de adequação ao ágil (modelos de avaliação), citados aqui de passagem.
Cap 4 e 5: assumem que o ciclo de vida já foi escolhido e tratam de como criar o ambiente e entregar dentro dele.