Introdução à Agilidade

Original de 18/6/2010: Gestão 2.0

Eu retornei no último fim de semana de uma viagem a Baltimore, Maryland, onde palestrei na RailsConf. Foi um evento com grandes palestras, algumas voltadas não só a Ruby on Rails, mas à carreira de programação em geral. Uma delas foi de ninguém menos que Robert Martin, da Object Mentor. Eu traduzi um artigo dele no meu post anterior.

Recomendo assistir à palestra na íntegra.

Desde que comecei este blog, tento explicar as condições e dificuldades que um Gestor de Projetos enfrenta. Mas venho tomando cuidado para não repetir o termo “Agile” a todo momento. Estamos no meio de uma febre de “agilidade”. Todo CIO, CTO, gerente ou consultor, para parecer moderno, diz que sabe “Scrum” e que é “ágil”.

Isso tem um lado bom: algumas empresas talvez enfim adotem essas ideias do jeito certo. Tem também um lado ruim, e grande. Estamos queimando o nome “Agile” por causa de consultorias ruins que implementam tudo errado no cliente. O resultado é a percepção, entre os desavisados, de que “Agile não funciona”.

Pois bem, durante a RailsConf, tive a oportunidade de conversar e entrevistar o Robert Martin, cuja gravação você pode assistir abaixo:

Dessa entrevista, o trecho que quero apresentar é a história de como surgiu o “Agile”. Robert Martin, também conhecido como “Uncle Bob”, é programador há décadas, certamente mais do que qualquer um de nós. Nos anos 90 ele foi um dos que notaram o surgimento de metodologias “leves” ou “lean”. Muito disso derivava dos conceitos de manufatura que revolucionaram a indústria japonesa a partir dos anos 60.

Vários nomes de peso começaram a propor formas mais inteligentes de desenvolver software. Kent Beck com o Extreme Programming (XP); Ken Schwaber e Jeff Sutherland com o Scrum; Alistair Cockburn com o Crystal.

Todos seguiam uma linha parecida: iterações curtas, feedback constante e muita comunicação. Vendo esse padrão, Uncle Bob procurou Martin Fowler, outro nome forte no mundo de arquitetura de software, e juntos passaram a organizar uma reunião, convocando um grupo desses profissionais.

A lendária reunião aconteceu na estação de esqui de Snowbird, em Utah, entre 11 e 13 de fevereiro de 2001. Dezessete profissionais passaram três dias ali e saíram com o “Manifesto Ágil”. Ele reúne 4 valores e 12 princípios que todos os participantes aceitaram como o mínimo denominador comum na prática de desenvolvimento de software. O manifesto diz:

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.

Como disse antes, existe uma febre crescente de adoção de metodologias ágeis. Pior que isso, existe a tendência de expropriar o termo “Ágil” e seus derivados, como “XP” e “Scrum”, criando verdadeiros frankensteins que misturam o jeito antigo com o novo. É o caso de tentar juntar RUP com Scrum, ou PMI com Scrum, e assim por diante.

São tentativas oportunistas que aproveitam a febre para ganhar dinheiro fácil. Algumas empresas, por exemplo, fazem questão de um “Certified Scrum Master” no currículo de um gerente, entre outras coisas igualmente irrelevantes.

E, para piorar, muitos tentam implementar metodologias ágeis “by the book”, ou seja, de forma dogmática. Todo dogma, por definição, é burro.

Voltando aos 4 valores: a prioridade é software que funciona e valor ao cliente. Implantar uma metodologia vem depois disso, quando vem. O primeiro valor é claro: valoriza muito mais Indivíduos e Interações do que Processos e Ferramentas. O que se vê hoje é o oposto, um esforço para empurrar processos, metodologias e ferramentas.

Agora é uma boa hora para começar a desmistificar o mundo Agile. Isto aqui é só uma introdução, mas vale o conselho que o Uncle Bob dá na entrevista: siga os originais. Se você está mesmo comprometido em melhorar as coisas e entregar projetos com qualidade e valor, largue essa nova geração de consultorias. Comece pelos primeiros livros de Ken Schwaber, Kent Beck, Alistair Cockburn e Mike Cohn.

Pergunte-se o tempo todo: estou de acordo com os 4 valores?

Se estiver dando mais ênfase ao processo do que às pessoas, você já começou errado. Muito errado.