As metodologias ágeis já morreram?

Há alguns meses, recebi um e-mail do amigo Marcelo Malheiros, com um post do Ron Jeffries, um dos signatários do manifesto ágil (que deu origem às metodologias ágeis), sugerindo que as metodologias ágeis estão sendo adotadas da maneira errada pelas organizações, algo que está deturpando o movimento. De imediato, me identifiquei com o artigo, pois é algo que venho dizendo há alguns anos em minhas aulas e palestras. Sei que peguei pesado demais neste título, mas leia até o fim para ver que eu não sou a favor do fim dos métodos ágeis, bem pelo contrário.

## O ontem explica o hoje

Lá no final dos anos 90, aprendíamos UML e RUP, linguagem e método para formalização de projetos de Software. Aprendíamos muito sobre Orientação a Objetos também. Cada detalhe de como usar uma linguagem gráfica para representar corretamente um Software. Aprendíamos que especificar, e que pensar antes de fazer era importante. A UML era a linguagem, o RUP era o método.

O RUP era um método completíssimo, com papéis e regras determinados para cada elemento da equipe: quem seria responsável pela análise, pelos testes, desenvolvimento, gerência do projeto, gerência de configuração, dentre muitos outros. O problema do RUP era justamente esse, ele dizia demais como as coisas deveriam ser. Entretanto, a proposta dele nunca foi impositiva, pois ele era um Framework de processo. Assim, cada pessoa ou empresa poderia utilizar dele somente o que era mais relevante e adaptar o Framework a suas necessidades locais.

Infelizmente as empresas não estavam preparadas para usar o arsenal da UML e do RUP. Sabendo de suas deficiências, contratavam consultorias para implantação de processos. Essas consultorias de Engenharia de Software, ávidas por vender horas e mais horas, recomendavam as empresas a utilizarem um processo bastante completo de especificação e gerência de projetos. Como consequência disso, as empresas tornavam seus processos mais burocráticos, demorados. E a conta dessa burocratização acabava sendo passada para o cliente, que pagava mais e mais horas de projeto, assim todos ganhavam mais, menos o cliente, que continuava recebendo um produto final tão ou menos eficiente quanto antes.

## A agonia de um modelo ultrapassado

Ao formalizarem os processos, as empresas precisavam de “Analistas”, seres “superiores” aos programadores, que ganhavam salários maiores também. Eram meses de análise e documentação realizadas muitas vezes por “Analistas” que não compreendiam o suficiente do negócio ou de Arquitetura de software. Após isso, o cliente aprovava documentos e mais documentos, para então iniciar o desenvolvimento. E quando o desenvolvimento iniciava, os desenvolvedores não entendiam nada daquela documentação, que havia sido feita por “Analistas” e acabavam fazendo tudo do seu jeito.

Mas por que isso acontecia? Por que as empresas e os profissionais não compreendiam totalmente o processo, ou não queriam investir ou “gastar” tempo na compreensão de um processo correto de Engenharia de Software. Assim, acabavam ficando a mercê da orientação de terceiros. Isso levou a indústria do Software a trabalhar de uma forma que sabemos hoje que não funciona para software: burocratização excessiva; foco exacerbado em documentação; contratos longos com valores fechados; longos planejamentos com datas de entregas determinadas.

Mas por que isso não funciona? Criar um software não é como construir uma ponte. Software é maleável, mutável, aceita mudança de requisitos, de regras de negócio. Software não é um produto acabado. Mesmo durante o seu desenvolvimento, precisamos compreender a natureza humana, que as ideias evoluem, que os requisitos evoluem. Assim, é preferível tornar um software melhor, implementar novos conceitos, a seguir um rigoroso planejamento e entregar uma solução que não agrada o cliente.

## O início de um novo ciclo

Sabendo disso (antes da maioria das pessoas), um grupo brilhante de profissionais se reuniu em 2001. Dentre eles estavam Kent Beck (XP,TDD), Alistair Cockburn (Crystal), Ward Cunningham (Wiki,XP,Design Patterns), Robert Martin (Clean code), Ron Jeffries (XP), Martin Fowler (Design Patterns, Refactoring, XP), Ken Schwaber (Scrum), Jeff Sutherland (Scrum), Steve Melor (xUML), dentre outras mentes brilhantes, para assinarem um manifesto (Agile Manifesto), criando quatro mandamentos que definiriam a Engenharia de Software nos próximos anos:
1. Indivíduos e interações mais que processos e ferramentas
2. Software em funcionamento mais que documentação abrangente
3. Colaboração com o cliente mais que negociação de contratos
4. Responder a mudanças mais que seguir um plano

Com isso estavam dizendo que é mais importante comunicação, software em funcionamento e atender mudança de requisitos, do que seguir um plano, documentar exageradamente e ter de perder tempo em negociações de contratos que não davam margem à mudanças de rumo durante o projeto.

## Novas metodologias (no papel)

Com isso vieram XP, Scrum, e outras metodologias chamadas ágeis, impondo um processo leve e dinâmico, com pouca previsibilidade (antecipação) e muito estímulo a desenvolver e entregar software tão cedo quanto possível para que se tenha feedback do cliente, e que este feedback guie o processo de criação, mais do que uma documentação exagerada e prévia. Alguns chamam esta grande especificação prévia de BDUF (Big Design Up Front), que era muito praticada na indústria de software até então.

É importante ressaltar que as metodologias ágeis não pregam a especificação inexistente. Apenas, a especificação não é formalizada no processo. Autores como Scott Ambler, inclusive criarm obras como a “Agile Modeling”, ensinando formas de se modelar de maneira ágil.

Martin Fowler, há muitos anos escreveu um artigo intitulado “Is design dead?” para versar sobre design de software em tempos de metodologias ágeis. Ele conclui que o design de software não morreu, mas evoluiu e agora é parte do processo evolucionário de criação de software, formado por equipes cada vez mais multidisciplinares. Diferentemente do passado (BDUF), o design agora acontece em todos os momentos do projeto.

Mas para funcionar na prática, cada metodologia impõe alguma cerimonia, mesmo que seja mínima. Também inclui alguns valores e práticas. Pegamos como exemplo o XP, para funcionar adequadamente, precisa de Pair programming, TDD, Integração contínua, reuniões rápidas diárias. Agregamos do Scrum em que as equipes precisam ser autogerenciáveis, multidisciplinares, agregamos o Kanban para o planejamento das iterações de maneira visual. Isto tudo é o que está previsto na metodologia para dar certo.

## Novas metodologias (na prática)

Nos dias atuais, sempre que eu pergunto em um grupo de maneira informal, ou em aula, ou em uma palestra, para profissionais de mercado se estes utilizam TDD e integração contínua por exemplo, muito menos que a metade acena positivamente. O mesmo vale para Pair programming. Quando eu pergunto quem utiliza metodologias ágeis, geralmente muito mais da metade acena positivamente. Mas o que está ocorrendo? Muitos pensam que estão utilizando metodologias ágeis, quando na verdade não estão.

Desenvolver software de maneira ágil não tem nada a ver com desenvolver software rapidamente. Muitos confundem, pensando que agilidade tem relação com velocidade. Agilidade tem relação com boas práticas de Engenharia de Software que vão permitir você fazer mais com menos, mais features, com menos código. Mas isso só é possível com boa arquitetura, testes, builds automatizados, reuniões frequentes, muitos olhos olhando para o código, preocupação com métricas, e muito mais.

Mas as empresas adotam um quadro de Kanban, fazem reuniões e colocam uma pressão tremenda nos desenvolvedores cobrando prazos para entrega rápida das features e chamam isso de metodologia ágil. Quando o desenvolvedor fala que precisa de tempo para fazer as coisas do jeito certo, para refatorar a arquitetura hoje, para poder entregar um software melhor e mais rápido amanhã, o gestor diz que não há tempo para isso. Isso definitivamente não é metodologia ágil.

Mas então o que há de tão errado nas metodologias ágeis? Simplesmente nada. Também não havia tanta coisa errada com o RUP que motivasse a enterrarem ele. Ele era um bom Framework de processos. Ele inclusive já previa entregas de maneira iterativa e incremental há 20 anos. O problema é que ele era incompreendido. Os profissionais achavam que ele devia ser implementado de maneira integral. Mas isso nunca foi uma premissa da metodologia, ela sempre deixou bem claro que poderia e deveria sem implementada em partes. Será que o problema do RUP era ser grande demais?

De certa forma, as metodologias ágeis sofrem do mesmo mal que o RUP sofreu, a incompreensão. As metodologias ágeis pregavam um método mais simples, para contrapor uma época burocrática. Os profissionais tornaram isso ainda mais simples, implementando somente um ou outro aspecto e chamando isso de ágil. Entretanto, algumas metodologias ágeis, mesmo que simples, para terem sucesso, precisam ser implementadas de maneira integral. A maioria das metodologias ágeis defende a mudança e a refatoração como motor da evolução. Porém a mudança só é possível se amparada por testes automatizados, caso contrário ela é perigosa. Será que o problema das metodologias ágeis era serem pequenas demais?

Vimos que o problema não está nas metodologias em si. O RUP não era um problema, XP e Scrum também não são. O problema é o ser humano. Ele é imediatista, ele não quer estudar, ele não quer implementar o método da maneira que ele foi prescrito. O ser humano desconsidera recomendações, conselhos, e quer fazer tudo do seu jeito, achando que o seu jeito que é o melhor. Assim, ele estraga tudo. Ao estragar tudo, coloca a culpa na metodologia. Isso dá margem ao surgimento de uma nova metodologia, um novo nome salvador. E no fim das contas, o ciclo se repete.

## O que ainda podemos fazer?

Poderíamos ter melhorado o RUP no lugar de ter enterrado ele. Poderíamos ter compreendido ele melhor. Não vamos deixar isso acontecer com as metodologias ágeis. Vamos compreender elas em sua essência e utilizá-las da maneira correta. Não vamos deixar que nos convençam que utilizar uma metodologia pela metade é suficiente. Vamos brigar pela utilização de cada vez mais boas práticas de trabalho. Se você usa Kanban para planejamento, que ótimo. Agora brigue por reuniões diárias onde cada membro da equipe tenha vez e voz. Agora brigue para que a equipe tenha autonomia para realização de estimativas. Brigue para que a equipe possa refatorar cada vez mais para atingir a excelência técnica, mesmo que isso não seja facilmente monetizado no presente. Brigue para poder utilizar TDD, depois brique para implementar um processo de integração contínua com builds automatizados para perceber facilmente quando as coisas derem errado.

Utilizar metodologias ágeis não se resume a um aspecto. É preciso um somatório de ações, de entendimento de valores e aplicação de práticas. Mas acima de tudo, é dar valor à excelência técnica, a Engenharia de Software, a Arquitetura de Software. As coisas podem mudar de nome com o tempo: RUP, XP, Scrum, mas nunca abra mão da excelência técnica. Com o tempo, as metodologias vão se transformando, a carruagem vai andando, e as abóboras se ajeitando.

> Pablo Dall'Oglio