Desenvolvimento de Software Antes do Agile

radio_button_uncheckedshort_textObjetivo do capítulo

Compreender a lógica do desenvolvimento de software tradicional e orientado por planos: planejamento extensivo antecipado, fases especializadas, controle por marcos e uma forte busca por previsibilidade. Em seguida, examinar por que o software difere da produção industrial repetitiva e por que o feedback tardio torna a incerteza progressivamente mais cara. Essa base é essencial para entender por que as abordagens Agile - e, posteriormente, o Scrum - atribuem tanta importância a ciclos curtos de aprendizagem e à adaptação.

radio_button_uncheckedshort_textIntrodução: antes do Agile, o problema não era falta de inteligência

Para compreender o Agile, não basta memorizar seus valores. É preciso entender o mundo ao qual ele reagia - e por que esse mundo, em determinado momento, pareceu perfeitamente racional.

As discussões modernas às vezes descrevem o desenvolvimento de software anterior ao Agile como se as organizações simplesmente não soubessem agir melhor: gestores elaboravam planos enormes, analistas produziam documentos, desenvolvedores programavam durante meses, testadores apareciam apenas no fim e os clientes descobriam tarde demais que o resultado estava errado. Essa caricatura é memorável, mas é historicamente frágil e profissionalmente pouco útil. As práticas tradicionais de desenvolvimento de software surgiram de um problema legítimo de gestão: grandes sistemas de software estavam se tornando caros, difíceis de coordenar e cada vez mais importantes para governos e empresas. As organizações buscavam disciplina, responsabilização, cronogramas, orçamentos, rastreabilidade e uma forma de controlar trabalhos que podiam envolver centenas de pessoas.

A resposta natural foi tomar emprestadas ideias da engenharia e da administração industrial. Se uma ponte, um componente aeronáutico, uma fábrica ou um edifício podiam ser planejados por meio de etapas definidas, talvez o software pudesse ser administrado de maneira semelhante. Os requisitos poderiam ser especificados; a análise poderia traduzir as necessidades do negócio em comportamento do sistema; arquitetos poderiam projetar a solução; programadores poderiam implementá-la; testadores poderiam verificá-la; e equipes de operações poderiam implantá-la e mantê-la. A gestão, então, poderia medir o progresso por meio de documentos, conclusão de fases, revisões, aprovações e marcos.

Essa família de abordagens passou a ser associada a ciclos de vida sequenciais e, mais tarde, à conhecida imagem do modelo em cascata (Waterfall). O artigo de Winston Royce, de 1970, é frequentemente citado nessa história, embora a realidade seja mais nuançada do que muitos resumos sugerem. Royce descreveu um fluxo sequencial que ia dos requisitos ao projeto, à codificação, aos testes e às operações, mas também alertou para os riscos de uma abordagem puramente linear e recomendou feedback, prototipação e uma versão preliminar para reduzir a incerteza. Portanto, a famosa cascata rígida não foi simplesmente inventada em um único momento e entusiasticamente prescrita exatamente como os diagramas posteriores fizeram parecer.

Por décadas, contudo, o pensamento orientado por planos moldou os projetos de software porque solucionava necessidades organizacionais reais. Um plano detalhado facilitava a aprovação de financiamento. Uma especificação de requisitos facilitava a celebração de contratos. Os marcos de aprovação davam aos executivos uma sensação de controle. Departamentos especializados permitiam às organizações contratar, administrar e otimizar competências específicas. A documentação ajudava a coordenar o trabalho entre grandes grupos. Em domínios previsíveis, esses mecanismos podem ser valiosos até hoje.

A tensão surge quando o trabalho não é suficientemente previsível. Muitas vezes, o software é criado precisamente porque alguém deseja uma nova capacidade, um novo modelo de negócio, uma nova experiência para o cliente ou uma nova forma de automatizar decisões. Nessas situações, conhecimentos importantes são descobertos durante a construção do produto. Usuários mudam de ideia depois de ver algo concreto. Desenvolvedores descobrem restrições técnicas. Concorrentes se movimentam. Regulamentos mudam. Premissas de desempenho falham. Um requisito que parecia óbvio em uma reunião torna-se ambíguo quando é traduzido em código. O problema central deixa de ser apenas executar um plano; passa a ser aprender sob incerteza.

Essa é a ponte intelectual para o Agile. O Manifesto para o Desenvolvimento Ágil de Software, escrito em 2001 por dezessete profissionais oriundos de diferentes movimentos de desenvolvimento leve, não afirmou que planos, processos, documentação ou contratos não tinham valor. Pelo contrário, reconheceu explicitamente seu valor, ao mesmo tempo em que atribuiu maior importância a software em funcionamento, colaboração, interação humana e resposta a mudanças. A mudança não foi da disciplina para o caos. Foi da previsão como principal mecanismo de controle para o feedback frequente e a adaptação como mecanismos essenciais de controle.

Para quem se prepara para a PSM I, esse contexto histórico é importante. O Scrum se fundamenta no empirismo: decisões são tomadas com base em observação e experiência, e o conhecimento emerge por meio de transparência, inspeção e adaptação. Essas ideias tornam-se muito mais fáceis de compreender quando primeiro se observam as limitações de ciclos longos e orientados por planos. Assim, este capítulo faz uma pergunta mais profunda do que “O que era o Waterfall?”. Ele pergunta: quais premissas fazem um sistema orientado por planos funcionar, o que acontece quando essas premissas falham e por que reduzir a distância entre ação e feedback altera fundamentalmente a maneira como o software pode ser gerenciado?

radio_button_uncheckedshort_textComo os projetos tradicionais de software eram organizados

Os projetos tradicionais de software eram comumente organizados em torno de uma sequência de atividades especializadas. Os nomes exatos variavam conforme a empresa, o contrato, a norma e a época, mas a lógica geral era reconhecível: primeiro decidir o que o sistema deveria fazer; depois projetar como deveria funcionar; em seguida construí-lo; depois verificá-lo; e, por fim, colocá-lo em produção. Cada etapa produzia saídas que se tornavam entradas para a etapa seguinte.

Um ciclo de vida simplificado poderia conter requisitos de negócio, requisitos de sistema ou de software, análise, arquitetura e projeto detalhado, implementação, integração, testes de sistema, testes de aceitação, implantação e manutenção. Em grandes organizações, departamentos diferentes podiam ser responsáveis por partes distintas desse fluxo. Analistas de negócio trabalhavam com stakeholders. Arquitetos e projetistas traduziam requisitos em estruturas técnicas. Equipes de desenvolvimento implementavam o projeto. Equipes de garantia da qualidade testavam o resultado de forma independente. Grupos de release ou de operações controlavam a implantação em produção.

Essa separação não era irracional. A especialização pode aumentar a competência e criar responsabilidades claras. Testes independentes podem reduzir conflitos de interesse. Análises formais podem evitar erros caros. A arquitetura pode ser essencial quando sistemas possuem restrições de segurança, escala, regulamentação ou integração. O problema surge quando a separação organizacional se transforma em separação temporal: analistas concluem seu trabalho meses antes de os desenvolvedores começarem; desenvolvedores terminam meses antes de os testadores validarem o comportamento integrado; e os usuários veem o produto real apenas perto do fim.

O projeto passa, então, a funcionar como uma cadeia de repasses. Cada repasse comprime um contexto rico em um artefato: documento de requisitos, especificação de projeto, contrato de interface, plano de testes, solicitação de mudança ou registro de aprovação. Os documentos tornam-se a memória do projeto porque as pessoas que originalmente discutiram determinada decisão podem já não estar envolvidas quando suas consequências aparecem. Quanto maior e mais distribuída a organização, mais atraente se torna esse modelo intensivo em documentação.

A governança do projeto normalmente reforçava essa estrutura por meio de marcos e gates de fase. Uma fase de requisitos podia exigir aprovação formal antes que o projeto técnico avançasse. A arquitetura podia precisar de aprovação antes da codificação. Os testes podiam começar somente depois que uma versão suficientemente completa existisse. O financiamento podia ser liberado em etapas. Contratos podiam definir a aceitação com base na especificação original. Assim, o progresso ficava fortemente associado à conclusão de atividades e entregáveis planejados.

Isso produz um efeito gerencial sutil: a organização pode relatar um progresso substancial antes que qualquer usuário final tenha recebido valor em funcionamento. Centenas de requisitos podem ter sido aprovados, documentos de arquitetura concluídos, milhares de horas contabilizadas e 70% do plano declarado concluído, embora o produto real ainda não tenha sobrevivido a uma interação realista com usuários. As métricas tradicionais de projeto podem, portanto, medir com mais facilidade o movimento pelo processo do que se o produto está, de fato, resolvendo o problema pretendido.

radio_button_uncheckedshort_textPlanejamento extensivo antecipado: a promessa de controle

O desenvolvimento orientado por planos começa com uma proposição gerencial poderosa: se conseguirmos compreender o suficiente sobre o resultado desejado antes do início da execução, poderemos decompor o trabalho, estimá-lo, sequenciá-lo, alocar recursos, definir dependências, calcular orçamentos e prever datas de entrega. Quanto melhores forem as informações iniciais, mais confiável deverá se tornar o plano.

Essa lógica é profundamente familiar porque funciona muito bem em muitos domínios. Se uma fábrica produziu o mesmo componente milhares de vezes, a variação histórica pode ser medida. Se um projeto de construção utiliza técnicas bem compreendidas e requisitos estáveis, um planejamento detalhado pode coordenar mão de obra e materiais. Se um processo de negócio é repetitivo, a padronização pode reduzir variações e aumentar a eficiência. Nesses contextos, desvios em relação ao plano frequentemente são problemas a ser minimizados.

A gestão tradicional de software importou essa lógica por meio de estruturas analíticas do projeto (work breakdown structures), gráficos de Gantt, redes de dependência, cronogramas de referência, planos de recursos, medições semelhantes ao valor agregado, comitês de controle de mudanças, definições detalhadas de escopo e marcos contratuais. O projeto tentava transformar um futuro incerto em uma sequência controlada de tarefas.

A técnica se torna mais atraente quando as mudanças são consideradas caras. Se uma alteração tardia de requisito obriga analistas a revisar especificações, arquitetos a modificar o projeto, desenvolvedores a reescrever código, testadores a redesenhar casos de teste e gestores a renegociar contratos, a resposta aparentemente óbvia é investir mais esforço em acertar os requisitos logo no início. Mais análise parece uma forma racional de reduzir retrabalho posterior.

Entretanto, essa estratégia contém uma premissa oculta: a incerteza pode ser removida principalmente por meio de mais reflexão antes da construção. Às vezes, isso é verdade. Uma regra jurídica ausente pode ser pesquisada. Uma interface conhecida pode ser documentada. Uma meta de desempenho pode ser esclarecida. Porém, muitas incertezas em software são experienciais. Um cliente talvez não saiba se um fluxo de trabalho é intuitivo até utilizá-lo. Uma equipe talvez não saiba se uma arquitetura nova se comportará adequadamente sob uma carga semelhante à de produção até implementar uma parte significativa. Um mercado pode não revelar a demanda até que um produto seja exposto a usuários reais. Essas incertezas não são simplesmente lacunas de documentação; são desconhecidos que exigem feedback da realidade.

Quando um projeto trata toda incerteza como se pudesse ser convertida em certeza por meio de planejamento, o plano pode tornar-se mais detalhado sem se tornar mais verdadeiro. A organização ganha precisão - datas exatas, tarefas detalhadas, percentuais atribuídos - enquanto as premissas subjacentes permanecem incertas. Precisão e previsibilidade não são a mesma coisa. Um cronograma pode ser preciso até o dia e, ainda assim, estar errado.

Distinção fundamental

Um plano detalhado é uma representação do que atualmente acreditamos que acontecerá. Em trabalhos previsíveis, essa representação pode aproximar-se bastante da realidade. No desenvolvimento de produtos complexos, o plano também contém hipóteses que precisam ser testadas por meio de entrega e feedback.

radio_button_uncheckedshort_textA separação entre análise, desenvolvimento, testes e entrega

Projetos sequenciais frequentemente otimizam cada disciplina como uma função separada. Analistas buscam requisitos completos. Projetistas buscam uma arquitetura coerente. Desenvolvedores buscam uma implementação eficiente. Testadores buscam verificação abrangente. Operações busca releases estáveis. Cada grupo pode desempenhar profissionalmente seu papel local e, ainda assim, o sistema como um todo produzir aprendizagem lenta.

O custo mais importante dessa separação não é a hierarquia organizacional em si, mas o atraso para descobrir se as premissas de um grupo sobrevivem ao contato com a etapa seguinte. Um analista pode documentar um requisito que parece inequívoco. Meses depois, um desenvolvedor descobre duas interpretações contraditórias. O esclarecimento então retorna por reuniões e controle de mudanças. Um desenvolvedor pode implementar uma funcionalidade tecnicamente válida que, mais tarde, os testadores descobrem ser impossível de usar em um cenário realista. Um sistema pode passar nos testes formais e ainda falhar operacionalmente porque implantação, observabilidade, segurança ou suporte foram considerados tarde demais.

Esse atraso cria filas. O trabalho espera pela aprovação da análise, revisão de projeto, capacidade de desenvolvimento, ambiente de testes, janela de release ou aceitação do negócio. A utilização local pode parecer alta - todos os departamentos estão ocupados - enquanto o fluxo ponta a ponta continua lento. O projeto otimiza pessoas e fases em vez do tempo necessário para transformar uma ideia em valor validado.

Uma longa separação entre fases também pode criar uma dinâmica adversarial em torno da qualidade. Quando os testes são principalmente uma etapa tardia, os defeitos passam a ser evidências de que o trabalho anterior estava errado. As equipes podem discutir se um problema é defeito de requisito, de projeto, de codificação, de teste, de ambiente ou uma solicitação de mudança. A organização gasta energia atribuindo o defeito à fase e ao orçamento corretos, em vez de tratar a qualidade como responsabilidade contínua do produto.

Outra consequência é o tamanho do lote. Se o desenvolvimento precisa estar “concluído” antes que os testes de sistema comecem, uma grande quantidade de mudanças chega aos testes de uma só vez. Quando centenas de componentes interagem pela primeira vez, as falhas tornam-se mais difíceis de diagnosticar porque muitas variáveis mudaram simultaneamente. A própria integração transforma-se em uma fase do projeto. Isso é o oposto da aprendizagem contínua: a incerteza se acumula até que um grande lote finalmente seja exposto à realidade.

O mesmo padrão aparece na entrega. Processos tradicionais de release frequentemente agrupam meses de trabalho em uma única grande versão, porque a implantação é cara e arriscada. Ironicamente, o tamanho do lote pode tornar a implantação ainda mais arriscada. Mais funcionalidades, mais dependências, mais alterações de infraestrutura e mais interações desconhecidas atravessam juntas a fronteira da produção. A organização passa, então, a ter um incentivo racional para liberar com menor frequência, o que prolonga ainda mais os ciclos de feedback.

radio_button_uncheckedshort_textProjetos orientados por planos e o significado de progresso

Um projeto orientado por planos utiliza o plano aprovado como referência central para a tomada de decisões. Metas de escopo, cronograma, custo e qualidade são estabelecidas, e a gestão procura manter a execução alinhada a essa linha de base. As mudanças costumam ser avaliadas quanto ao impacto, porque alterar uma dimensão pode afetar as demais. Essa é uma governança sensata quando o resultado pretendido é suficientemente conhecível de antemão.

O desafio é que a conformidade com o plano pode tornar-se um substituto para o sucesso do produto. Se uma equipe entregar exatamente as funcionalidades especificadas dezoito meses antes, na data e no orçamento contratados, o projeto pode ser considerado bem-sucedido mesmo que os usuários já não precisem de várias dessas funcionalidades. Inversamente, uma equipe que descobre uma direção de produto melhor na metade do trabalho pode parecer estar desviando do plano, embora a adaptação aumente o valor.

Essa é uma tensão fundamental entre o pensamento de projeto e o pensamento de produto. Um projeto costuma ser enquadrado como um empreendimento temporário com escopo, orçamento e data de término definidos. Um produto é um veículo contínuo de geração de valor em um ambiente que muda. À medida que o software se tornou cada vez mais central para produtos, serviços e modelos de negócio, tornou-se mais difícil sustentar premissas de escopo estático.

Em um ambiente orientado por planos, o controle de mudanças é, portanto, um mecanismo de proteção. Se o escopo puder mudar livremente enquanto prazo e orçamento permanecem fixos, o projeto torna-se ingovernável. Solicitações formais de mudança tornam visíveis as consequências econômicas. A fragilidade aparece quando a mudança é tratada principalmente como perturbação, e não como informação. Um cliente que muda de direção pode estar revelando que o requisito original estava incompleto, que o mercado se moveu ou que o software em funcionamento expôs uma possibilidade melhor. O sistema precisa decidir se aprender é uma exceção ao controle ou uma parte normal do desenvolvimento.

Abordagens Agile passariam a dar mais ênfase à adaptação do plano à medida que o conhecimento melhora. Isso não elimina previsões nem compromissos. Muda o objeto de controle. Em vez de controlar principalmente pela conformidade a um plano distante, as equipes podem controlar por horizontes mais curtos, resultados de trabalho visíveis, inspeção frequente e adaptação deliberada. Essa mudança é central para a base empírica do Scrum.

radio_button_uncheckedshort_textPrevisibilidade versus incerteza: o problema central de gestão

Toda abordagem de desenvolvimento faz uma afirmação implícita sobre a incerteza. O planejamento tradicional funciona melhor quando a variabilidade é limitada: os requisitos podem ser compreendidos com estabilidade razoável, a tecnologia é conhecida, as dependências são conhecidas e a relação entre esforço e resultado é suficientemente repetível. Nessas condições, investir em previsão é valioso porque ela pode orientar uma execução eficiente.

Projetos de software frequentemente contêm várias formas de incerteza ao mesmo tempo. A incerteza de requisitos diz respeito ao que os usuários realmente precisam. A incerteza de solução diz respeito a como construir a solução. A incerteza tecnológica diz respeito a plataformas, integrações, dados, desempenho, segurança ou infraestrutura se comportarem conforme o esperado. A incerteza de mercado diz respeito à adoção do resultado pelos clientes. A incerteza organizacional envolve decisões de stakeholders, financiamento, regulamentações, dependências e estratégia. A incerteza humana envolve colaboração, interpretação, competências e mudanças na composição da equipe.

Parte da incerteza pode ser reduzida antes da implementação. Entrevistas, protótipos, experimentos de arquitetura, simulações, provas de conceito e pesquisa podem melhorar o conhecimento. Entretanto, outras incertezas permanecem até que exista um Incremento significativo do produto. É por isso que um plano elaborado no início de uma iniciativa de software inovadora frequentemente contém suas informações mais frágeis justamente quando se espera que cubra o período mais longo.

O problema mais profundo não é que as previsões sejam inúteis. As equipes precisam de previsões. As empresas precisam tomar decisões de investimento. Os clientes precisam de expectativas. O problema está em confundir uma previsão com uma garantia sobre um futuro complexo. Quanto mais distante o horizonte de planejamento, mais premissas se acumulam. Um plano de uma semana pode depender de um pequeno conjunto de variáveis conhecidas. Um plano de dois anos pode depender de tecnologia, equipe, prioridades, fornecedores, comportamento dos usuários e condições de mercado permanecerem suficientemente estáveis. Cada dependência adicional é outra oportunidade para que a realidade se afaste do modelo.

É por isso que a frequência do feedback importa. Feedback frequente não elimina magicamente a incerteza; ele limita por quanto tempo a organização permanece errada antes de descobrir isso. Se uma premissa for inválida, aprender depois de uma semana é mais barato do que aprender depois de doze meses, porque menos decisões dependentes foram construídas sobre ela. Ciclos curtos de feedback transformam a incerteza de uma grande surpresa no fim do projeto em um fluxo de descobertas menores e gerenciáveis.

No Scrum, essa ideia aparece diretamente no empirismo. A transparência torna a situação atual observável. A inspeção compara a realidade com metas e expectativas. A adaptação muda o curso quando o resultado observado é inaceitável. A teoria não é contrária ao planejamento; ela reconhece que o planejamento precisa ser repetidamente atualizado por evidências.

radio_button_uncheckedshort_textPor que desenvolvimento de software não é o mesmo que produção industrial

A comparação entre software e manufatura só é útil quando distinguimos desenvolvimento de produto de produção de produto. Na manufatura, depois que um produto e seu processo amadurecem, a organização pode produzir repetidamente o mesmo item. A variação costuma ser indesejável. A eficiência melhora por meio da padronização das etapas, redução de defeitos, balanceamento do fluxo, automação do trabalho repetitivo e aprendizagem a partir de padrões estatísticos estáveis.

O desenvolvimento de software geralmente é diferente porque a equipe não está digitando repetidamente o mesmo programa. Se o software desejado já existe e pode simplesmente ser copiado, o custo marginal da cópia é extremamente baixo. A parte cara é descobrir e construir algo que ainda não existe exatamente daquela forma. O desenvolvimento, portanto, aproxima-se mais de projeto, pesquisa, resolução de problemas e criação de conhecimento do que de montagem repetitiva.

Essa diferença possui grandes consequências gerenciais. Na produção, pedir aos trabalhadores que repitam de modo mais consistente um processo comprovado pode aumentar a produção. No desenvolvimento, obrigar especialistas a seguir uma sequência pré-escrita cada vez mais detalhada pode não resolver questões técnicas ou de produto inéditas. O próprio trabalho gera informações que não poderiam ser totalmente especificadas de antemão.

O software também é incomumente maleável. A estrutura física de um edifício impõe fortes restrições a mudanças tardias; o software, em muitos casos, pode ser alterado depois da liberação. Essa aparente flexibilidade é ao mesmo tempo vantagem e armadilha. Como o código é modificável, stakeholders esperam adaptação. Contudo, sistemas de software também acumulam dependências, acoplamento, migrações de dados, obrigações de segurança, restrições operacionais e dívida técnica. Uma mudança que parece pequena na linguagem do negócio pode afetar muitas partes ocultas do sistema.

A estrutura de custos também é diferente. Produzir outra unidade física consome material e capacidade de fabricação. Produzir outra cópia de software é barato, enquanto projetar e manter o sistema é caro. Portanto, o objetivo econômico do desenvolvimento de software não é principalmente maximizar o número de unidades de código produzidas. É maximizar resultados úteis ao mesmo tempo em que se administra a complexidade, a aprendizagem e a capacidade de mudança no longo prazo.

É por isso que métricas de produtividade importadas do pensamento industrial podem induzir ao erro. Linhas de código, percentuais de utilização, número de tarefas concluídas ou horas trabalhadas não medem de forma confiável o valor para o cliente. Mais código pode tornar um produto pior. Uma equipe pode estar 100% utilizada e ainda entregar lentamente porque o trabalho permanece em filas. Um desenvolvedor que remove código desnecessário pode criar mais valor do que outro que escreve milhares de linhas. Em trabalho do conhecimento, volume de saída e qualidade do resultado não são equivalentes.

A analogia mais valiosa com sistemas modernos de produção, portanto, não é “tratar desenvolvedores como uma linha de montagem”. É estudar fluxo, qualidade na origem, pequenos lotes, detecção rápida de problemas e redução de espera. Essas ideias influenciaram posteriormente o pensamento Lean e Agile justamente porque tratam do comportamento do sistema sem fingir que a criação de software é montagem fabril repetitiva.

radio_button_uncheckedshort_textO custo oculto de ciclos longos de feedback

Feedback é informação sobre as consequências de uma decisão. Em software, ele pode vir de muitos lugares: um compilador, um teste automatizado, uma revisão de código, um build integrado, uma varredura de segurança, um teste de desempenho, uma demonstração para stakeholders, uma sessão de usabilidade, telemetria de produção, comportamento de clientes, receita, chamados de suporte ou incidentes operacionais. Quanto menor a distância entre uma decisão e o feedback relevante, mais rapidamente a equipe consegue corrigir seu modelo da realidade.

A entrega tradicional baseada em fases frequentemente ampliava essa distância. Requisitos podiam ser revisados por stakeholders sem serem vivenciados em software em funcionamento. A arquitetura podia ser aprovada no papel sem ser exercitada de ponta a ponta. Desenvolvedores podiam testar componentes isolados e integrá-los tarde. Equipes de qualidade podiam descobrir defeitos sistêmicos apenas depois de um grande lote de implementação. Clientes podiam ver o produto somente perto da aceitação. Cada atraso permitia que premissas equivocadas se propagassem.

Considere uma regra de negócio mal compreendida durante a análise de requisitos. Se um stakeholder vir uma parte funcional três dias depois, a equipe talvez precise corrigir apenas algumas linhas de lógica, testes e documentação. Se o mesmo mal-entendido permanecer oculto por nove meses, dezenas de telas, estruturas de dados, interfaces, casos de teste, materiais de treinamento e relatórios podem depender dele. O defeito deixa de ser uma única afirmação errada; torna-se arquitetura, código, processo e expectativa.

Ciclos longos de feedback, portanto, criam um custo cumulativo do erro. O problema não é apenas que mudanças “ficam mais caras depois”, de maneira abstrata. A organização criou mais decisões que dependem da premissa original. Corrigir a premissa significa revisitar toda a rede de trabalho dependente.

Eles também criam custos psicológicos e políticos. Quando meses de trabalho foram investidos em um plano, equipes e líderes se apegam a ele. Uma descoberta tardia ameaça orçamentos, reputações, contratos e compromissos de desempenho. As pessoas podem defender a direção existente mesmo quando as evidências sugerem mudança. Feedback frequente reduz o tamanho de cada correção e transforma a adaptação em um evento normal, e não em uma crise.

Ciclos longos também podem ocultar problemas de qualidade. Quando testes e integração acontecem tarde, defeitos chegam em lotes. As equipes perdem a memória contextual das decisões que os produziram. Desenvolvedores podem já ter migrado para outro trabalho. Reproduzir ambientes torna-se difícil. A análise de causa raiz torna-se mais lenta. O tempo decorrido entre causa e detecção vira outra fonte de complexidade.

Por fim, o feedback tardio dos clientes cria o risco mais perigoso de todos: construir corretamente a coisa errada. Um sistema pode ser tecnicamente excelente, bem documentado, seguro, performático e entregue conforme a especificação, mas ainda assim não gerar valor suficiente para usuários ou para o negócio. Somente o contato com stakeholders reais e o uso real podem validar muitas premissas de produto.

radio_button_uncheckedshort_textPor que as abordagens tradicionais não eram simplesmente “ruins”

É tentador contar a história do Agile como uma narrativa de vitória na qual equipes iterativas e esclarecidas substituíram um pensamento Waterfall obsoleto. Essa narrativa é simples demais para profissionais sérios. Métodos orientados por planos possuem pontos fortes, e muitos ambientes modernos ainda necessitam de elementos que parecem tradicionais: documentação regulatória, governança de arquitetura, análise de segurança, controles contratuais, orçamentos de longo prazo, evidências para auditoria, coordenação com hardware, aquisições e certificação de releases.

A verdadeira questão é a adequação ao contexto. Se os requisitos forem genuinamente estáveis, a solução for bem compreendida, o custo de mudança for alto e o feedback puder ser simulado ou validado com confiabilidade antes da implementação completa, mais planejamento antecipado pode reduzir riscos. Um componente de software embarcado em hardware regulamentado pode exigir rastreabilidade e verificação formais. Uma migração de dados com prazo legal fixo pode exigir um plano de corte altamente coordenado. A substituição de infraestrutura pode conter trabalho de execução previsível depois que a fase de descoberta estiver concluída.

Da mesma forma, Agile não elimina a necessidade de análise, projeto, testes ou planejamento. Ele altera o momento em que essas atividades acontecem e a forma como são integradas. A análise pode ocorrer continuamente. A arquitetura pode evoluir com restrições deliberadas. Os testes podem ser incorporados ao desenvolvimento. O planejamento pode ocorrer em múltiplos horizontes e ser revisado à medida que as evidências melhoram. A entrega pode acontecer em Incrementos menores. As disciplinas permanecem; o que muda é a topologia do feedback.

Essa distinção é importante para a PSM I porque o Scrum é deliberadamente leve. Ele não instrui uma equipe a abandonar documentação, arquitetura, governança, previsões ou competências especializadas. Fornece um framework para o desenvolvimento de produtos complexos no qual uma equipe pequena, multifuncional e autogerenciável produz Incrementos valiosos e utilizáveis e inspeciona frequentemente o progresso em direção aos objetivos. Práticas complementares podem existir ao redor e dentro do Scrum, desde que não prejudiquem o framework.

Um profissional maduro, portanto, evita o tribalismo metodológico. A lição do desenvolvimento anterior ao Agile não é “planejar é ruim”. A lição é que a quantidade e o horizonte do planejamento devem corresponder à previsibilidade do trabalho, e os planos devem permanecer subordinados às evidências quando a realidade muda.

radio_button_uncheckedshort_textDa previsão de longo prazo à aprendizagem em ciclos curtos

No fim da década de 1990, muitos profissionais já vinham experimentando alternativas ao desenvolvimento pesado e orientado por documentação. Ideias iterativas e incrementais não nasceram em 2001; a história do software contém muitos exemplos anteriores de desenvolvimento orientado por feedback. Métodos como Scrum, Extreme Programming, Crystal, Dynamic Systems Development Method, Adaptive Software Development e Feature-Driven Development representaram tentativas distintas de aumentar a capacidade de resposta e a entrega.

Quando dezessete profissionais se reuniram em Snowbird, Utah, em fevereiro de 2001, eles não estavam inventando a iteração do zero. Estavam articulando valores compartilhados entre abordagens que haviam evoluído por meio da prática. O Manifesto para o Desenvolvimento Ágil de Software resultante priorizou indivíduos e interações, software em funcionamento, colaboração com o cliente e resposta a mudanças - ao mesmo tempo em que reconheceu explicitamente o valor de processos, documentação, contratos e planos.

A palavra “Agile”, portanto, descreve uma mudança naquilo que recebe prioridade quando há tensão. Se documentação abrangente atrasa a aprendizagem obtida por meio de software em funcionamento, o software em funcionamento recebe maior ênfase. Se a adesão rígida ao plano entra em conflito com evidências novas e importantes, a resposta à mudança recebe maior ênfase. Se a interpretação contratual bloqueia a colaboração em torno de necessidades emergentes, a colaboração recebe maior ênfase. O objetivo não é ausência de estrutura; é uma estrutura que ajude as pessoas a aprender e entregar em condições de incerteza.

O Scrum expressa essa mudança por meio de um ciclo delimitado. Uma Sprint cria um horizonte curto. Uma Product Goal fornece direção de longo prazo. Uma Sprint Goal cria foco sem exigir que cada detalhe permaneça fixo. Um Incremento utilizável fornece evidência concreta. Os eventos Scrum criam oportunidades formais para inspecionar e adaptar. Assim, o framework responde ao problema do feedback tardio não apenas com previsões melhores, mas com contato repetido entre planos e realidade.

Compreender essa progressão é mais valioso do que memorizar uma tabela intitulada “Waterfall versus Agile”. Organizações reais são misturas. Elas possuem contratos, orçamentos, compliance, descoberta de produto, experimentação técnica, planejamento trimestral, restrições operacionais e equipes com diferentes graus de incerteza. A competência profissional consiste em reconhecer onde a previsão é confiável, onde a aprendizagem é necessária e como projetar feedback rápido o suficiente para que premissas incorretas não se transformem em compromissos caros.

radio_button_uncheckedshort_textExemplo prático: a mesma funcionalidade bancária em dois sistemas de desenvolvimento

Imagine que um banco deseje introduzir uma nova funcionalidade em seu aplicativo móvel: os clientes devem poder agendar transferências recorrentes para contatos e receber uma previsão clara de quando cada transferência será processada.

A ideia parece simples. O banco espera forte adoção e inicialmente define o projeto como uma iniciativa de nove meses.

Em uma abordagem tradicional orientada por planos, os primeiros meses podem concentrar-se nos requisitos. Analistas entrevistam áreas de negócio, compliance, segurança, operações, atendimento ao cliente e especialistas em pagamentos. Uma grande especificação é aprovada. Em seguida, arquitetos projetam serviços, modelos de dados, fluxos de integração e tratamento de falhas. O desenvolvimento começa depois que decisões importantes de projeto são estabelecidas como linha de base. Equipes de teste preparam casos com base na especificação enquanto aguardam uma versão integrada. Uma versão piloto torna-se disponível para usuários de negócio no oitavo mês.

Nesse momento, a interação real revela três surpresas. Primeiro, os clientes interpretam “recorrente” de maneiras diferentes: muitos querem regras como “o primeiro dia útil depois que o salário cair”, e não apenas uma data fixa no calendário. Segundo, a data prevista de processamento torna-se confusa quando fins de semana e feriados bancários interagem. Terceiro, a tela original de confirmação oculta tarifas e regras de cancelamento de modo que gera desconfiança. Nenhum desses problemas significa necessariamente que os profissionais anteriores foram descuidados. São descobertas produzidas ao ver e utilizar o produto real.

O projeto ainda pode se adaptar, mas a adaptação agora é cara. O modelo de dados das transferências recorrentes pressupõe agendamentos por calendário. APIs, tabelas de banco de dados, casos de teste, procedimentos operacionais e documentação do usuário dependem dessa premissa. A equipe precisa abrir solicitações de mudança, estimar impactos, revisar cronogramas e possivelmente adiar o lançamento. Oito meses de trabalho dependente amplificaram uma premissa que poderia ter sido testada muito antes.

Agora imagine a mesma iniciativa administrada em torno de ciclos de aprendizagem mais curtos. A equipe ainda analisa compliance, segurança, arquitetura e restrições de pagamentos, mas, em vez de tentar finalizar toda a solução primeiro, identifica as premissas de maior risco. Em uma iteração inicial, produz um protótipo ou Incremento enxuto e seguro que demonstra a criação do agendamento e a previsão da data usando regras realistas. Stakeholders e usuários selecionados interagem com ele. A equipe aprende imediatamente que o comportamento em dias úteis é confuso e que alguns usuários pensam em termos do recebimento do salário, e não de datas.

Esse feedback altera o Product Backlog antes que a arquitetura esteja profundamente comprometida com um único modelo de agendamento. A equipe pode executar um experimento técnico para agendamentos baseados em eventos, refinar a interface com o usuário e esclarecer qual capacidade gera valor suficiente para uma primeira liberação. Os testes não são adiados para o fim; testes automatizados e exploratórios evoluem junto com a funcionalidade. Segurança e preocupações operacionais são tratadas continuamente porque a equipe precisa que cada Incremento atenda a um padrão de qualidade acordado.

A segunda abordagem não garante sucesso. A equipe ainda pode tomar decisões ruins, subestimar a complexidade ou receber feedback enganoso. Sua vantagem é outra: erros importantes têm menos tempo para se acumular. A organização aprende enquanto o custo de mudar de direção ainda é comparativamente pequeno.

Essa é a mentalidade relevante para o Scrum. O Scrum não promete que uma Sprint de duas semanas tornará previsível um trabalho incerto. Ele cria um mecanismo para tornar a incerteza visível e revisar repetidamente os planos com base no que foi aprendido.

radio_button_uncheckedshort_textUm modelo mental simples para a prova e para o trabalho real

Ao analisar um cenário de desenvolvimento, faça cinco perguntas: (1) Quanto é realmente conhecido? (2) Quais premissas ainda precisam de evidências? (3) Quanto tempo falta até a equipe receber feedback significativo? (4) Quanto trabalho pode tornar-se dependente de uma premissa errada antes que esse feedback chegue? (5) O plano pode ser adaptado sem tratar a aprendizagem como fracasso?

Essas perguntas ajudam a separar previsibilidade de uma certeza apenas desejada. Elas também preparam você para conceitos posteriores da PSM I. Os eventos Scrum não são reuniões adicionadas por cerimônia; eles criam um ritmo regular de inspeção e adaptação. O Incremento não é apenas um artefato de entrega; ele torna o progresso e a qualidade concretos. A Sprint Goal não é um contrato de escopo fixo em miniatura; ele fornece foco ao mesmo tempo em que permite que o plano exato evolua. A autogestão não é ausência de responsabilização; ela coloca decisões de planejamento próximas das pessoas que realizam o trabalho e aprendem com ele.

Quando se compreende o custo do feedback tardio, esses elementos deixam de parecer arbitrários. Tornam-se partes de um sistema coerente de controle para trabalhos complexos.

radio_button_uncheckedshort_textConclusão: a verdadeira mudança foi da proteção de premissas para as evidências

O desenvolvimento de software anterior ao Agile era frequentemente organizado em fases sequenciais, funções especializadas, planejamento extensivo antecipado, linhas de base detalhadas e controle formal de mudanças. Essas práticas eram tentativas de criar ordem em projetos cada vez maiores e mais caros. Ofereciam clareza, documentação, responsabilização e uma linguagem para orçamentos e cronogramas. Em trabalhos suficientemente previsíveis, muitas dessas capacidades continuam úteis.

A fragilidade aparece quando se espera que os planos eliminem incertezas que só podem ser resolvidas por meio de construção, integração, interação com stakeholders e uso real. O desenvolvimento de software não equivale à produção industrial repetitiva. É, em grande medida, trabalho do conhecimento: a equipe descobre o problema e a solução enquanto cria o produto. Requisitos podem mudar porque os stakeholders aprendem. Projetos técnicos podem mudar porque a tecnologia ensina algo novo à equipe. Mercados podem mudar porque o mundo não espera pelo plano do projeto.

Ciclos longos de feedback ampliam essas incertezas. Uma premissa equivocada sobrevive por mais tempo, atrai mais decisões dependentes e torna-se mais cara de reverter. Integração tardia cria grandes lotes de defeitos. Exposição tardia aos usuários cria o risco de construir corretamente a coisa errada. Feedback operacional tardio transforma a implantação em um evento de alto risco. O custo não é apenas técnico; é também organizacional e psicológico, porque investimentos maiores criam maior resistência à mudança.

O Agile surgiu de anos de experimentação com maneiras diferentes de administrar essa realidade. Sua contribuição mais importante não foi uma coleção de cerimônias nem uma rejeição ao planejamento. Foi uma mudança na relação entre planejamento e evidência. Planos continuam úteis, mas precisam ser testados por resultados em funcionamento e revisados quando novas informações surgem.

Minha avaliação é que essa é a forma mais produtiva de estudar a história. Não aprenda “Waterfall ruim, Agile bom”. Aprenda as condições sob as quais a previsão funciona e as condições sob as quais a aprendizagem empírica se torna essencial. Essa distinção fará com que conceitos posteriores do Scrum - Sprints, Goals, Incrementos, inspeção, adaptação, autogestão e valor - pareçam menos regras para memorizar e mais respostas a um problema concreto de gestão.

Da próxima vez que você se deparar com um belo plano de software de longo prazo, não pergunte se planejar está errado. Faça uma pergunta mais precisa: em quanto tempo a realidade poderá desafiar as premissas contidas nesse plano? A resposta dirá mais sobre a capacidade de aprendizagem do projeto do que o número de páginas de seu cronograma.

radio_button_uncheckedshort_textPrincipais conclusões

• Projetos de software tradicionais normalmente separavam requisitos, análise, projeto, implementação, testes e entrega em fases sequenciais e funções especializadas.
• O planejamento extensivo antecipado é mais confiável quando requisitos, tecnologia, dependências e resultados desejados são suficientemente previsíveis.
• A governança orientada por planos pode criar forte controle sobre atividades e, ainda assim, atrasar a comprovação de que o produto gera valor.
• O desenvolvimento de software difere da produção industrial repetitiva porque consiste principalmente em criação de conhecimento e resolução de problemas, e não em fabricar repetidamente uma unidade já conhecida.
• Ciclos longos de feedback permitem que premissas incorretas acumulem trabalho dependente, tornando correções tardias mais caras e politicamente mais difíceis.
• Agile não rejeitou planejamento, documentação, processos ou contratos; mudou as prioridades quando esses mecanismos entram em conflito com aprendizagem, colaboração, software em funcionamento e adaptação.
• O Scrum utiliza empirismo e ciclos curtos de inspeção e adaptação para lidar com trabalhos complexos nos quais conhecimentos importantes surgem durante o desenvolvimento.

radio_button_uncheckedshort_textVocabulário essencial

radio_button_uncheckedshort_textReferências e leituras complementares

• Agile Manifesto - History A história oficial descreve a reunião de Snowbird, em fevereiro de 2001, e os métodos leves representados pelos dezessete signatários.
• Manifesto for Agile Software Development Os quatro valores afirmam explicitamente que os itens à direita continuam tendo valor, ao mesmo tempo em que os itens à esquerda recebem maior prioridade.
• National Academies - Achieving Effective Acquisition of Information Technology in the Department of Defense Fornece contexto histórico sobre Royce, o modelo sequencial e o fato de que Royce não defendeu simplesmente um processo Waterfall rígido.
• Open University - From waterfall to iterative development Resume o processo sequencial Waterfall, seu apelo gerencial e os riscos do feedback tardio e de requisitos em mudança.
• Royce, Winston W. - Managing the Development of Large Software Systems (1970) Referência histórica fundamental associada às discussões sobre ciclos de vida sequenciais de software e à necessidade de feedback que reduza riscos em sistemas de grande porte. Artigo original de conferência, 1970