No filme A princesa prometida, o personagem do pirata Roberts está subindo em uma corda, que é cortada por Vizzini. Quando Roberts não cai, Vizzini diz: "Ele não caiu? INCONCEBÍVEL!" Inigo Montoya responde: "Você está sempre usando essa palavra. Acho que ela não tem o sentido que você pensa que tem."

Quando converso com as pessoas sobre o conceito de Agilidade, eu me sinto como Montoya na cena acima. Fico pensando se estamos falando sobre a mesma coisa. Não quer dizer que eu esteja certo e eles, errados. Só quero dizer que há muita confusão em torno do uso atual do termo Agilidade. ¹ O pessoal no segmento de mercado de software tem o hábito de usar as palavras com o significado que querem atribuir a elas, em especial quando se trata de terminologia técnica nova. Até certo ponto isso é compreensível, afinal, nossas tecnologias mudam tão rápido que o número de novos termos e acrônimos que aparecem quase diariamente dificulta acompanhá-los. Com isso, ficamos um pouco relaxados com os termos que usamos e esperamos estar mais ou menos certos.

Embora o conceito de Agilidade esteja em uso há algum tempo, muitos acadêmicos e profissionais o usam de forma incorreta.

Neste mês, gostaria de apresentar uma pesquisa de opinião sobre a paisagem Agile. Para começar, porém, precisamos estabelecer uma definição para o termo. Isso não é fácil. De fato, não sei se consigo dar conta do recado, mas vou tentar. Vamos começar com os primeiros princípios e depois ver como eles costumam ser distorcidos pelas pessoas que desenvolveram uma definição pessoal para Agilidade. Depois de chegarmos a um consenso sobre uma definição (espera-se), faremos resenhas sobre alguns livros e referências úteis para se embrenhar no universo de Agile.

No princípio...

Antes de fevereiro de 2001, a palavra "ágil" tinha o sentido de "que se move ou age com muita facilidade, destreza e rapidez" ou "que age ou trabalha com eficiência e rapidez". ² Em 2001 essa palavra começou a significar algo mais específico para os desenvolvedores de software. Um grupo de dezessete pessoas que se autointitulam anarquistas organizacionais,³ , mas eram principalmente consultores de software e líderes no campo de ideias para o desenvolvimento de software, se reuniu em Snowbird, Utah, e definiu o desenvolvimento de software Agile. Agile era uma base em comum com a qual concordavam, embora cada participante tivesse suas próprias ideias sobre como desenvolver softwares de alta qualidade.

O acordo de base comum resultante da reunião em Snowbird é o Manifesto Agile.⁴ Já analisei esse manifesto, mas vale a pena repetir os quatro valores definidos nele porque nos dão a base para entender o sentido intencionado para a Agilidade (com 'A' maiúsculo). Esses valores são fraseados como preferências de um aspecto do desenvolvimento de software após o outro:

1. Os indivíduos e suas interações acima de processos e ferramentas.
2. O software em funcionamento acima da documentação abrangente.
3. A colaboração dos clientes acima da negociação de contratos.
4. A capacidade de resposta a mudanças acima de se seguir um plano.

E é isso. Parece bem simples e direto. Mas resultou em mais equívocos e interpretações diferentes do que qualquer outra palavra de que consigo me lembrar. Por quê? Consigo listar pelo menos três razões.

Primeiramente, as pessoas entendem a palavra "ágil" como é usada comumente. Quando falamos em desenvolvimento Agile, os ouvintes ouvem essa palavra e, como mencionado na introdução, aplicam sem próprio filtro semântico e acreditam que estamos falando que algo que se move com rapidez, algo com mudanças constantes e frequentes. Sem dúvida, muitos de nossos projetos de software mudam e se movem rapidamente, mas nem todos. Naturalmente, o mesmo problema ocorreria se os participantes em Snowbird escolhessem qualquer outra palavra já definida para descrever sua abordagem de desenvolvimento de software. Na época, muitos pensaram em usar leve para diferenciá-lo dos processos considerados pesados que, achavam, eram empurrados para cima das organizações de desenvolvimento pelas grandes empresas de consultoria.

Segundo, mesmo quando as pessoas sabem que há um sentido diferente para a palavra Agile, elas têm sua própria definição. Talvez tenham lido artigos ou livros sobre desenvolvimento Agile e tentaram implementar algumas práticas que tornariam seus projetos mais Agile (de acordo com a sua definição). Infelizmente, as pessoas tendem a distorcer o sentido desejado para o termo Agile, e isso inclui até alguns especialistas ou pessoas que estão envolvidas no movimento Agile já há algum tempo. Basta assistir a uma conferência sobre Agile e verá o que quero dizer. Muitos chegaram à conclusão de que agilidade é como a arte: "Eu sei o que é quando vejo" e "É uma definição muito pessoal". Na conferência de Agile 2006, alguém disse que tinham implementado Agile "completo". Quando perguntei o que isso significava, sua definição foi de que estavam fazendo testes de unidade e integração contínua. Essas são práticas que podem ser aplicadas em suporte aos quatro valores, mas que não são, em si mesmas, Agile.

A razão final vem da declaração de valores. Pensou-se muito em como frasear os valores, mas muitas pessoas olham para eles e questionam -- com razão -- as dicotomias incorporadas neles. Por exemplo, "documentação abrangente" é o completo oposto de "software em funcionamento"? Os valores parecem dar a entender que esses dois aspectos são opostos, mas não há justificação lógica para isso. Assim, dispomos de quatro pares de valores, cada qual colocado em oposição aos outros quatro pelos criadores do Manifesto Agile. Meu propósito aqui não é discutir a validade das escolhas feitas, mas simplesmente dizer que não se pode considerar Agile a menos que concorde com os pares propostos, decidindo valorizar o primeiro valor acima do segundo em cada par. Se decidirmos que documentação abrangente é comparada mais adequadamente com indivíduos e interações, estritamente falando, não temos vocabulário para discutir Agilidade de forma comparativa. Essa é a terceira razão para a confusão ao falarmos de Agilidade. Muitos não concordam com os pares iniciais.

Abordagem científica

Uma das melhores maneiras de abordar qualquer assunto, novo ou bem estabelecido, é começar com as definições e, em seguida, por meio de análise rigorosa e questionamento, ver aonde isso nos leva. Vamos fazer isso com a Agilidade.

Se considerarmos o Manifesto Agile como o documento de origem, podemos determinar que qualquer organização ou projeto que deseja ser Agile deve valorizar as características mencionadas primeiro em cada um dos quatro valores (p.ex., "colaboração dos clientes") mais do que as características mencionadas em segundo lugar (p.ex., "negociação de contratos"). Alistair Cockburn me disse certa vez que Agilidade é uma posição em um universo de dezesseis posições possíveis. O que ele quis dizer é que, se considerarmos cada par de valores, temos a opção de valorizar o primeiro valor mais do que o segundo ou não. É uma decisão binária. Visto que há quatro pares, há dezesseis configurações possíveis. Acho que essa é a maneira mais simples e clara de encarar a Agilidade. Isso evita o problema de tentar distinguir entre graus de Agilidade. Usando a descrição de Cockburn, podemos decidir se uma organização ou projeto é Agile ou não. Se a organização possui esses valores e os aplica ao seu modo de operação, ela é Agile. Caso contrário, não é Agile.

Também podemos abordar a Agilidade por um ponto de vista negativo, com as devidas desculpas a Jeff Foxworthy.⁵ Se valorizamos o uso de processos e ferramentas tanto quanto ou mais do que interações de indivíduos, não somos Agile. Se valorizamos a documentação abrangente tanto quanto ou mais do que software em funcionamento, não somos Agile. Se valorizamos as negociações de contratos tanto quanto ou mais do que colaboração dos clientes, não somos Agile. Se valorizamos seguir um plano tanto quanto ou mais do que responder a mudanças, não somos Agile.

A chave do texto acima é notar que não é preciso valorizar características não Agile mais do que as características Agile. Basta valorizá-las pelo menos tanto quanto as características Agile. Se estiver trabalhando em um projeto de engenharia de sistema, acho que valorizaria apegar-se ao plano tanto quanto responder a mudanças. Estará lidando com hardware e software e precisará trabalhar muito para uni-los de acordo com o planejamento. Talvez seja fácil mudar o software, mas mudar o hardware costuma ser difícil, se não impossível.

Então, deixe-me dizer o seguinte -- e aguentar as críticas da comunidade Agile: não há problema em não ser Agile. Agilidade não é algo pelo qual tenhamos de nos empenhar por si só. É apenas algo pelo qual podemos nos empenhar se fizer sentido para nosso projeto e organização. Ao falar com muitos na comunidade Agile, vemos que eles entendem e concordam com isso. Mas, como o evangelizador que recebeu uma visão e quer compartilhá-la, eles vêm com tanta força que o zelo deles por essas crenças às vezes nos deixa sem fala.

Uma coisa é dizer que possui certos valores, mas outra bem diferente é por em prática esses valores. Os autores do manifesto incluíram um conjunto de princípios a seguir por quem quer ser Agile. ⁶ Se seguir os princípios no modo em que executa seu trabalho, estará exibindo um comportamento Agile.

Agora, vamos chegar a um acordo sobre a definição que usaremos para Agile e Agilidade no restante deste documento. Agilidade é definida como apegar-se aos valores estabelecidos no Manifesto Agile e seguir o conjunto de princípios acompanhantes -- nada mais e nada menos do que isso.

Qual foi o erro?

A definição que mencionei acima é simples demais. Por que então há tanta confusão e pontos de vista conflitantes sobre se uma organização ou projeto é ou não é Agile? Parte do problema é que os princípio são mencionados de uma forma que deixa muita margem para interpretação e implementação desses princípios. Vejamos alguns deles.

Um princípio diz: "Desenvolver projetos ao redor de indivíduos motivados. Dê a eles o ambiente e suporte necessário, e confie que farão seu trabalho." Como implementar esse prática? Primeiro, pergunte-se o que é um indivíduo motivado? Algumas pessoas são motivadas apenas por ganho financeiro. Outras são motivadas por fazer parte de uma ótima equipe. Os indivíduos motivados de uma equipe podem atrapalhar outra equipe. Quando há um conjunto de talentos pré-selecionado por sua organização, talvez não seja possível ter os indivíduos que se ajustam à sua definição de motivação em sua equipe do projeto. Ainda é possível ser Agile?

Outro princípio diz: "Processos Agile promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter indefinidamente um ritmo constante." É óbvio que se nossos padrões forem bem baixos e trabalharmos muito pouco esse será um ritmo que poderemos manter indefinidamente. Evidentemente essa não é a intenção do princípio.

Poderíamos pegar a maioria dos princípios individualmente e distorcê-los um pouco para ir contra o espírito de Agilidade. Mas quando encarados em conjunto, eles tendem a apoiar uns aos outros. Contudo, ainda há muita margem para implementar os princípios. Isso abriu um mercado lucrativo para treinadores, consultores, metodologistas de Agile e outros que querem ajudar uma organização a tornar-se Agile e adotar o tipo de Agilidade defendido pelo consultor. Também levou muitas organizações a adotar novas práticas e alegar que atingiram a Agilidade de acordo com a interpretação do metodologista.

Ter uma interpretação para Agilidade é fácil. Chegar a uma interpretação válida pode ser mais difícil. Não existe um oráculo único ao qual possamos recorrer para saber definitivamente se nosso projeto ou organização é Agile. A pergunta que realmente precisamos fazer é: E isso importa? Se estivermos produzindo de forma eficaz software que atende a todas as necessidades de nossos interessados, está tudo certo. Sempre é preciso tentar melhorar, mas será que para isso realmente precisamos nos ajustar a qualquer rótulo que seja? Esse tem sido um problema ao tentar seguir CMM e CMMI, RUP e outras metodologias. As pessoas e organizações ficam focadas demais em serem "certificadas" em determinado nível em vez de se concentrarem no objetivo definitivo -- entregar o software. As metodologias e práticas são maios, não o fim em si.

OK, se é tão simples assim...

Uma pergunta feita na conferência Agile2006, em Minneapolis, foi "Se Agilidade é tão simples, por que existem tantos livros para explicar como alcançá-la?" Isso foi dito com certa ironia, mas há uma questão séria por trás da pergunta. No meu escritório na faculdade, tenho uma prateleira quase completamente dedicada a livros da categoria Agile. Há mais de trinta deles. Tenho mais cerca de uma dúzia em casa. É muita coisa escrita. Por que tantos livros sobre Agilidade?

A resposta simples é que livros são uma ótima maneira de os consultores venderem seus próprios serviços. É também uma maneira de acadêmicos e profissionais expressarem seus conceitos sobre um tópico. Os livros influenciam as pessoas e têm efeito sobre o que há de mais atual e sobre as práticas. Sempre que são descobertos novos conceitos, é natural que surjam livros, journals e artigos a respeito. Para que esses conceitos tenham um grande efeito, são organizadas conferências. O setor de tecnologia é um terreno especialmente fértil para ideias e os livros inspirados nelas porque, como observei no início deste artigo, é difícil para nós no segmento de mercado de TI -- lutando para concluir projetos, cumprindo prazos, mantendo-nos dentro do orçamento e, ao mesmo tempo, tentando satisfazer nossos clientes -- acompanhar as maneiras mais recentes de atingir nossos objetivos sem ajuda de boa qualidade e autoguiada.

A segunda resposta é que muitos autores que afirmam ter uma nova abordagem para um tópico parecem ser bem-sucedidos em publicar seus livros. Em resultado, cada livro se propõe a apresentar algo novo e interessante sobre as interpretações dos autores sobre os valores e princípios. Muitos deles apresentam um modo que leva à implementação dos princípios e valores. Como muitos livros de autoajuda, eles alegam que nos tornaremos Agile se seguirmos seu programa. Quem já tentou diferentes dietas, programas de relaxamento, programas de melhoria da leitura, e assim por diante, sabe que o que funciona para uma pessoa não funciona para outra. O mesmo acontece com muitos livros sobre a Agilidade. Um método talvez funcione para o projeto A, mas falha miseravelmente para o projeto B. Cada projeto e organização precisa encontrar seu próprio caminho para a Agilidade, se for apropriado ser Agile.

Agilidade onipresente

Atualmente a agilidade está em toda parte. É o éter que rodeia o desenvolvimento de software. Se vale a pena o tempo e o esforço de aprender e aplicar determinada prática, ela deve ser Agile. Para aprender e usar uma ferramenta em nossos projetos, ela deverá oferecer suporte à Agilidade. Essa é uma questão de marketing mais do que uma questão de conteúdo em si. Agile é como a nova marca de tênis que queremos comprar para ajudar nossas equipes de desenvolvimento a saltar mais alto e correr mais rápido.

Eu estava em uma livraria um dia desses e peguei um livro sobre a linguagem de programação Ruby. Na capa de trás, dizia assim: "Ruby é uma linguagem de programação Agile e orientada a objetos." ..." Tiveram o bom senso de não colocar o 'a' em maiúsculo na palavra "Agile", embora eu não saiba dizer se o leitor mediano perceberia ou se importaria com isso. Será que Ruby realmente inclui o conjunto de valores expresso no Manifesto Agile? Essa pergunta soa ridícula, e de fato é. Mas agora estamos falando em marketing, e nem sempre a lógica é a coisa mais importante nesses casos. Use a palavra "Agile" para captar a atenção do seu cliente e, assim, ganhe reconhecimento. (Espero que algum dia possamos ter clientes mais inteligentes que farão as perguntas certas e colocarão a Agilidade na perspectiva certa.)

Não sou contra a Agilidade. Também não sou o que alguns chamam de Agilista. Gosto de pensar que sou pragmático e que uso o que me ajuda e descarto o que não ajuda. Às vezes, a Agilidade funciona. Às vezes preciso de algo diferente. Acho que essa é a melhor posição a tomar.

Principais livros e metodologias sobre Agile

Gostaria de usar o restante deste artigo para fornecer uma breve descrição de livros sobre Agile que considero importantes. Vou comentar porque acho que cada um é importante e o que ele tem a oferecer. Vou apresentar uma lista que começa com um panorama amplo -- livros que tratam principalmente de Agilidade em geral, seus valores e princípios. Daí, vou focar cada vez mais metodologias e práticas específicas.

Livros sobre valores e princípios Agile

Agile Software Development: the Cooperative Game, 2ed., Alistair Cockburn, Addison-Wesley Professional, 2006, ISBN 0321482751.

Alistair Cockburn escreve bem. Esse livro fornece uma das melhores descrições de Agilidade do ponto de vista de um dos promotores originais do Agile. A escrita é clara e bem equilibrada. Cockburn descreve Agilidade e a coloca em perspectiva em relação a outros lugares no espectro de valores. Ele indica com muita habilidade o ponto ideal dos métodos Agile, por que funcionam e os benefícios que se obtém deles.

O tratamento de Cockburn não é técnico. Ele não entra em questões de codificação nem em um monte de detalhes. Ele fornece material suficiente para ficarmos bem informados sobre Agilidade. Cockburn é conhecido por seu foco em questões interpessoais no desenvolvimento de software e gasta bastante tempo discutindo os aspectos pessoais da Agilidade. Recomendo esse livro para quem não sabe nada sobre desenvolvimento de software Agile.

Agile & Iterative Software Development A Manager's Guide, Craig Larman, Addison-Wesley, 2004, ISBN 0131111558.

Craig Larman é especialista no desenvolvimento de software, especialmente práticas orientadas a objetos. Ele conhece profundamente diferentes metodologias e sabe como e quando aplicá-las. Nesse livro, Larman analisa métodos iterativos, Scrum, XP, RUP e Evo. Scrum e XP estão basicamente na área de Agile, enquanto RUP e Evo ficam mais no campo iterativo tradicional (impulsionado por planos). Larman compara e contrasta as diferentes metodologias para ajudar os leitores a avaliar seus benefícios e decidir o tipo de processo melhor para tipos específicos de projetos e organizações.

A comparação das metodologias vem na última metade do livro. Os primeiros seis capítulos são o que esse volume tem de melhor. Nesses capítulos, Larman analisa de forma crítica o desenvolvimento de software, a agilidade, o desenvolvimento iterativo e apresenta ao leitor provas do uso de métodos Agile e iterativos. Essas provas vêm de pesquisas, experiência e outras fontes. Larman evidentemente se preparou muito bem.

Balancing Agility and Discipline A Guide for the Perplexed, Barry Boehm e Richard Turner, Addison-Wesley, 2004, ISBN 0321186125.

Esse livro será interessante para gerentes que vêm de grandes organizações e projetos ou têm uma sólida formação em engenharia de software (não em desenvolvimento de software). ⁷ Boehm e Turner são acadêmicos com experiência em grandes projetos, muitos deles no segmento de mercado de defesa. Eles apresentam o tópico ao tentar identificar os lugares onde cada tipo de metodologia pode ser usado da melhor maneira possível -- os pontos ideais. Boehm é mais conhecido por seu desenvolvimento do modelo COCOMO de estimativa de projeto e escreveu muitos trabalhos de impacto sobre a engenharia de software, incluindo aquele que apresenta o desenvolvimento iterativo. ⁸

O principal problema que tenho com o livro é que não confio muito que Boehm ou Turner já tenha trabalhado no tipo de projeto ao qual costumo me dedicar. Ou seja, aqueles que têm menos de 100.000 linhas de código. Eles concentram suas pesquisas em grandes projetos nos quais a engenharia de software tradicional é eficaz. Mesmo assim, acho importante ler esse livro, visto que ele aborda a Agilidade de uma perspectiva diferente da maioria dos outros livros desta lista.

Livros sobre metodologias Agile

Agile Software Development with Scrum, Ken Schwaber e Mike Beedle, Prentice Hall, 2001, ISBN 0130676349.

Nos últimos anos, Scrum recebeu bastante atenção. É um método muito simples para o gerenciamento de projeto e tem uma leve conexão com o desenvolvimento de software. Na maior parte, o Scrum consiste em algumas práticas que não são novas, mas que são implementadas de forma rigorosa. Os defensores do Scrum afirmam ter grande sucesso na aplicação dele a projetos de desenvolvimento de software de todos os tamanhos. Não há práticas na metodologia que eu consideraria práticas técnicas. São todas sobre gerenciamento de projeto.

Esse livro descreve a metodologia Scrum nas palavras dos inventores dele, Schwaber e Beedle. Uma das coisas interessantes sobre Scrum é que suas práticas podem ser aplicadas em conjunto com a maioria das outras práticas. Vale a pena ler esse livro para entender um pouco como os projetos Agile devem abordar o gerenciamento de projeto.

Extreme Programming Explained: Embrace Change, 2ed., Kent Beck com Cynthia Andres, Addison-Wesley Professional, 2004, ISBN 0321278658.

Esse livro, na primeira edição, provavelmente teve mais impacto no lançamento do movimento Agile do que qualquer outro. De fato, muitos profissionais passaram a considerar Extreme Programming (XP) como sendo Agile. Para o desenvolvedor de software, XP é a metodologia que trata melhor dos problemas que os interessam. Beck, ajudado por Andres na segunda edição, descreve as práticas fundamentais que ele determinou ser a mais usada -- ou considera ser a mais usada -- metodologia Agile entre desenvolvedores de software. Menciono que acredita ser a mais usada porque há poucas organizações que realmente podem aplicar todas as práticas à sua situação, mas ainda afirmam usar XP.

A segunda edição desse livro é maior do que a primeira, mas, na minha opinião, não acrescenta nada muito útil. A edição mais recente acrescenta mais material sobre estratégias e modificações na metodologia XP básica. É uma pena. Se conseguir um exemplar da primeira edição e não tem experiência em métodos Agile, recomendo lê-la para entender o que é XP.

Extreme Programming Installed, Ron Jeffries, Ann Anderson e Chet Hendrickson, Addison-Wesley Professional, 2000, ISBN 0201708426.

Esse é o segundo volume do dilúvio de livros relacionados a XP publicados pela Addison-Wesley. Vale a pena lê-lo porque ele descreve as práticas de XP e como são usadas pelos membros da equipe do projeto original do XP. ⁹ O livro é muito fácil de ler e dá para ter uma boa ideia de como é trabalhar em um projeto XP. Esse livro foi o que me convenceu de que a aplicação de 100% de práticas de XP não era o tipo de projeto em que eu escolheria trabalhar. Também ajudou a me convencer de que havia algumas práticas excelentes que eu precisava aprender. Embora XP tenha evoluído, esse é um ótimo livro para uma equipe inexperiente ler antes de se empenhar em um projeto com XP pela primeira vez.

Livros específicos de prática

Test Driven Development: A Practical Guide, David Astels, Prentice Hall Ptr, 2003, ISBN 0131016490.

Acredito que o desenvolvimento orientado a testes (TDD) é uma das práticas mais importantes que surgiu do movimento Agile. Ela enfatiza a qualidade e a responsabilidade pela qualidade por parte do desenvolvedor. Ela exige foco em qualidade durante todo o ciclo de desenvolvimento, independentemente da metodologia aplicada. Esse livro é uma ótima introdução a TDD. Foi ele que ajudou a me convencer de seu poder que ultrapassa os simples testes.

Pragmatic Unit Testing in Java with JUnit, Andrew Hunt e David Thomas, The Pragmatic Programmers, LLC, 2003, ISBN 0974514012.

Ele complementa o livro anterior com sugestões muito práticas sobre como realmente implementar a prática de TDD. A Pragmatic Programmers publica uma série excelente de livros que falam diretamente aos desenvolvedores de software sobre tópicos relacionados à mais recente tecnologia. Esse livro é uma de suas primeiras publicações e é leitura obrigatória para qualquer programador Java que queira ser bom em escrever testes de unidade. Ele coloca o teste de unidade no contexto de TDD e dá ao leitor todas as ferramentas necessárias para escrever, gerenciar e automatizar ótimos testes de unidade.

User Stories Applied, Mike Cohn, Addison-Wesley Professional, 2004, ISBN 0321205685.

Histórias de usuários parecem ser o veículo de especificação de requisitos escolhido por muitos projetos Agile, embora outras abordagens, como casos de uso, sejam aceitáveis. A história do usuário é uma pequena funcionalidade que pode ser descrita pelo cliente em um cartão de índice. Isso se ajusta à abordagem de iteração muito pequena do XP e outros métodos Agile. Como no caso da escrita de casos de uso, a escrita de histórias do usuário é uma qualificação que deve ser aprendida e praticada. Mike Cohn fornece a melhor introdução à escrita de histórias de usuários que já vi. Seu livro sobre histórias de usuários é aquilo que o livro de Alistair Cockburn é para os casos de uso. ¹⁰ Para quem trabalha com casos de uso e não leu o livro de Cockburn, Cohn fornece um curso completo de como escrever e aplicar histórias de usuários ao seu projeto. Ele usa muitos exemplos e sua experiência em projetos reais fica evidente. Analistas que estejam, mesmo que remotamente, interessados em histórias de usuários devem ler esse livro.

Planning Extreme Programming, Kent Beck e Martin Fowler, Addison-Wesley Professional, 2000, ISBN 0210710919.

Oura prática fundamental para projetos de XP é o jogo de planejamento. Esse é um conjunto de atividades bastante simples que ajuda o cliente e a equipe a decidir o que entra em cada iteração, como estimar o esforço e como acompanhar os resultados para melhorar sua capacidade de fazer estimativas. Beck e Fowler se saem muito bem na descrição de práticas de um modo que interessará desenvolvedores, gerentes e todos os outros membros de uma equipe de XP.

Diversos

A seguir dois livros que não se encaixam nas categorias acima, mas que achei úteis e sempre consulto. Usei o segundo como livro de estudo em meu curso de engenharia de software que ensino duas vezes por ano.

Agile Software Development Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall, 2002, ISBN 0135974445.

Esse é um livro de desenvolvedor escrito por um desenvolvedor de desenvolvedores. Bob Martin é um grande desenvolvedor com profundo entendimento dos princípios orientados a objetos e Agile. Nesse livro, o Tio Bob reúne os dois e fornece aos desenvolvedores uma grande proeza em matéria de princípios de design orientado a objetos e insight de como usá-los em um projeto Agile. Ele deveria estar na biblioteca de todo desenvolvedor.

Extreme Software Engineering: A Hands-On Approach, Daniel H. Steinberg e Daniel W. Palmer, Prentice Hall, 2003, ISBN 013047812.

Esse é um livro pequeno que fornece um quadro bastante equilibrado sobre projetos Agile, com preferência por XP. Não é dogmático em sua abordagem e tenta mostrar que a Agilidade não é uma abordagem casual no desenvolvimento de software, nem uma desculpa para fazer as coisas de um jeito antigo. Percebi que meus alunos consideram esse livro fácil de ler, e ele me deixa muito tempo para enfatizar os aspectos de desenvolvimento de software que considero importantes. É uma ótima leitura para um fim de semana.

Conclusão

A Agilidade está em toda parte. Ignore-a e fique perdido em meio ao diálogo técnico atual. Aprenda sobre ela e seja capaz de tomar decisões inteligentes quanto se ela é adequada para você. Será capaz também de entender muitas outras práticas e metodologias emergentes. No caso de gerentes de tecnologia em qualquer nível, essa é a responsabilidade deles, bem como um passo necessário para sua sobrevivência.

Eu incentivo todos a começar a estudar os livros que listei acima, bem como outros livros de autores como Mary Poppendieck (desenvolvimento Lean), Scott Ambler (bancos de dados), Jim Highsmith (práticas de gerenciamento) e outros escritores contribuíram diretamente para o movimento Agile ou desenvolveram princípios e práticas que "funcionam bem" com as equipes e projetos Agile. Espero que, como eu, meus leitores encontrem alguns livros que lhes forneçam ideias para tentar com sua equipe, seus projetos e sua organização. Sem dúvida, eles encontrarão muitos livros descartáveis -- não por estarem errados, mas porque não se ajustam às suas necessidades. Seja um consumidor em informado e seu valor para usa organização será maior.

Notas

¹ Usarei a palavra com inicial maiúscula para distingui-la do uso comum da palavra. Essa é uma convenção usada pelos membros da comunidade Agile.

² Segundo o dicionário Aulete Digital. http://aulete.uol.com.br/.

³ Veja a história do Manifesto Agile. http://www.agilemanifesto.org/history.html.

⁴ http://www.agilemanifesto.org.

⁵ Jeff Foxworthy é um comediante conhecido por fazer piadas no formato: "Se você ..., você é um caipira" (referindo-se especificamente a um membro da classe trabalhadora rural do sul dos EUA, considerada ignorante).

⁶ http://manifestoagil.com.br/principios.html.

⁷ Consulte minha coluna de dezembro de 2005 onde mostro quais são as diferenças na minha opinião. http://www.ibm.com/developerworks/rational/library/dec05/pollice/index.html.

⁸ Barry Boehm, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, agosto de 1986.

⁹ O projeto que lançou o milésimo livro :-) foi o do Sistema de Compensação Abrangente da Chrysler, iniciado em 1995. Esse é considerado o projeto onde todas as práticas de XP foram aplicadas, registradas e refinadas na metodologia que agora chamamos de XP.

¹⁰ Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley Professional, 2000, ISBN 0201702258. Quem trabalha com casos de uso e não leu esse livro não sabe o que está perdendo.

Sobre o autor

Gary Pollice é professor de prática do Worcester Polytechnic Institute, em Worcester, MA, EUA. Ele ensina engenharia, design e teste de software, além de outros cursos de Ciência da Computação, direcionando também os projetos dos alunos. Antes de entrar para o mundo acadêmico, ele passou mais de 35 anos desenvolvendo vários tipos de software, de aplicativos de negócios a compiladores e ferramentas. Seu último trabalho dentro do segmento de mercado foi com IBM Rational Software, onde era conhecido como "o ranzinza do RUP", além de ser membro da equipe original do Rational Suite. Ele é o autor principal de Software Development for Small Teams: A RUP-Centric Approach, publicado pela Addison-Wesley em 2004. Ele é bacharel em matemática e tem mestrado em Ciência da Computação.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• No princípio...
• Abordagem científica
• Qual foi o erro?
• OK, se é tão simples assim...
• Agilidade onipresente
• Principais livros e metodologias sobre Agile
• Conclusão
• Notas
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais