Agile vs. Desenvolvimento Tradicional de Software

radio_button_uncheckedshort_textObjetivo do capítulo

Ao final deste capítulo, você deverá ser capaz de comparar formas de trabalho orientadas por plano e formas Agile sem reduzir nenhuma delas a estereótipos; explicar com precisão o desenvolvimento preditivo, iterativo, incremental e adaptativo; e escolher uma abordagem com base na incerteza, no risco, nas necessidades de feedback e no contexto do produto.

radio_button_uncheckedshort_textIntrodução: a verdadeira pergunta não é "Agile ou Waterfall?"

A comparação útil não é entre moderno e antigo. É esta: quanto podemos saber antecipadamente, qual é o custo de estarmos errados e com que rapidez a realidade pode nos fornecer informações melhores?

As discussões sobre Agile versus desenvolvimento tradicional de software muitas vezes são reduzidas a uma disputa. Agile é descrito como flexível, rápido e moderno; o desenvolvimento tradicional é descrito como rígido, lento e obsoleto. Esse enquadramento é atraente por ser simples, mas oculta o verdadeiro problema de engenharia e gestão.

Diferentes tipos de trabalho apresentam diferentes níveis de incerteza. Alguns projetos podem ser planejados com alto grau de confiança porque requisitos, tecnologia, sequência e condições de aceitação são estáveis. Outros envolvem comportamento do cliente, resposta do mercado, tecnologia inédita ou prioridades de negócio em mudança, aspectos que não podem ser previstos com confiabilidade no início.

Abordagens tradicionais ou orientadas por plano se desenvolveram em ambientes nos quais coordenação, previsibilidade, clareza contratual, papéis especializados e controle de grandes pacotes de trabalho eram importantes. As abordagens Agile ganharam força porque equipes de software descobriram repetidamente que os planos podiam se tornar obsoletos muito antes da entrega, que os requisitos melhoravam depois que os usuários viam software funcionando e que integração e validação tardias geravam surpresas caras. Nenhuma dessas trajetórias históricas implica que planejar seja ruim ou que adaptar seja sempre superior. A questão relevante é saber se o ciclo de vida escolhido corresponde à natureza do trabalho.

Uma abordagem preditiva tenta compreender antecipadamente uma parcela substancial do escopo e da sequência e, em seguida, executar o trabalho com base nesse modelo, controlando desvios. Uma abordagem adaptativa pressupõe que conhecimentos importantes surgirão durante o trabalho e cria intencionalmente ciclos curtos nos quais os planos podem ser revistos. O desenvolvimento iterativo melhora uma solução por meio de ciclos repetidos. O desenvolvimento incremental acrescenta partes concluídas ao longo do tempo. Abordagens Agile normalmente combinam iteração e incrementos com feedback frequente, colaboração com o cliente e adaptação.

Essa distinção é importante para a PSM I porque o Scrum é explicitamente empírico. O Scrum Guide vigente afirma que o Scrum é fundamentado no empirismo e no Lean Thinking e que utiliza uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Portanto, o Scrum não rejeita a previsibilidade; ele busca previsibilidade por meio de evidências frequentes, e não pela suposição de que um plano detalhado de longo prazo permanecerá correto.

O objetivo deste capítulo é construir uma comparação útil para além da prova. Ao final, você deverá ser capaz de olhar para um produto ou projeto e formular perguntas melhores: quão estáveis são os requisitos? Quanto feedback conseguimos obter durante o desenvolvimento? Podemos entregar partes úteis antecipadamente? A tecnologia é bem compreendida? Qual é o custo da mudança? Que tipo de risco predomina - risco de execução ou risco de descoberta? As respostas valem mais do que qualquer rótulo.

radio_button_uncheckedshort_textQuatro termos que você precisa distinguir

Antes de comparar Agile e desenvolvimento tradicional, é essencial separar quatro termos que frequentemente são confundidos: preditivo, iterativo, incremental e adaptativo. Eles descrevem características diferentes de um ciclo de vida. Uma iniciativa real pode apresentar mais de uma dessas características ao mesmo tempo.

Preditivo

Definição: uma quantidade substancial do escopo, da sequência, da lógica de cronograma, das expectativas de custo e dos critérios de aceitação é definida antecipadamente. A execução é gerenciada em relação a uma linha de base, e as mudanças são avaliadas por meio de um processo de controle.

Quando costuma ser útil: é mais adequado quando o trabalho é bem compreendido, as dependências são estáveis e o custo da descoberta tardia é menor do que o custo de replanejamentos frequentes.

Iterativo

Definição: uma solução é revisitada repetidamente. Cada ciclo melhora, refina ou corrige o que foi aprendido em ciclos anteriores. Uma iteração não necessariamente produz uma versão utilizável para lançamento.

Quando costuma ser útil: é útil quando o problema é mais bem compreendido por meio de refinamento repetido - por exemplo, design de UX, algoritmos, protótipos, arquitetura e modelos.

Incremental

Definição: o produto final cresce por meio de adições concluídas. Cada incremento acrescenta capacidade, e alguns incrementos podem ser utilizáveis antes que toda a visão do produto esteja completa.

Quando costuma ser útil: é útil quando o valor pode ser decomposto em fatias que possam ser concluídas e validadas progressivamente.

Adaptativo

Definição: planos e prioridades são revistos intencionalmente à medida que surgem evidências. Abordagens adaptativas normalmente utilizam ciclos curtos de feedback, envolvimento contínuo de stakeholders e entrega frequente ou inspeção de incrementos.

Quando costuma ser útil: é útil quando requisitos, tecnologia, condições de mercado ou necessidades dos clientes são incertos ou provavelmente mudarão.

Distinção importante

Iterativo não significa automaticamente incremental. Incremental não significa automaticamente adaptativo. Abordagens Agile normalmente combinam iteração, incrementos, feedback rápido e adaptação - mas os termos não são intercambiáveis.

radio_button_uncheckedshort_textPreditivo vs. Adaptativo: duas formas diferentes de criar controle

O contraste mais forte está entre o pensamento preditivo e o adaptativo. Ambos procuram controle, mas o obtêm de maneiras diferentes. Sistemas preditivos tentam reduzir a incerteza antes da execução por meio de mais análise e planejamento. Sistemas adaptativos aceitam que parte da incerteza não pode ser eliminada antecipadamente e criam controle por meio de ciclos curtos de feedback, evidências transparentes e replanejamento frequente.

É por isso que a afirmação "Agile não tem planejamento" é incorreta. O planejamento existe em toda abordagem séria de entrega. O que muda é o quão longe o plano alcança, o nível de detalhe, a frequência de revisão e a autoridade que a organização concede a novas evidências para alterá-lo. A orientação publicada pelo PMI expressa a mesma ideia: todos os ciclos de vida incluem planejamento; a diferença está em quanto planejamento é realizado e em que momento.

radio_button_uncheckedshort_textAgile vs. Desenvolvimento Tradicional em Dez Dimensões

A comparação a seguir utiliza "tradicional" para se referir a uma abordagem predominantemente orientada por plano, preditiva e organizada por fases. Organizações reais variam, e muitos projetos tradicionais incluem iteração, protótipos, entregas em estágios ou feedback. Da mesma forma, muitas equipes que se dizem Agile ainda utilizam governança pesada, datas fixas, documentação e controles contratuais. O objetivo é comparar tendências, não caricaturas.

radio_button_uncheckedshort_text1. Planejamento

Tendência tradicional / preditiva. O desenvolvimento tradicional tende a investir mais intensamente em planejamento antecipado. Casos de negócio, linhas de base de requisitos, arquitetura, cronogramas, planos de alocação de pessoal, dependências, orçamentos e critérios de aceitação podem ser definidos antes do início da implementação. O benefício é a coordenação: quando o trabalho é estável, um plano detalhado pode revelar dependências e apoiar compromissos entre muitos grupos.

Tendência Agile / adaptativa. O planejamento Agile é contínuo e em camadas. Um produto ainda pode ter estratégia, roadmaps, previsões, orçamentos, expectativas de release e direcionamento arquitetural, mas os planos detalhados são intencionalmente mais precisos perto do presente e mais provisórios quanto mais distantes no futuro. No Scrum, uma Product Goal fornece direcionamento de prazo mais longo, o Sprint Planning estabelece um objetivo e um plano de curto prazo, e o Sprint Backlog é adaptado à medida que mais se aprende.

Ideia-chave

A diferença não é planejamento versus ausência de planejamento. É plano-como-linha-de-base versus plano-como-melhor-previsão-atual.

radio_button_uncheckedshort_text2. Escopo

Tendência tradicional / preditiva. Projetos preditivos frequentemente tratam o escopo como uma linha de base a ser protegida. O pressuposto é que definir o escopo antecipadamente melhora estimativas, contratação, alocação de pessoas e sequenciamento. Mudanças são possíveis, mas podem exigir análise formal de impacto, porque alterar uma parte da linha de base pode afetar custo, cronograma e compromissos.

Tendência Agile / adaptativa. O desenvolvimento de produtos Agile trata o escopo detalhado como algo mais emergente. Metas e resultados desejados podem permanecer estáveis enquanto as funcionalidades exatas utilizadas para alcançá-los mudam. Product Backlogs evoluem conforme se acumulam feedback de clientes, aprendizado técnico e evidências de mercado. Isso permite às equipes parar de construir ideias de baixo valor e investir em oportunidades recém-descobertas.

Ideia-chave

Metas estáveis não exigem escopo detalhado congelado.

radio_button_uncheckedshort_text3. Feedback

Tendência tradicional / preditiva. No desenvolvimento orientado por fases, o feedback muitas vezes é estruturado em torno de revisões, gates, fases de testes, etapas-piloto, testes de aceitação do usuário ou entrega final. Esses controles podem ser rigorosos, mas, se os intervalos forem longos, mal-entendidos podem persistir por meses antes de confrontarem usuários reais ou um sistema integrado.

Tendência Agile / adaptativa. Agile reduz a distância entre ação e evidência. Fatias de software funcionando, demonstrações, analytics, testes, pesquisa com usuários, Sprint Reviews e feedback de produção criam oportunidades repetidas para inspecionar tanto o produto quanto a direção. O objetivo não é coletar mais opiniões; é encontrar evidências relevantes mais cedo.

Ideia-chave

O custo do feedback normalmente é menor quando o trabalho a ser corrigido ainda é pequeno.

radio_button_uncheckedshort_text4. Entrega

Tendência tradicional / preditiva. Projetos tradicionais frequentemente se coordenam em torno de grandes releases, conclusão de fases ou uma entrega integrada final. Isso pode ser apropriado quando a entrega parcial tem pouco valor - por exemplo, quando uma instalação física inteira precisa estar concluída antes de poder operar.

Tendência Agile / adaptativa. Agile prefere incrementos menores e utilizáveis sempre que o produto permitir. A entrega incremental melhora fluxo de caixa, aprendizado, confiança dos stakeholders e visibilidade de riscos. Uma pequena capacidade pode ser lançada, medida e melhorada enquanto outras capacidades permanecem no Product Backlog.

Ideia-chave

A entrega incremental é valiosa porque cria opções, e não apenas porque gera velocidade.

radio_button_uncheckedshort_text5. Gestão de Mudanças

Tendência tradicional / preditiva. A gestão de mudanças preditiva protege a linha de base. Mudanças propostas são avaliadas quanto ao impacto, aprovadas ou rejeitadas, documentadas e integradas aos planos. Isso é valioso quando as mudanças trazem grandes consequências contratuais, de segurança, hardware, regulação ou dependências.

Tendência Agile / adaptativa. A gestão de mudanças adaptativa torna a mudança parte normal da tomada de decisão sobre o produto. Novas informações alteram a ordenação do Product Backlog, as previsões ou as escolhas de Sprints futuros. Isso não elimina a governança; muda o padrão de "proteger o plano original" para "proteger a meta e usar novas evidências para melhorar o caminho".

Ideia-chave

Agile acolhe mudanças úteis, não interrupções sem controle.

radio_button_uncheckedshort_text6. Participação do Cliente

Tendência tradicional / preditiva. A entrega tradicional pode depender fortemente do levantamento de requisitos no início e da aceitação formal mais tarde. O envolvimento do cliente pode se concentrar em fases específicas, especialmente quando contratos separam claramente as responsabilidades de fornecedor e comprador.

Tendência Agile / adaptativa. Agile favorece colaboração contínua. Clientes, usuários, Product Owners, stakeholders e especialistas de domínio permanecem conectados ao desenvolvimento para que perguntas e evidências possam alterar decisões enquanto ainda há tempo para agir. No Scrum, stakeholders são especialmente importantes na Sprint Review, enquanto o Product Owner gerencia continuamente o valor do produto e as decisões do backlog.

Ideia-chave

A colaboração com o cliente é um mecanismo de aprendizado, não um convite cerimonial para reuniões.

radio_button_uncheckedshort_text7. Organização da Equipe

Tendência tradicional / preditiva. Estruturas tradicionais frequentemente refletem especialização funcional: analistas definem, arquitetos projetam, Developers implementam, testadores verificam, operações implantam e gestores coordenam entre departamentos. A especialização pode produzir conhecimento profundo e padrões funcionais claros, mas handoffs podem criar filas e perda de informação.

Tendência Agile / adaptativa. Abordagens Agile tendem a favorecer equipes estáveis e cross-functional, capazes de levar uma ideia até um resultado utilizável com menos handoffs. O Scrum define explicitamente uma Scrum Team cross-functional e self-managing. A especialização continua importante, mas os especialistas colaboram dentro de um resultado compartilhado em vez de otimizar etapas departamentais isoladas.

Ideia-chave

Cross-functionality reduz a dependência de filas organizacionais; não exige que cada pessoa possua todas as habilidades.

radio_button_uncheckedshort_text8. Gestão de Riscos

Tendência tradicional / preditiva. A gestão de riscos preditiva tenta identificar a incerteza antecipadamente, analisar probabilidade e impacto, definir respostas, criar reservas, revisar designs e controlar a execução. Isso é poderoso para riscos conhecidos e ambientes em que prevenir é mais barato do que experimentar.

Tendência Agile / adaptativa. Agile acrescenta outro mecanismo de risco: exposição. Pequenos incrementos forçam pressupostos a confrontar a realidade. Integração frequente revela risco técnico. Feedback de usuários revela risco de produto. Sprints curtas limitam o tempo investido antes da inspeção. O Scrum descreve explicitamente sua abordagem iterativa e incremental como uma forma de otimizar a previsibilidade e controlar riscos.

Ideia-chave

Métodos preditivos frequentemente são fortes para risco conhecido; métodos adaptativos frequentemente são fortes para risco de descoberta.

radio_button_uncheckedshort_text9. Métricas

Tendência tradicional / preditiva. Projetos tradicionais normalmente enfatizam variação de cronograma, variação de orçamento, conclusão de marcos, earned value, percentual concluído, contagem de defeitos e conformidade com o plano. Essas métricas podem ser úteis quando o plano representa de maneira significativa o sucesso.

Tendência Agile / adaptativa. Ambientes Agile acrescentam medidas mais próximas de fluxo, qualidade, valor e resultados: cycle time, lead time, throughput, frequência de releases, defeitos que escaparam para produção, adoção pelos usuários, conversão, satisfação, confiabilidade e progresso em direção às metas. Velocity pode ser usada por algumas equipes para previsão local, mas não é uma métrica universal de sucesso em Agile ou Scrum.

Ideia-chave

A melhor métrica responde a uma pergunta de decisão; ela não existe apenas porque é fácil de contar.

radio_button_uncheckedshort_text10. Aprendizado

Tendência tradicional / preditiva. Em um modelo fortemente preditivo, o aprendizado muitas vezes é usado para melhorar a execução do plano: resolver problemas, controlar variações e prevenir defeitos. Se os pressupostos sobre o próprio produto forem tratados como requisitos fixos, o aprendizado sobre o produto pode chegar tarde demais para influenciar decisões importantes.

Tendência Agile / adaptativa. Agile trata o aprendizado como parte do modelo de desenvolvimento do produto. Requisitos são hipóteses sobre aquilo de que as pessoas precisam. Designs são hipóteses sobre o que funcionará. Previsões são hipóteses sobre o que pode ser entregue. Ciclos curtos de feedback permitem testar e revisar essas hipóteses.

Ideia-chave

Uma organização adaptativa não apenas executa trabalho; ela atualiza suas crenças.

radio_button_uncheckedshort_textPrevisibilidade não significa certeza

Um equívoco frequente é imaginar que o desenvolvimento preditivo cria certeza, enquanto Agile aceita a incerteza. Nenhuma abordagem consegue eliminar a incerteza. Métodos preditivos criam previsões úteis quando as entradas são estáveis e as relações entre tarefas são razoavelmente conhecíveis. Métodos adaptativos criam previsões úteis recalibrando-as repetidamente com base em resultados observados.

O Scrum é particularmente esclarecedor nesse ponto. Seu propósito não é abandonar a previsibilidade. O Scrum Guide afirma que uma abordagem iterativa e incremental é utilizada para otimizar a previsibilidade e controlar riscos. A diferença é epistemológica: a previsibilidade melhora por meio de transparência, inspeção, adaptação e evidências do trabalho concluído, e não pela suposição de que um modelo inicial do futuro permanecerá permanentemente preciso.

A qualidade da previsão, portanto, depende do ambiente. Se uma equipe estiver substituindo 500 dispositivos de rede idênticos por meio de um procedimento validado, o throughput histórico e um sequenciamento detalhado podem criar excelente controle preditivo. Se a mesma organização estiver inventando uma nova experiência de suporte assistida por IA para clientes, nenhum cronograma poderá prever com confiabilidade qual design de interação conquistará a confiança dos clientes antes que a equipe o teste. O sistema de controle adequado muda de acordo com a incerteza.

radio_button_uncheckedshort_textQuando diferentes abordagens podem ser apropriadas

Escolher um ciclo de vida é uma decisão econômica. Quanto mais estável e repetível for o trabalho, mais valor uma abordagem preditiva poderá extrair do planejamento. Quanto mais incerto e dependente de feedback for o trabalho, mais valor uma abordagem adaptativa poderá extrair do aprendizado. Muitas iniciativas reais contêm as duas condições e, por isso, beneficiam-se de modelos híbridos.

Uma regra prática de seleção

Quando o custo da experimentação for baixo e o custo de construir a coisa errada for alto, encurte o ciclo de feedback. Quando o trabalho for estável, repetível, fortemente restrito e caro de interromper, um planejamento preditivo mais robusto pode ser economicamente superior.

radio_button_uncheckedshort_textExemplo prático - um banco, dois projetos, duas abordagens sensatas

Imagine um banco conduzindo duas iniciativas ao mesmo tempo. A primeira é uma migração obrigatória de um serviço interno consolidado de um data center antigo para um novo ambiente de hospedagem. A arquitetura-alvo é conhecida, o comportamento da aplicação é estável, o runbook de migração foi testado, as janelas de manutenção são limitadas e os reguladores exigem evidências claras de controles. A segunda iniciativa é uma nova funcionalidade móvel destinada a ajudar clientes a entender e reduzir despesas recorrentes. O banco conhece o objetivo de negócio, mas ainda não sabe qual experiência os clientes considerarão confiável nem qual utilizarão regularmente.

Para a migração, um plano fortemente preditivo pode ser apropriado. As equipes podem inventariar dependências, definir ondas de migração, programar janelas de freeze, estabelecer procedimentos de rollback, obter aprovações, ensaiar cutovers e medir a conclusão em relação a um estado-alvo conhecido. O feedback continua importante, e os ensaios podem ser iterativos, mas o valor do trabalho decorre em grande parte de executar uma transformação conhecida de forma segura e completa.

Para o produto voltado ao cliente, o mesmo modelo de gestão seria arriscado. Uma especificação de seis meses poderia descrever dezenas de gráficos de orçamento e regras de notificação, mas o banco ainda não saberia se os clientes considerariam a funcionalidade útil ou invasiva. Uma abordagem adaptativa pode começar com uma pequena hipótese: clientes talvez valorizem visualizar assinaturas recorrentes agrupadas de forma clara, com uma maneira simples de identificar cobranças desnecessárias.

A equipe de produto cria um incremento fino para um grupo limitado de clientes, mede engajamento, entrevista usuários, observa quais rótulos geram confusão e descobre que os clientes se importam mais com cobranças recorrentes futuras do que com a classificação histórica. O Product Backlog muda. Uma funcionalidade que parecia essencial no plano original é rebaixada em prioridade, enquanto uma nova capacidade de alertas sobe porque as evidências indicam maior valor.

Agora imagine impor o mesmo método às duas iniciativas. Se a migração fosse gerenciada como um exercício interminável de descoberta, o banco poderia criar incerteza desnecessária em torno de uma tarefa bem compreendida. Se o novo produto fosse gerenciado como um escopo preditivo fixo, o banco poderia entregar com eficiência um conjunto de funcionalidades que os clientes não querem. A seleção do método importa porque diferentes tipos de incerteza exigem diferentes economias de feedback.

A lição não é que infraestrutura deva ser sempre preditiva e produtos digitais devam ser sempre Agile. Migrações inéditas para a nuvem podem conter alta incerteza, enquanto uma melhoria madura de software pode ser altamente previsível. O fator decisivo é a natureza do trabalho, e não a categoria impressa no termo de abertura do projeto.

radio_button_uncheckedshort_textMétricas: medir conformidade vs. medir evidências

As métricas revelam o que uma organização acredita que significa progresso. Em um ambiente orientado por plano, linhas de base de cronograma e custo podem ser poderosas porque a incerteza principal pode estar na execução: conseguimos concluir um conjunto conhecido de trabalho conforme prometido? Em um ambiente de descoberta de produto, métricas de conformidade podem se tornar enganosas porque executar o plano original talvez não seja o mesmo que criar valor.

É por isso que métricas Agile não deveriam simplesmente substituir métricas tradicionais por um novo conjunto de números de atividade. Story points concluídos, número de Sprints, tamanho do backlog ou velocity da equipe podem se tornar o mesmo tipo de proxy se estiverem desconectados de resultados. Uma equipe pode aumentar a velocity enquanto a satisfação do cliente cai. Pode fechar mais tickets enquanto a confiabilidade piora. Pode entregar mais funcionalidades enquanto a adoção permanece inalterada.

Métricas adaptativas úteis frequentemente combinam fluxo, qualidade e resultado. Métricas de fluxo revelam como o trabalho se move. Métricas de qualidade revelam se a entrega é sustentável. Métricas de produto revelam se usuários e negócio recebem valor. A métrica deve ajudar alguém a decidir o que adaptar em seguida. Se nenhuma decisão muda porque um número se alterou, esse número pode estar servindo apenas para reporte, e não para aprendizado.

radio_button_uncheckedshort_textRisco e aprendizado: dois lados da mesma decisão

Gestão de riscos e aprendizado estão intimamente ligados. Um risco existe porque o futuro é incerto. Parte da incerteza pode ser analisada; outra parte precisa ser testada. Métodos preditivos frequentemente reduzem a incerteza decompondo o plano, analisando dependências, revisando designs, modelando modos de falha e controlando mudanças. Métodos adaptativos reduzem a incerteza criando pequenos experimentos e incrementos utilizáveis que expõem pressupostos.

Uma organização madura utiliza as duas formas. A arquitetura de segurança pode exigir análise substancial antes que qualquer dado de cliente seja manipulado. Uma nova mensagem de onboarding pode ser validada com mais segurança por meio de testes controlados com usuários do que por meses de debate. Uma migração de banco de dados pode merecer um plano de cutover ensaiado e um procedimento de rollback. Um novo algoritmo de recomendação pode exigir experimentos repetidos porque seu valor é impossível de conhecer até que usuários reajam.

A distinção mais importante está entre risco conhecido e risco de descoberta. O risco conhecido muitas vezes pode ser gerenciado com controles preventivos, padrões, checklists, planos de contingência e análise especializada. O risco de descoberta existe porque a organização pode estar errada sobre o que os clientes precisam, sobre como a tecnologia se comportará ou sobre qual solução é a melhor. Ciclos curtos de feedback são particularmente eficazes contra risco de descoberta porque convertem incerteza em evidência.

radio_button_uncheckedshort_textComo o Scrum se posiciona nessa comparação

O Scrum está claramente no lado adaptativo do espectro, mas contém mecanismos importantes de previsibilidade e disciplina. Ele é fundamentado no empirismo e no Lean Thinking. Sprints criam ciclos de aprendizado com duração fixa. A Product Goal fornece direcionamento de prazo mais longo. Sprint Goals criam foco de curto prazo. O Product Backlog fornece uma visão ordenada e evolutiva do trabalho futuro. A Definition of Done estabelece transparência sobre qualidade. Increments criam evidências. Eventos formais criam inspeção e adaptação recorrentes.

Essa combinação explica por que o Scrum não deve ser descrito como "sem plano, sem documentação, sem prazos". O Scrum é leve, mas não é casual. Ele pede que as pessoas planejem usando o conhecimento atual, tornem o trabalho transparente, inspecionem com frequência e adaptem quando as evidências mudarem. Previsões continuam existindo, mas são tratadas como previsões, e não como garantias sobre um futuro complexo.

Para a PSM I, lembre-se de que o próprio Scrum utiliza as palavras iterativo e incremental. Essa linguagem não é decorativa. A iteração apoia o refinamento por meio de ciclos repetidos. O desenvolvimento incremental torna o progresso concreto por meio de adições utilizáveis. O empirismo torna a abordagem adaptativa porque as decisões são revistas com base na observação. Juntos, esses mecanismos otimizam a previsibilidade e controlam riscos em ambientes complexos.

Olhar para a prova PSM I

Quando uma questão apresentar incerteza, mudança de requisitos, novas evidências de stakeholders ou aprendizado técnico inesperado, procure respostas que preservem as accountabilities e as metas do Scrum ao mesmo tempo em que permitam inspeção e adaptação. Não proteja um plano detalhado apenas porque ele foi criado primeiro.

radio_button_uncheckedshort_textInterpretações equivocadas comuns

radio_button_uncheckedshort_textUm framework simples de decisão

Nenhum checklist curto consegue escolher automaticamente um ciclo de vida, mas as perguntas a seguir ajudam a revelar onde o controle preditivo ou adaptativo provavelmente criará mais valor.

• Quão estáveis são os requisitos, e quais evidências sustentam essa estabilidade?
• Quão bem compreendida é a tecnologia ou a abordagem de solução?
• Usuários ou stakeholders conseguem avaliar resultados parciais de maneira significativa?
• Incrementos valiosos podem ser entregues antes que toda a solução esteja concluída?
• Quão cara é uma mudança de requisito depois que a implementação começa?
• Quão caro é construir a coisa errada e descobrir esse erro tarde?
• Restrições de segurança, regulação, contrato, hardware ou dependências são dominantes?
• O projeto contém principalmente risco de execução ou contém risco de descoberta significativo?
• Com que rapidez a equipe consegue obter feedback confiável de clientes, técnico ou operacional?
• Uma estrutura híbrida isolaria de forma mais eficaz o trabalho previsível do trabalho incerto?

Pense em incerteza, não em ideologia

Um bom sistema de entrega não é aquele que parece mais Agile nem aquele que parece mais controlado. É aquele que cria a quantidade adequada de planejamento, feedback, aprendizado e governança para a incerteza e as consequências do trabalho.

radio_button_uncheckedshort_textConclusão: escolha o modelo de feedback que corresponda ao trabalho

Agile versus desenvolvimento tradicional não é um debate entre flexibilidade e disciplina. Ambas as abordagens buscam entrega bem-sucedida, coordenação útil, risco gerenciável e algum grau de previsibilidade. Elas diferem principalmente quanto à origem esperada do conhecimento e à frequência com que permitem que esse conhecimento altere o plano.

O desenvolvimento preditivo investe mais intensamente em compreender e organizar o futuro antes da execução. É eficaz quando requisitos são estáveis, a tecnologia é conhecida, dependências podem ser modeladas e desvios são caros. O desenvolvimento iterativo melhora uma solução por repetição. O desenvolvimento incremental faz o produto crescer por meio de adições concluídas. O desenvolvimento adaptativo pressupõe que informações importantes surgirão durante o trabalho e cria ciclos curtos de aprendizado em torno dessa realidade.

Ao longo de planejamento, escopo, feedback, entrega, gestão de mudanças, participação do cliente, organização da equipe, risco, métricas e aprendizado, o padrão Agile é consistente: reduzir a distância entre uma decisão e as evidências sobre essa decisão. O padrão tradicional também é consistente: reduzir a incerteza cedo o bastante para que a execução coordenada em relação a um plano se torne economicamente vantajosa. Nenhum dos padrões é universalmente superior.

Na minha visão, as organizações mais maduras deixam de perguntar em qual método "acreditam" e passam a perguntar qual incerteza estão tentando controlar. Uma migração de infraestrutura bem compreendida pode merecer planejamento preditivo rigoroso. Um novo produto digital voltado ao cliente pode merecer rápida descoberta adaptativa. Uma transformação regulada pode exigir marcos externos fixos com desenvolvimento adaptativo de software dentro deles. O contexto não é um compromisso; ele faz parte do julgamento profissional.

Para a PSM I, a conexão principal é clara. O Scrum é projetado para trabalho complexo, no qual o conhecimento surge por meio da experiência. Ele utiliza uma abordagem iterativa e incremental, inspeção frequente e adaptação não porque o planejamento seja pouco importante, mas porque os planos se tornam mais confiáveis quando a realidade pode corrigi-los com frequência. Quando essa ideia é compreendida, a diferença entre desenvolvimento tradicional e Agile deixa de ser um slogan e se torna uma teoria prática de aprendizado, risco e tomada de decisão.

radio_button_uncheckedshort_textPrincipais conclusões

• Preditivo, iterativo, incremental e adaptativo descrevem características diferentes e não devem ser usados como sinônimos.
• Abordagens preditivas criam controle principalmente por meio de compreensão antecipada, linhas de base e mudança gerenciada.
• Abordagens adaptativas criam controle principalmente por meio de ciclos curtos de feedback, evidências e replanejamento frequente.
• Agile continua planejando; muda o momento, o horizonte, o detalhamento e a autoridade do planejamento.
• Abordagens tradicionais podem ser apropriadas quando requisitos e tecnologia são estáveis e o trabalho é repetível ou fortemente restrito.
• Abordagens Agile são especialmente úteis quando o risco de descoberta é alto e feedback significativo pode ser obtido com frequência.
• Trabalho iterativo refina; trabalho incremental adiciona capacidade concluída; Agile normalmente combina ambos com adaptação.
• Participação do cliente, equipes cross-functional, incrementos utilizáveis e aprendizado contínuo reduzem o custo de descobrir que um pressuposto estava errado.
• Métricas devem apoiar decisões sobre valor, fluxo, qualidade ou risco, em vez de recompensar atividade por si só.
• Abordagens híbridas podem ser apropriadas quando trabalho previsível e trabalho incerto coexistem na mesma iniciativa.
• Scrum é iterativo, incremental, empírico e adaptativo, ao mesmo tempo em que busca previsibilidade e controle de riscos.

radio_button_uncheckedshort_textReferências e leituras complementares

• Manifesto for Agile Software Development - Os valores Agile originais, incluindo colaboração com o cliente e resposta a mudanças.
• Principles behind the Agile Manifesto - Os doze princípios que tratam de entrega antecipada, mudança de requisitos, software funcionando com frequência, colaboração, sustentabilidade, excelência técnica, simplicidade, equipes auto-organizadas e reflexão.
• The Scrum Guide - November 2020 - A definição oficial de Scrum, incluindo empirismo, Lean Thinking, desenvolvimento iterativo e incremental, transparência, inspeção, adaptação e autogerenciamento.
• Project Management Institute - One Size Does Not Fit All: Choosing the Right Project Approach - Discussão sobre ciclos de vida preditivos, iterativos, incrementais e adaptativos e sobre quando podem ser adequados a diferentes projetos.
• Project Management Institute - A Spectrum of Approaches to Project Agility - Um contínuo que vai do preditivo, passa pelo iterativo e incremental e chega ao Agile, enfatizando que o planejamento existe em todos os ciclos de vida.