Nós seguimos estes princípios:
Nossa maior prioridade é satisfazer o cliente
através da entrega contínua e adiantada
de software com valor agregado.
Mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando,
de poucas semanas a poucos meses,
com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário
e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de desenvolvimento
é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo
constante indefinidamente.
Contínua atenção à excelência técnica e bom design
aumenta a agilidade.
Simplicidade--a arte de maximizar a quantidade de
trabalho não realizado--é essencial.
As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
_História: O Manifesto Ágil
De 11 a 13 de fevereiro de 2001, na estação de esqui The Lodge at Snowbird, nas montanhas Wasatch de Utah, dezessete pessoas se reuniram para conversar, esquiar, relaxar e tentar encontrar um terreno comum - e, claro, comer. O que surgiu foi o Manifesto Ágil de 'Desenvolvimento de Software'. Representantes da Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e outros simpáticos à necessidade de uma alternativa aos processos de desenvolvimento de software pesados e orientados por documentação se reuniram.
Agora, uma reunião maior de anarquistas organizacionais seria difícil de encontrar, então o que emergiu dessa reunião foi simbólico – um Manifesto para o Desenvolvimento Ágil de Software – assinado por todos os participantes. A única preocupação com o termo ágil veio de Martin Fowler (um britânico para quem não o conhece) que permitiu que a maioria dos americanos não soubesse pronunciar a palavra "ágil".
As preocupações iniciais de Alistair Cockburn refletiam os primeiros pensamentos de muitos participantes. "Eu, pessoalmente, não esperava que esse grupo específico de agilitas chegasse a um acordo sobre algo substantivo." Mas seus sentimentos pós-reunião também foram compartilhados: "Falando por mim, estou encantado com o fraseado final [do Manifesto]. Fiquei surpreso que os outros parecessem igualmente encantados com a frase final. Então, concordamos em algo substantivo."
Nomeando-nos "The Agile Alliance", este grupo de pensadores independentes sobre desenvolvimento de software, e às vezes concorrentes entre si, concordou com o Manifesto para o Desenvolvimento Ágil de Software exibido na página de título deste site.
Mas, embora o Manifesto forneça algumas ideias específicas, há um tema mais profundo que move muitos, mas não todos, com certeza, membros da aliança. No final da reunião de dois dias, Bob Martin brincou que estava prestes a fazer uma declaração "mole". Mas, embora tingidos de humor, poucos discordavam dos sentimentos de Bob – de que todos nós nos sentíamos privilegiados por trabalhar com um grupo de pessoas que possuíam um conjunto de valores compatíveis, um conjunto de valores baseados na confiança e no respeito uns pelos outros e promovendo modelos organizacionais baseados em pessoas, colaboração e construção dos tipos de comunidades organizacionais nas quais gostaríamos de trabalhar. No fundo, acredito que os Metodologistas Ágeis são realmente sobre coisas "moles" – sobre entregar bons produtos aos clientes operando em um ambiente que faz mais do que falar sobre "pessoas como nosso ativo mais importante", mas na verdade "age" como se as pessoas fossem o mais importante, e perder a palavra "ativo". Então, em última análise, o aumento meteórico do interesse – e às vezes tremendas críticas – às Metodologias Ágeis é sobre o material mole de valores e cultura.
Por exemplo, acho que, em última análise, a Extreme Programming cresceu em uso e interesse, não por causa da programação em pares ou refatoração, mas porque, tomadas como um todo, as práticas definem uma comunidade de desenvolvedores livre da bagagem das corporações dilbertescas. Kent Beck conta a história de um trabalho inicial em que estimou um esforço de programação de seis semanas para duas pessoas. Depois que seu gerente realocou o outro programador no início do projeto, ele completou o projeto em doze semanas - e se sentiu péssimo consigo mesmo! O chefe – é claro – criticou Kent sobre o quão lento ele foi ao longo da segunda seis semanas. Kent, um tanto desanimado porque ele era um "fracasso" como programador, finalmente percebeu que sua estimativa original de 6 semanas era extremamente precisa – para 2 pessoas – e que seu "fracasso" era realmente o fracasso do gerente, na verdade, o fracasso da mentalidade padrão de processo "fixo" que tantas vezes assola nossa indústria.
Esse tipo de situação acontece todos os dias – marketing, ou gestão, ou clientes externos, clientes internos e, sim, até mesmo desenvolvedores – não querem tomar decisões difíceis de compensação, então impõem demandas irracionais por meio da imposição de estruturas de poder corporativo. Este não é apenas um problema de desenvolvimento de software, ele corre em todas as organizações dilbertescas.
Para ter sucesso na nova economia, para entrar agressivamente na era do e-business, do comércio eletrônico e da web, as empresas têm que se livrar de suas manifestações de Dilbert de make-work e políticas arcanas. Essa liberdade das inanidades da vida corporativa atrai os defensores das Metodologias Ágeis e assusta os mendigos (não se pode usar a palavra "merda" em um jornal profissional) dos tradicionalistas. Francamente, as abordagens ágeis assustam os burocratas corporativos – pelo menos aqueles que estão felizes empurrando o processo por causa do processo versus tentando fazer o melhor para o "cliente" e entregar algo oportuno e tangível e "conforme prometido" – porque eles ficam sem lugares para se esconder.
O movimento ágil não é anti-metodologia, na verdade, muitos de nós queremos restaurar a credibilidade da palavra metodologia. Queremos restabelecer o equilíbrio. Adotamos a modelagem, mas não para arquivar algum diagrama em um repositório corporativo empoeirado. Abraçamos a documentação, mas não centenas de páginas de tomos nunca mantidos e raramente usados. Planejamos, mas reconhecemos os limites do planejamento em um ambiente turbulento. Aqueles que rotulariam os proponentes do XP ou SCRUM ou qualquer outra Metodologia Ágil como "hackers" ignoram tanto as metodologias quanto a definição original do termo hacker.
A reunião no Snowbird foi incubada em uma reunião anterior de proponentes da Extreme Programming e alguns "outsiders", organizada por Kent Beck no Rogue River Lodge em Oregon na primavera de 2000. Na reunião de Rogue River, os participantes expressaram apoio a uma variedade de metodologias "Light", mas nada formal ocorreu. Durante o ano 2000 foram escritos vários artigos que referenciavam a categoria de processos "Leves" ou "Leves". Alguns desses artigos se referiam a "Metodologias leves, como Extreme Programming, Adaptive Software Development, Crystal e SCRUM". Nas conversas, ninguém gostou muito do apelido "Luz", mas ele parecia ficar por enquanto.
Em setembro de 2000, Bob Martin, da Object Mentor em Chicago, começou a próxima reunião com um e-mail; "Eu gostaria de convocar uma pequena conferência (de dois dias) no período de janeiro a fevereiro de 2001 aqui em Chicago. O objetivo desta conferência é reunir todos os líderes de métodos leves em uma sala. Todos vocês estão convidados; e eu estaria interessado em saber quem mais eu deveria abordar." Bob criou um site Wiki e as discussões se acirraram.
Logo no início, Alistair Cockburn pesou com uma epístola que identificava o descontentamento geral com a palavra 'Light': "Não me importo que a metodologia seja chamada de leve no peso, mas não tenho certeza se quero ser chamado de leve participando de uma reunião de metodologistas leves. De alguma forma, soa como um bando de pessoas magras e leves tentando se lembrar de que dia é."
O debate mais acirrado foi sobre localização! Havia uma preocupação séria com Chicago no inverno – frio e nada divertido de fazer; Snowbird, Utah – coisas frias, mas divertidas de se fazer, pelo menos para aqueles que esquiam de cabeça como Martin Fowler tentou no primeiro dia; e Anguilla, no Caribe – quente e divertida, mas demorada para chegar. No final, Snowbird e esqui venceram; no entanto, algumas pessoas – como Ron Jeffries – querem um lugar mais quente da próxima vez.
Esperamos que nosso trabalho conjunto como a Agile Alliance ajude outras pessoas em nossa profissão a pensar sobre desenvolvimento de software, metodologias e organizações, de maneiras novas – mais ágeis. Se assim for, cumprimos nossos objetivos.
luanvsky
commented
1 year ago
Manifesto para Desenvolvimento Ágil de Software
Princípios por trás do Manifesto Ágil
Nós seguimos estes princípios: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
_História: O Manifesto Ágil
De 11 a 13 de fevereiro de 2001, na estação de esqui The Lodge at Snowbird, nas montanhas Wasatch de Utah, dezessete pessoas se reuniram para conversar, esquiar, relaxar e tentar encontrar um terreno comum - e, claro, comer. O que surgiu foi o Manifesto Ágil de 'Desenvolvimento de Software'. Representantes da Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e outros simpáticos à necessidade de uma alternativa aos processos de desenvolvimento de software pesados e orientados por documentação se reuniram.
Agora, uma reunião maior de anarquistas organizacionais seria difícil de encontrar, então o que emergiu dessa reunião foi simbólico – um Manifesto para o Desenvolvimento Ágil de Software – assinado por todos os participantes. A única preocupação com o termo ágil veio de Martin Fowler (um britânico para quem não o conhece) que permitiu que a maioria dos americanos não soubesse pronunciar a palavra "ágil".
As preocupações iniciais de Alistair Cockburn refletiam os primeiros pensamentos de muitos participantes. "Eu, pessoalmente, não esperava que esse grupo específico de agilitas chegasse a um acordo sobre algo substantivo." Mas seus sentimentos pós-reunião também foram compartilhados: "Falando por mim, estou encantado com o fraseado final [do Manifesto]. Fiquei surpreso que os outros parecessem igualmente encantados com a frase final. Então, concordamos em algo substantivo."
Nomeando-nos "The Agile Alliance", este grupo de pensadores independentes sobre desenvolvimento de software, e às vezes concorrentes entre si, concordou com o Manifesto para o Desenvolvimento Ágil de Software exibido na página de título deste site.
Mas, embora o Manifesto forneça algumas ideias específicas, há um tema mais profundo que move muitos, mas não todos, com certeza, membros da aliança. No final da reunião de dois dias, Bob Martin brincou que estava prestes a fazer uma declaração "mole". Mas, embora tingidos de humor, poucos discordavam dos sentimentos de Bob – de que todos nós nos sentíamos privilegiados por trabalhar com um grupo de pessoas que possuíam um conjunto de valores compatíveis, um conjunto de valores baseados na confiança e no respeito uns pelos outros e promovendo modelos organizacionais baseados em pessoas, colaboração e construção dos tipos de comunidades organizacionais nas quais gostaríamos de trabalhar. No fundo, acredito que os Metodologistas Ágeis são realmente sobre coisas "moles" – sobre entregar bons produtos aos clientes operando em um ambiente que faz mais do que falar sobre "pessoas como nosso ativo mais importante", mas na verdade "age" como se as pessoas fossem o mais importante, e perder a palavra "ativo". Então, em última análise, o aumento meteórico do interesse – e às vezes tremendas críticas – às Metodologias Ágeis é sobre o material mole de valores e cultura.
Por exemplo, acho que, em última análise, a Extreme Programming cresceu em uso e interesse, não por causa da programação em pares ou refatoração, mas porque, tomadas como um todo, as práticas definem uma comunidade de desenvolvedores livre da bagagem das corporações dilbertescas. Kent Beck conta a história de um trabalho inicial em que estimou um esforço de programação de seis semanas para duas pessoas. Depois que seu gerente realocou o outro programador no início do projeto, ele completou o projeto em doze semanas - e se sentiu péssimo consigo mesmo! O chefe – é claro – criticou Kent sobre o quão lento ele foi ao longo da segunda seis semanas. Kent, um tanto desanimado porque ele era um "fracasso" como programador, finalmente percebeu que sua estimativa original de 6 semanas era extremamente precisa – para 2 pessoas – e que seu "fracasso" era realmente o fracasso do gerente, na verdade, o fracasso da mentalidade padrão de processo "fixo" que tantas vezes assola nossa indústria.
Esse tipo de situação acontece todos os dias – marketing, ou gestão, ou clientes externos, clientes internos e, sim, até mesmo desenvolvedores – não querem tomar decisões difíceis de compensação, então impõem demandas irracionais por meio da imposição de estruturas de poder corporativo. Este não é apenas um problema de desenvolvimento de software, ele corre em todas as organizações dilbertescas.
Para ter sucesso na nova economia, para entrar agressivamente na era do e-business, do comércio eletrônico e da web, as empresas têm que se livrar de suas manifestações de Dilbert de make-work e políticas arcanas. Essa liberdade das inanidades da vida corporativa atrai os defensores das Metodologias Ágeis e assusta os mendigos (não se pode usar a palavra "merda" em um jornal profissional) dos tradicionalistas. Francamente, as abordagens ágeis assustam os burocratas corporativos – pelo menos aqueles que estão felizes empurrando o processo por causa do processo versus tentando fazer o melhor para o "cliente" e entregar algo oportuno e tangível e "conforme prometido" – porque eles ficam sem lugares para se esconder.
O movimento ágil não é anti-metodologia, na verdade, muitos de nós queremos restaurar a credibilidade da palavra metodologia. Queremos restabelecer o equilíbrio. Adotamos a modelagem, mas não para arquivar algum diagrama em um repositório corporativo empoeirado. Abraçamos a documentação, mas não centenas de páginas de tomos nunca mantidos e raramente usados. Planejamos, mas reconhecemos os limites do planejamento em um ambiente turbulento. Aqueles que rotulariam os proponentes do XP ou SCRUM ou qualquer outra Metodologia Ágil como "hackers" ignoram tanto as metodologias quanto a definição original do termo hacker.
A reunião no Snowbird foi incubada em uma reunião anterior de proponentes da Extreme Programming e alguns "outsiders", organizada por Kent Beck no Rogue River Lodge em Oregon na primavera de 2000. Na reunião de Rogue River, os participantes expressaram apoio a uma variedade de metodologias "Light", mas nada formal ocorreu. Durante o ano 2000 foram escritos vários artigos que referenciavam a categoria de processos "Leves" ou "Leves". Alguns desses artigos se referiam a "Metodologias leves, como Extreme Programming, Adaptive Software Development, Crystal e SCRUM". Nas conversas, ninguém gostou muito do apelido "Luz", mas ele parecia ficar por enquanto.
Em setembro de 2000, Bob Martin, da Object Mentor em Chicago, começou a próxima reunião com um e-mail; "Eu gostaria de convocar uma pequena conferência (de dois dias) no período de janeiro a fevereiro de 2001 aqui em Chicago. O objetivo desta conferência é reunir todos os líderes de métodos leves em uma sala. Todos vocês estão convidados; e eu estaria interessado em saber quem mais eu deveria abordar." Bob criou um site Wiki e as discussões se acirraram.
Logo no início, Alistair Cockburn pesou com uma epístola que identificava o descontentamento geral com a palavra 'Light': "Não me importo que a metodologia seja chamada de leve no peso, mas não tenho certeza se quero ser chamado de leve participando de uma reunião de metodologistas leves. De alguma forma, soa como um bando de pessoas magras e leves tentando se lembrar de que dia é."
O debate mais acirrado foi sobre localização! Havia uma preocupação séria com Chicago no inverno – frio e nada divertido de fazer; Snowbird, Utah – coisas frias, mas divertidas de se fazer, pelo menos para aqueles que esquiam de cabeça como Martin Fowler tentou no primeiro dia; e Anguilla, no Caribe – quente e divertida, mas demorada para chegar. No final, Snowbird e esqui venceram; no entanto, algumas pessoas – como Ron Jeffries – querem um lugar mais quente da próxima vez.
Esperamos que nosso trabalho conjunto como a Agile Alliance ajude outras pessoas em nossa profissão a pensar sobre desenvolvimento de software, metodologias e organizações, de maneiras novas – mais ágeis. Se assim for, cumprimos nossos objetivos.
Jim Highsmith, pela Agile Alliance
©Jim Highsmith (2001) •__