Toda história tem um início

Em meados de 2006 eu trabalhava numa empresa que vinha iniciando um período de mudanças. Essas mudanças visavam a conquista da certificação CMMi nível 2, e por isso passávamos de um ambiente de extrema informalidade (e de um pouco de desorganização) para um extremamente processual e metódico.

Nessa mesma época passei a me interessar por gerência de projetos, e desejava criar uma ferramenta simples para o controle das atividades da equipe em que trabalhava. Dei para essa ferramenta o nome de Hive, porque admirava a organização das abelhas na manutenção das colméias. Mas passadas essas frivolidades, deveria me concentrar no problema da implementação. Queria criar algo independente de plataforma, e a internet foi a resposta natural. Então passei alguns dias codificando em PHP e logo desisti da idéia. Também tentei com Java, o que me consumiu um ou dois meses. Enquanto isso, pesquisava por outras aplicações semelhantes a minha e que já estivessem implementadas.

Foi quando descobri o Basecamp, um controle de atividades simples e descomplicado. Mas o que mais me chamou a atenção não foi a ferramente em si, mas a maneira como ela tinha sido construída. Não pretendo contar a história do Ruby on Rails, embora essa pequena odisséia seja essencial para entender como cheguei ao Agile. Para nós, basta saber que o que David Heinemeier Hansson realmente queria quando criou o RoR era ter em mãos um suporte ágil para desenvolver aplicações para internet enquanto utilizava metodologias ágeis.

E por causa dele passei uns bons meses aprendendo Rails e brincando de criar pet projects. Não demorou muito até que eu descobrisse que a 37Signals, a empresa de DHH, tinha escrito um livro com um título no mínimo interessante: Getting Real.

Não poderia haver melhor momento para eu ler aquelas páginas. Cair na real era tudo que eu queria que acontecesse com as pessoas que escreviam os novos processos da minha empresa. Aqueles mesmos processos que nos faziam trabalhar cada vez mais para fazer cada vez menos.

O que o cliente quer

Era uma vez nossa cliente, ela se chamava Liege. Quando eu comecei a trabalhar com ela, descobri que há um ano ela havia tido uma grande idéia. Coletar dados de todos os sitemas não interconectados que permeavam a organização onde ela trabalhava, e tratá-los de maneira unificada para gerar dados estratégicos. Na época, não sabíamos que isso tinha um nome: business intelligence.

Mas o que me chamava atenção naquela pioneira do BI era o que ela sempre me dizia a cada vez que eu a visitava: “Antigamente não era assim, eu pegava o telefone e ligava pro Rafael, e ele fazia o que eu queria sem essa embromação.”

A embromação a qual ela se referia significava: pedir uma reunião conosco para esclarever a viabilidade técnica de uma solicitação de manutenção no sistema (geração de um formulário de visita técnica e de outro de coleta de dados). Se a viabilidade fosse constatada, criar uma solicitação no Sistema de Relacionamento com o Cliente e a priorizar. Esperar para que o responsável pelo seu departamento aprovasse a solicitação (não havia prazo para ele fazê-lo). Esperar que o responsável dentro da nossa empresa aprovasse a solicitação (prazo?) e a encaminhasse para o gerente responsável (prazo?). Esperar que o gerente atribuisse um prazo para o atendimento da solicitação e a encaminhasse para o técnico responsável (talvez eu). Esperar que o técnico realizasse o atendimento (implementando uma nova funcionalidade ou corrigindo um bug), atualizasse a documentação e preenchesse o check list. Esperar o técnico fechar o atendimento no sistema, o gerente aprovar, o responsável da empresa aprovar, o responsável do departamento do cliente aprovar… e finalmente, olhar para o seu aplicativo e descobrir que para mudar a nomenclatura de um simples campo ela precisou esperar uma semana.

E bem, eu resumi bastante o processo, porque tudo que eu descrevi acima estava formalmente especificado no capítulo 3 do Procedimento Operacional número 30054-89 revisão 12. Não me admira que ela preferisse o método do telefone.

Caindo na Real

Getting Real é um livro sobre a filosofia ágil. Não é sobre XP ou Scrum, mas aproveita as idéias deles. Não estipula normas ou processos, mas uma maneira de pensar. Em resumo, é ágil. Não rápido, mas ágil. É como diz em sua própria introdução:

“Caindo na Real entrega exatamente o que os clientes precisam e elimina qualquer coisa que não precisam.”

Após ler o livro, descobri o que significava ser ágil. Ele foi a porta de entrada para essa nova maneira de pensar. Uma maneira, que no meu caso, não era tão indigerível como para outras pessoas. Mas por enquanto vamos parar por aqui, porque depois de escrever sobre como eu entrei nesse mundo, ainda falta contar para vocês: o que é Agile e como ele surgiu.