Como a busca da indústria de software por formas de trabalho mais leves e adaptativas convergiu em Snowbird, em 2001 - e por que o Ágil é um conjunto de valores e princípios, e não uma metodologia única.
Tempo estimado de leitura: 20 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Compreender o contexto do desenvolvimento de software na década de 1990, o surgimento dos chamados , os problemas que seus criadores procuravam resolver, a reunião de Snowbird em fevereiro de 2001, o nascimento do Manifesto para o Desenvolvimento de Software e a distinção fundamental entre o como conjunto de valores e princípios compartilhados e qualquer método ou framework específico, como ou .
Introdução: o não começou com uma reunião
O não criou a necessidade de adaptação. Ele deu um nome e uma linguagem comum a aprendizados que profissionais já vinham construindo havia anos.
É tentador contar a história do como uma narrativa de origem simples e bem definida: dezessete profissionais de software se reuniram em uma estação de esqui em Utah, em 2001, escreveram um manifesto e, então, nasceu uma nova forma de desenvolver software. A reunião de fato ocorreu, o Manifesto exerceu uma influência extraordinária e a data é importante. No entanto, essa versão simplificada esconde a lição mais útil. O não foi inventado do nada em Snowbird. Snowbird foi o momento em que diferentes correntes de prática, frustração, experimentação e aprendizado profissional finalmente encontraram uma linguagem em comum.
Ao longo da década de 1990, muitas organizações de software enfrentavam uma incompatibilidade entre a forma como os projetos eram gerenciados e a maneira como o conhecimento sobre o software realmente surgia. Planos extensos prometiam controle. prometia clareza. Fases especializadas prometiam eficiência. Procedimentos formais de mudança prometiam estabilidade. Ainda assim, as equipes constatavam repetidamente que os requisitos mudavam, que os usuários só descobriam do que realmente precisavam depois de ver o , que integrações se comportavam de maneira diferente da prevista nas especificações, que estimativas perdiam validade à medida que as premissas mudavam e que revelavam problemas acumulados durante meses.
Isso não significava que todo projeto tradicional fracassasse, nem que a disciplina de engenharia fosse a inimiga. O problema mais profundo era que a indústria frequentemente tentava gerenciar o desenvolvimento incerto de produtos como se fosse um processo de produção previsível. Os capítulos anteriores mostraram por que essa postura se torna perigosa em trabalhos complexos.
Na década de 1990, profissionais de diferentes comunidades chegaram, de forma independente, a uma conclusão semelhante: o desenvolvimento de software precisava de ciclos de feedback mais curtos, colaboração mais próxima, práticas técnicas mais robustas, lotes menores de trabalho e maior capacidade de adaptação à medida que o conhecimento evoluía.
Essas abordagens foram inicialmente descritas com expressões como “” ou “metodologias leves”. O nome era imperfeito. “Leve” poderia soar como falta de seriedade, como se o rigor estivesse sendo removido, quando, na verdade, estava sendo deslocado para outros pontos do processo. Muitas dessas abordagens eram altamente disciplinadas. , por exemplo, enfatizava práticas como testes automatizados, , e participação próxima do cliente. enfatizava controle empírico, e incremental e oportunidades frequentes de inspeção e adaptação. Outras abordagens enfrentavam problemas semelhantes por perspectivas diferentes.
O ofereceu a esse movimento diverso um vocabulário compartilhado. Ele não eliminou as diferenças entre seus participantes. Em vez disso, identificou aquilo que, após anos desenvolvendo software, eles aprenderam a valorizar com maior intensidade. Para quem se prepara para a , essa história é importante porque e são relacionados, mas não são intercambiáveis. já existia antes do Manifesto. é um framework específico. , no sentido estabelecido pelo Manifesto, é um conjunto mais amplo de valores e princípios que influenciou a forma como as pessoas compreendem o desenvolvimento adaptativo de software. Entender essa distinção evita um dos erros conceituais mais comuns no ensino de : tratar o como se fosse um processo de marca registrada, com um único fluxo de trabalho universal.
A indústria de software dos anos 1990: pressão por uma abordagem diferente
A década de 1990 foi um período de profundas transformações tecnológicas e comerciais. A computação pessoal se expandiu, arquiteturas cliente-servidor tornaram-se comuns, a programação orientada a objetos ganhou influência, interfaces gráficas elevaram as expectativas dos usuários, sistemas corporativos passaram a conectar mais funções de negócio e a Internet pública transformou tanto a distribuição de software quanto o ritmo da concorrência. O software deixou de ser apenas um componente de apoio oculto em ambientes administrativos e, cada vez mais, passou a fazer parte da forma como as organizações competiam, se comunicavam, vendiam e atendiam seus clientes.
Ao mesmo tempo, muitas organizações de desenvolvimento utilizavam modelos de processo influenciados pela engenharia preditiva e pela gestão de grandes projetos. Esperava-se, com frequência, que os requisitos fossem substancialmente definidos antes da construção. Análise e design buscavam reduzir a incerteza antecipadamente. Desenvolvimento podia ser separado de testes e operações. O progresso podia ser representado por documentos, marcos, conclusão de fases ou relatórios de percentual concluído muito antes de os usuários terem software funcional relevante para avaliar.
Essas abordagens respondiam a necessidades organizacionais reais. Grandes programas exigem coordenação. Contratos exigem escopo e responsabilização. Ambientes críticos para a segurança exigem evidências. Empresas precisam de arquitetura, orçamento, conformidade e governança. O problema não era a existência de planejamento ou documentação. O problema era usar esses mecanismos como substitutos do feedback. Quando uma organização só conseguia observar software útil perto do final de um projeto, premissas equivocadas podiam sobreviver por meses enquanto os planos continuavam aparentando estar saudáveis.
O aumento do ritmo comercial tornou essa limitação ainda mais evidente. Um requisito escrito seis meses antes podia já não refletir as prioridades dos clientes. Um concorrente podia alterar o mercado. Uma nova plataforma ou tecnologia podia mudar a viabilidade econômica de um design. Um projeto podia entregar exatamente o que havia sido especificado e, ainda assim, entregar tarde demais, resolver o problema errado ou impor uma experiência de uso que ninguém desejava. A indústria precisava de formas de manter a disciplina de engenharia e, ao mesmo tempo, reduzir o intervalo entre uma decisão e as evidências sobre essa decisão.
Esse contexto também revelou a natureza social do desenvolvimento de software. Software é criado por meio de trabalho do conhecimento: pessoas interpretam necessidades ambíguas, fazem escolhas de design, descobrem restrições, resolvem conflitos e se comunicam continuamente. Tratar como unidades de produção intercambiáveis ignorava a importância da experiência, da conversa, da motivação e da compreensão compartilhada. Por isso, várias abordagens emergentes passaram a ser explicitamente orientadas às pessoas, além de adaptativas. Elas não perguntavam apenas como programar o trabalho de outra forma, mas também que tipo de organização permite que pessoas qualificadas resolvam problemas difíceis em conjunto.
A ascensão dos
Antes que a palavra “” se tornasse o termo abrangente, profissionais utilizavam expressões como “”. O ensaio “The New Methodology”, publicado por Martin Fowler em julho de 2000, registrou bem aquele momento: várias comunidades já exploravam abordagens que contrastavam com metodologias consolidadas e mais preditivas. Fowler destacou duas características recorrentes - adaptabilidade e orientação centrada nas pessoas - e não simplesmente a quantidade literal de documentação ou de processo.
O cenário era diverso. havia sido desenvolvido no início da década de 1990 por Jeff Sutherland e Ken Schwaber e foi apresentado formalmente ao público na OOPSLA, em 1995. , associado especialmente a Kent Beck e ao projeto Chrysler C3, em meados dos anos 1990, combinava ciclos de desenvolvimento muito curtos com práticas de engenharia exigentes. Dynamic Systems Development Method, , Adaptive Software Development, Feature-Driven Development, ideias de programação pragmática e outras abordagens ofereciam diferentes combinações de princípios e técnicas.
Esses métodos não concordavam em tudo. Alguns prescreviam práticas técnicas de engenharia. Outros se concentravam mais fortemente na gestão de projetos ou de produtos. Alguns variavam de acordo com o tamanho da equipe ou com a criticidade do sistema. Outros eram propositalmente mínimos. Essa diversidade é importante: o movimento não surgiu porque um único grupo descobriu um processo perfeito. Ele surgiu porque vários grupos enfrentavam problemas relacionados e percebiam aprendizados que se sobrepunham.
Um desses aprendizados era que requisitos nem sempre poderiam ser tratados como um contrato completo com o futuro. Outro era que fornece informações que especificações não conseguem fornecer. Outro ainda era que representantes de negócio e profissionais técnicos precisam colaborar com frequência, em vez de se comunicarem principalmente por documentos e transferências de trabalho. Também se percebeu que a qualidade não pode ser adiada para uma fase distante de testes sem aumento de risco e que as equipes precisam de autonomia suficiente para adaptar seu trabalho à medida que a realidade muda.
Chamar essas abordagens de “leves” levou alguns críticos a presumir que seus defensores se opunham a planejamento, arquitetura, documentação ou disciplina. Os relatos históricos dos autores do rejeitam diretamente essa interpretação. O movimento buscava equilíbrio. As abordagens emergentes continuavam planejando; apenas reconheciam os limites da de longo prazo em ambientes turbulentos. Continuavam documentando; questionavam a documentação que se desvinculava da comunicação útil. Continuavam projetando; preferiam designs capazes de evoluir com o aprendizado, em vez de tentar eliminar toda incerteza antes da implementação.
Essa distinção é especialmente relevante para . é deliberadamente leve, mas leve não significa vago. O framework estabelece accountabilities, eventos, artefatos, compromissos e regras claros, ao mesmo tempo em que deixa muitas técnicas de implementação a cargo das pessoas que realizam o trabalho. A finalidade dessas restrições é criar um sistema empírico confiável, e não um roteiro burocrático.
Profissionais diferentes, problemas semelhantes
As pessoas que mais tarde assinariam o vinham de contextos e métodos distintos, mas respondiam a famílias reconhecíveis de problemas. Compreender esses problemas é mais útil do que memorizar uma lista de nomes, porque as mesmas tensões ainda aparecem nas organizações atuais.
O primeiro problema era o valor entregue tardiamente. Projetos podiam consumir orçamentos substanciais antes que os usuários recebessem algo utilizável. Quando a entrega ocorria em grandes lotes, o negócio esperava mais tempo pelos benefícios e a equipe esperava mais tempo por evidências significativas. Entregas frequentes ofereciam uma forma de reduzir ambos os atrasos.
O segundo problema era o aprendizado tardio. Se o surgisse apenas perto do final, mal-entendidos sobre requisitos, design, integração, usabilidade e viabilidade técnica poderiam permanecer ocultos. Iterações curtas transformavam o desenvolvimento em um processo repetido de aprendizado: construir algo relevante, inspecionar o que aconteceu e, em seguida, ajustar.
O terceiro problema era o custo da mudança. Abordagens preditivas frequentemente tentavam controlar mudanças por meio de baselines mais rígidas e mecanismos de aprovação. Os métodos emergentes buscavam reduzir o custo técnico e organizacional da mudança, de modo que a adaptação se tornasse economicamente viável. Práticas como testes automatizados, ,, design simples, planejamento iterativo e priorização frequente contribuíam, cada uma à sua maneira.
O quarto problema era a comunicação por repasses entre especialidades. Quando analistas, designers, programadores, testadores, clientes e gestores operavam como etapas separadas, a informação podia se degradar em cada fronteira. As abordagens leves, de modo geral, ampliavam a colaboração direta e encurtavam a distância entre quem compreendia o problema de negócio e quem criava o software.
O quinto problema era o falso progresso. Um projeto podia estar “80% concluído” segundo o plano, enquanto o produto integrado continuava inutilizável. As abordagens emergentes passaram a atribuir maior peso a resultados demonstráveis e funcionais. Essa mudança do foco em atividade para o foco em evidência se tornaria uma das ideias mais reconhecíveis associadas ao desenvolvimento de software.
Por fim, esses profissionais lidavam com o aspecto humano do trabalho complexo. A resolução criativa de problemas não se comporta como uma linha de montagem. Equipes precisam de confiança, competência técnica, comunicação rápida e espaço para tomar decisões locais. O desafio não era eliminar a gestão, mas criar condições em que as pessoas pudessem responder de forma inteligente às informações, em vez de esperar que cada ajuste percorresse uma estrutura centralizada de comando.
Snowbird, Utah: fevereiro de 2001
De 11 a 13 de fevereiro de 2001, dezessete profissionais se reuniram no The Lodge at Snowbird, nas montanhas Wasatch, em Utah. Segundo a história oficial do , o encontro reuniu representantes e defensores ligados a ,,, Adaptive Software Development, , Feature-Driven Development, programação pragmática e abordagens relacionadas. Eles buscavam um terreno comum entre métodos que muitas vezes eram reunidos sob o rótulo insatisfatório de “leves”.
A reunião não surgiu sem preparação. Um encontro anterior, organizado por Kent Beck no Oregon em 2000, já havia reunido profissionais de e alguns participantes externos, e as conversas sobre abordagens leves circulavam havia algum tempo. Ainda em 2000, Robert C. Martin propôs reunir os líderes dessas abordagens em um mesmo ambiente. Seguiram-se discussões, inclusive sobre o nome e até mesmo sobre o local do encontro. Snowbird acabou se tornando o cenário do acordo que moldou a identidade do movimento.
O resultado mais marcante não foi uma metodologia combinada. Dezessete profissionais com convicções fortes não tentaram fundir ,,, e todos os demais métodos em um processo gigantesco. Em vez disso, formularam um pequeno conjunto de valores compartilhados e, depois, um conjunto de princípios de apoio. O resultado recebeu o nome de Manifesto para o Desenvolvimento de Software.
A palavra “” foi importante porque descrevia uma qualidade desejada pelo grupo: capacidade de resposta e adaptação, sem sugerir que o trabalho fosse trivial ou “leve” em sentido depreciativo. O novo nome ajudou um conjunto de abordagens relacionadas a se tornar um movimento reconhecível. A Alliance também foi criada para dar continuidade à difusão dessas ideias.
Para estudantes, a data de fevereiro de 2001 é fácil de memorizar. O fato mais importante, porém, é conceitual: Snowbird foi um ato de síntese. Os signatários observaram suas diferentes práticas e perguntaram quais crenças fundamentais compartilhavam. É por isso que o Manifesto se expressa por meio de valores, e não de um diagrama de processo.
O Manifesto para o Desenvolvimento de Software: uma declaração de preferência
O Manifesto é intencionalmente curto. Seus autores afirmaram que estavam descobrindo maneiras melhores de desenvolver software por meio da própria prática e ajudando outras pessoas a fazê-lo. Eles expressaram quatro declarações de valor em pares. Em cada par, ambos os lados têm valor, mas os autores atribuíram maior ênfase ao lado relacionado à colaboração humana, aos resultados utilizáveis, à parceria com o cliente e à capacidade de responder a mudanças.
Essa estrutura é frequentemente mal compreendida. O não afirma que não têm valor. Não afirma que a documentação deve desaparecer. Não afirma que contratos sejam irrelevantes. Não afirma que planejar seja desperdício. A frase final da declaração de valores preserva explicitamente o valor dos itens que recebem menor ênfase. O ponto central é a prioridade: quando os dois lados entram em tensão, o movimento aprendeu que o desenvolvimento eficaz de software frequentemente depende mais de interação, resultados funcionais, colaboração e adaptação.
Os doze princípios por trás do Manifesto ampliam essa lógica. Eles enfatizam entrega antecipada e contínua de software valioso, aceitação de mudanças nos requisitos, entregas frequentes, colaboração diária entre negócio e , pessoas motivadas, comunicação eficaz, como uma medida fundamental de progresso, ,, simplicidade, e reflexão periódica seguida de ajuste.
Considerados em conjunto, valores e princípios formam uma teoria coerente de aprendizado. Ciclos curtos de entrega produzem evidências. A colaboração melhora a interpretação dessas evidências. A mantém o produto modificável. A simplicidade limita investimentos desnecessários. conseguem agir sobre o conhecimento local. A reflexão melhora o próprio sistema de trabalho. Portanto, não significa simplesmente “ir mais rápido”. Sua promessa mais profunda é melhorar a capacidade da organização de aprender e responder enquanto produz continuamente software útil.
Isso também explica por que transformações Ágeis superficiais frequentemente decepcionam. Renomear um gerente de projetos como “”, transformar documentos de requisitos em tickets, criar um quadro ou agendar reuniões diárias não torna necessariamente uma organização adaptativa. Se o feedback continuar chegando tarde, as decisões permanecerem centralizadas, for raro, a qualidade for adiada e os planos não puderem mudar quando as evidências mudarem, o vocabulário pode ser , mas o modelo operacional continua preditivo.
como mentalidade e princípios - não como uma metodologia específica
Um dos conceitos mais importantes para quem estuda para a é que não é uma metodologia única com uma sequência universal de etapas. O Manifesto não define papéis, eventos, artefatos, duração de iterações, técnicas de estimativa, formatos de backlog, colunas de quadro ou ferramentas de engenharia. Ele fornece valores e princípios. Métodos e frameworks diferentes podem materializar essas ideias de maneiras distintas.
Chamar de “mentalidade” é uma forma moderna e comum de resumir essa orientação mais ampla. A palavra “mentalidade” não aparece como componente formal do Manifesto de 2001 e, por isso, não deve ser tratada como uma regra oficial adicional. Usada com cuidado, porém, é útil: descreve uma preferência por aprendizado, colaboração, valor para o cliente, qualidade técnica e tomada de decisão adaptativa em vez de adesão rígida a um plano inicial. Uma mentalidade influencia a forma como as pessoas interpretam situações; um método oferece estruturas e práticas mais concretas.
é um desses frameworks concretos, mas e não são sinônimos. já era praticado e descrito antes de 2001. Ken Schwaber e Jeff Sutherland estavam entre os dezessete signatários do Manifesto, e se alinha fortemente aos valores e . Ainda assim, possui sua própria definição no Scrum Guide. Ele especifica uma com três accountabilities, cinco eventos formais dentro da , três artefatos e seus compromissos, além de uma base empírica. Nenhuma dessas estruturas é definida pelo próprio .
oferece outro exemplo. também é associado ao , mas inclui um conjunto diferente e mais explícito de práticas de engenharia. Uma organização pode utilizar em conjunto com práticas complementares de engenharia influenciadas por . Também pode seguir sem utilizar . No sentido inverso, uma equipe pode imitar a mecânica visível de e, ainda assim, comportar-se de formas que enfraquecem os valores adaptativos associados ao .
Essa distinção não é uma curiosidade acadêmica. Ela altera a forma de raciocinar sobre questões de prova e sobre organizações reais. Se alguém perguntar “ exige um ?”, a resposta é não: o é um evento do . Se alguém perguntar “ exige histórias de usuário?”, a resposta também é não: histórias de usuário são uma técnica amplamente utilizada, mas não são uma exigência do . Se alguém perguntar se responder a mudanças é compatível com , a resposta é sim, no nível de seus valores e princípios. Um vocabulário claro evita que práticas se transformem em dogmas acidentais.
Exemplo prático: duas equipes, a mesma mudança de requisito
Imagine duas equipes de software desenvolvendo uma solicitação de empréstimo on-line. No início da iniciativa, ambas acreditam que os clientes se sentirão confortáveis em preencher um formulário de doze etapas antes de receber qualquer indicação de elegibilidade. No meio do desenvolvimento, uma pesquisa com usuários revela um padrão forte: muitos clientes abandonam o processo porque desejam uma estimativa inicial antes de fornecer informações detalhadas.
A Equipe A segue uma interpretação fortemente orientada pelo plano. O fluxo de doze etapas foi aprovado, projetado, documentado e distribuído entre vários grupos especializados. Alterá-lo agora exige solicitação formal, análise de impacto, aprovação orçamentária, redesenho e replanejamento. Os gestores temem que aceitar a descoberta faça o projeto parecer fora de controle. Assim, a equipe conclui o plano original e pretende tratar o abandono dos usuários em uma versão futura.
A Equipe B trabalha a partir de uma orientação . Ela também possui objetivos, restrições orçamentárias, arquitetura, requisitos de conformidade e um plano. Entretanto, o plano é tratado como um meio para gerar valor, e não como o próprio valor. A nova evidência desencadeia uma conversa entre profissionais de produto e de tecnologia. Eles identificam um experimento menor: fornecer antecipadamente um resultado indicativo de elegibilidade usando um conjunto mínimo de dados, medir conversão e compreensão dos clientes e, então, decidir como adaptar o restante da jornada.
A diferença não é que a Equipe B aceite toda solicitação imediatamente. Capacidade de resposta não significa escopo sem controle. A equipe avalia a evidência em relação ao objetivo do produto, ao valor de negócio, ao risco, ao custo e às implicações técnicas. O que muda é a relação padrão com o aprendizado. Novas informações não são tratadas automaticamente como ameaça ao plano; são tratadas como uma possível entrada valiosa para a próxima decisão.
Agora conecte esse cenário ao . Uma poderia tornar o novo aprendizado transparente por meio do refinamento do e da colaboração com stakeholders. O poderia ajustar a ordenação do com base em valor e aprendizado. Durante uma , e poderiam renegociar o escopo à medida que mais informações surgissem, desde que a não fosse colocado em risco. Uma poderia inspecionar o e o feedback do mercado ou dos usuários, orientando o que fazer a seguir. oferece uma estrutura empírica concreta por meio da qual a preferência mais ampla por responder a mudanças pode ser praticada profissionalmente.
Essa é a materialização essencial do pensamento : não otimize para obedecer perfeitamente às premissas de ontem. Otimize para resultados valiosos, criando caminhos curtos da ideia à evidência e da evidência à adaptação.
Por que essa história importa para a
A é uma avaliação de , e não uma prova de história do . Ainda assim, compreender este capítulo evita vários erros que aparecem repetidamente no aprendizado de . Primeiro, não surgiu como consequência do ; ele é anterior ao encontro de 2001. Segundo, não define . O Scrum Guide define . Terceiro, não prescreve práticas populares simplesmente porque equipes Ágeis as utilizam com frequência.
A história também torna mais fácil compreender o do . O movimento que convergiu em Snowbird reagia a ciclos longos de feedback, planos rígidos, colaboração fraca com clientes e estruturas de processo capazes de ocultar o estado real de um produto. enfrenta essas tensões por meio de transparência, inspeção, adaptação, Sprints curtas, Increments utilizáveis, accountabilities claras e um emergente. O framework não é uma tradução do Manifesto em cerimônias, mas o alinhamento filosófico é evidente.
Ao raciocinar em questões de prova, evite substituir por afirmações vagas como “ diz que devemos ser flexíveis”. Flexibilidade, por si só, não é suficiente. cria limites disciplinados. Uma tem duração fixa. A qualidade não pode diminuir. A fornece foco. As accountabilities não podem simplesmente ser redistribuídas porque um gestor prefere outra estrutura. A adaptação ocorre dentro de um framework concebido para tornar a mudança útil, e não caótica.
Um candidato bem preparado, portanto, mantém três camadas separadas: valores e ; como framework definido; e práticas opcionais utilizadas por determinada organização ou equipe. Quando essas camadas ficam claras, muitas questões aparentemente difíceis tornam-se problemas de classificação: isto é exigido pelo ? É compatível com o pensamento , mas opcional? Ou é apenas uma prática local que pode ou não ser útil?
Conclusão: um nome para um movimento que já estava aprendendo
O movimento surgiu de anos de experimentação, e não de uma única invenção teórica. Durante a década de 1990, profissionais de software enfrentaram pressão crescente provocada por tecnologias em mudança, mercados mais rápidos, requisitos incertos, feedback tardio, repasses de trabalho dispendiosos e limites de modelos de desenvolvimento altamente preditivos. Diferentes comunidades responderam com métodos frequentemente chamados de leves porque reduziam processos desnecessários e ampliavam adaptação, colaboração e entrega de .
Em fevereiro de 2001, várias dessas abordagens já haviam amadurecido o suficiente para que dezessete profissionais se reunissem em Snowbird e identificassem um terreno comum. A conquista deles não foi uma metodologia universal. Foi uma declaração compacta de valores e princípios que nomeou aquilo que a experiência lhes havia ensinado a priorizar. O Manifesto para o Desenvolvimento de Software deu ao movimento uma identidade e um vocabulário compartilhados que se difundiram muito além das pessoas presentes naquela sala.
, portanto, é melhor compreendido como uma orientação ampla para o desenvolvimento de software: valorizar pessoas e colaboração, buscar resultados reais e funcionais, envolver clientes de forma próxima e manter a capacidade de responder quando a realidade invalida o plano. Essas ideias são sustentadas por princípios relacionados a entregas frequentes, , trabalho sustentável, simplicidade, e . Frameworks e métodos específicos oferecem mecanismos diferentes para colocar essas ideias em prática.
Na minha visão, o legado mais importante do movimento não é a velocidade. É a humildade intelectual combinada com ação disciplinada. reconhece que o trabalho complexo com software contém incerteza e, então, pede às equipes que exponham essa incerteza por meio de entregas frequentes, feedback, colaboração e qualidade técnica. Substitui a ilusão de controle por uma relação mais estreita entre decisões e evidências.
Para um futuro , essa história oferece uma base útil. não é “reuniões Ágeis”, e não é “ sem regras”. é um framework empírico específico que pertence a uma tradição mais ampla de desenvolvimento adaptativo de produtos. Compreender de onde essa tradição veio torna mais fácil aplicar o framework com propósito, em vez de ritual, e prepara o estudante para aprofundar os valores e sem confundi-los com as .
Linha do tempo resumida: dos ao
Linha do tempo resumida: dos ao
Período
Desenvolvimento
Por que isso importa
Início dos anos 1990
é desenvolvido por Jeff Sutherland e Ken Schwaber.
Mostra que é anterior ao .
1994-1996
Métodos como e surgem ou assumem forma reconhecível; é apresentado na OOPSLA 1995.
Várias comunidades experimentam, de forma independente, maneiras adaptativas de entregar software.
Fim dos anos 1990
, Adaptive Software Development, Feature-Driven Development, ideias de programação pragmática, , e outras abordagens ganham visibilidade.
A categoria dos “” começa a se formar.
2000
Profissionais discutem pontos em comum em encontros e artigos; Martin Fowler publica “The New Methodology”.
Padrões compartilhados tornam-se visíveis antes de existir um nome comum.
11-13 fev. 2001
Dezessete profissionais se reúnem em Snowbird, Utah.
Eles sintetizam valores comuns em vez de fundir seus métodos.
De 2001 em diante
O Manifesto para o Desenvolvimento de Software e a Alliance dão ao movimento uma identidade reconhecível.
“” torna-se o termo abrangente para uma família mais ampla de abordagens adaptativas.
, e práticas de equipe: mantenha as camadas separadas
, e práticas de equipe: mantenha as camadas separadas
Camada
O que fornece
Exemplos
Valores e
Preferências amplas e princípios para o desenvolvimento adaptativo de software.
Colaboração, entrega frequente de valor, resposta a mudanças, , reflexão.
Um framework definido para gerar valor por meio de soluções adaptativas para problemas complexos.
Accountabilities da , Sprints, eventos, artefatos, compromissos, .
Práticas e ferramentas opcionais
Técnicas dependentes do contexto, selecionadas por equipes ou organizações.
Histórias de usuário, ,, quadros , fluxos no , ferramentas de /.
Mentalidade para a prova
Não responda a uma questão de dizendo: “ é flexível, então qualquer coisa pode mudar”. é adaptativo, mas possui regras explícitas, accountabilities, timeboxes, compromissos e expectativas de qualidade. Separe os dos requisitos do e das práticas opcionais.
Principais aprendizados
O movimento surgiu de experimentos práticos realizados durante a década de 1990; ele não foi criado do zero em 2001.
Os profissionais reagiam a feedback tardio, requisitos em mudança, repasses de trabalho dispendiosos, colaboração insuficiente com clientes e falsa certeza em planos preditivos.
Os “” incluíam abordagens distintas, como ,,,, Adaptive Software Development e Feature-Driven Development.
Dezessete profissionais se reuniram em Snowbird, Utah, de 11 a 13 de fevereiro de 2001 e produziram o Manifesto para o Desenvolvimento de Software.
O Manifesto expressa valores e princípios compartilhados, e não um processo universal de desenvolvimento de software.
é frequentemente descrito como uma mentalidade, mas o artefato oficial de 2001 é um conjunto de valores e princípios; o termo não deve ser confundido com uma metodologia específica.
é anterior ao e continua sendo um framework definido separadamente, embora sua abordagem empírica esteja fortemente alinhada aos valores e .
Histórias de usuário, ,, e técnicas semelhantes podem ser úteis, mas não são requisitos nem do nem do .
Vocabulário para pesquisa e estudo
Termos úteis para aprofundamento e preparação para a
história do movimento ; história do ; Snowbird 2001; de software; desenvolvimento de software; indústria de software nos anos 1990; história do ; história do ;; métodos ; Adaptive Software Development; Feature-Driven Development; valores e ;; versus ; desenvolvimento adaptativo de software; resposta a mudanças; ;;; desenvolvimento incremental; ; conceitos Ágeis para a .
Schwaber, Ken; Sutherland, Jeff. The Scrum Guide, novembro de 2020. - Definição oficial atual de e fonte para distinguir o dos mais amplos e das práticas opcionais de equipe.
Nota histórica
O desenvolvimento de software na década de 1990 era diverso; nem toda organização utilizava um processo rígido, e o existia muito antes do . Este capítulo descreve as tensões que motivaram o movimento dos sem sugerir que existia uma única prática universal antes do .
