O XP, o Scrum e todos os post-its que vieram com o agile, já estão bem populares por aqui. Bem, pelo menos é o que se pode ler em fóruns, blógs, sites e afins. E isso é bom. Muito bom. Porque não são apenas desenvolvedores de software que estão utilizando metodologias ágeis para serem mais produtivos, mas empresas com atuação em diversas áreas já começam a utilizar o scrum, por exemplo, para organizar suas equipes de uma forma mais eficiente.

Na minha opnião, ganhamos alguma experiência nos últimos anos: acertando, errando e principalmente aprendendo com nossos erros. Acho que estamos ultrapassando uma etapa importante do desenvolvimento ágil no brasil,  sainda das perguntas do tipo

“What is agile software development ?!”

para perguntas como

“What I need to do to be agile ?! What I need to do to have an agile team ?!”

Porque é quando as empresas tentam inserir agilidade em suas equipes, é que percebem que essa tarefa não é tão fácil quanto parecia. Eu já comentei por aqui, que atualmente, todo mundo quer ser ágil, mas poucas empresas conseguem implantar agilidade em seu ambiente corporativo com sucesso.

Mas porque isso acontece ? Kent Beck não sabe do que está falando? Tudo o que M. Fowler vem escrevendo nós últimos anos não funciona ?

Acho que não é esse o caso.

Na minha opnião as empresas, quando tentam seguir uma fórmula de agilidade, exigem ou engessam a aplicação de determinadas práticas para as equipes, ou acreditam nessas metodologias como a bala de prata para todos os seus problemas: já estão contrariando tudo aquilo que o agile tem de mais importante: adaptação.

Sobre isso, não posso deixar de comentar o ultimo post de Dhanji R. Prasanna, quando fala sobre a aplicação de metodologias ágeis no google:

“The engineering discipline at Google can best be described as the Cowboy Methodology. This derisive monicker is used by agile practitioners to chide those who follow no process at all, the connotation being that they produce messy and often untenable results.

There are exceptions of course, many Google teams use various degrees of XP, Scrum, or something else entirely. However, these are few and far between in my experience. The lack of methodology predominates. This is not to say that software does not get written on time, nor is it to say that good code is not produced but the process under which it is, is largely non-existent.”

Isso significa que o google é o mais famoso adepto do Extreme Go Horse? Não, acho que o google está se adaptando.

Acho que qualquer time que queira ser ágil, deve antes de tudo, ser capaz de se adaptar.

E adaptação siginifica perceber que muitas vezes, espalhar post-its pelas paredes, simplesmente não faz sentido, se a própria equipe não se comunica através deles. Significa perceber que reuniões diárias não são necessárias, quando temos escopo de curtíssimo prazo, todos trabalham próximos uns aos outros e sabem o que precisa ser feito.

Se adaptar é perceber que muitas vezes, é melhor investir tempo programando efetivamente, com codereview e refactoring, do que desperdiçar horas em planejamento, detalhando requisitos incertos, estimando tarefas e montando um cronograma de 3 meses, que dificilmente será cumprido.

Se adaptar é ter a capacidade de identificar, quais práticas podem ser utilizadas  em cada situação, e isso significa geralmente utilizar um mix de metodologias e técnicas, entre scrum, XP, modelagem agil or whatever.

Cowboy Methodology? NO.
It’s all about adaptation.

Semana passada estive na Sociesc conversando um pouco sobre desenvolvimento ágil na Semana da Computação, realizada entre os dias 23 e 28 de agosto. Falei um pouco da minha experiência pessoal com desenvolvimento de software e no que estou trabalhando atualmente.

Segue o vídeo da apresentação:

Correções:
*Fiz um comentário sobre uma fábrica de software com mil programadores no Refice. Não sei porque falei esse número. É uma empresa com no máximo 400 funcionários.
*Logo após eu falei que NÃO sou especialista em nenhuma metodologia ágil e por isso não iria entrar em detalhes em nenhuma delas (aka XP, scrum, kanbam)

Alguns dias atrás eu comentava com um colega de trabalho, sobre o meu sentimento de que o “agilismo” (ou seja lá qual for o termo) já se tornou a moda da vez. Os “xipezeiros”, “scrunzeiros” e agilistas de plantão estufam o peito pra falar dos seus “sprints”… que utilizam quadros brancos… que tem post-its colados por toda empresa… que UML  não serve pra náda… e que ser ágil é sentar e sair programando.
Tenho o sentimento que muitas pessoas e consequentemente empresas, se juntam a manáda e começam a utilizar alguma metodologia, porque alguém disse que é bom, ou porque o blog do momento falou que é “cool” ser ágil.

Qual a empresa de tecnologia hoje, ser arriscaria a dizer para seu cliente que não é “Ágil” ?
Todo mundo tenta desesperadamente ser ágil.
Até a IBM, quer ser ágil.

Tenho a impressão que essa busca incansável, é motivada principalmente por 2 coisas:

- a primeira é que já sofremos muito durante os últimos anos  tentando fazer software
Quem já trabalhou numa fábrica de software, numa consultoria de 3 letrinhas, já encarou caso de uso de mais de 100 páginas, ou quis modelar um ERP inteiro em UML antes de começar a programar, sabe bem do que estou falando. Para quem já está na labuta a pelo menos uns 10 anos e passou por tudo isso já aprendeu que algumas coisas nem sempre funcionam. E vêem o agile como a melhor opção disponível para desenvolver software atualmente.

- a segunda é a falsa idéia de que as metodologias ágeis pregam… não utilizar metodologia alguma..!!!
Isso é fato quando se vê muita gente em fóruns e afins, falando que na suas empresas não tem análise, não tem documentação ou burocracia alguma...que após uma reunião, todos os programadores se debruçam-se sobre seus teclados e se põe a codificar até que algo seja “entregável” para o cliente.
Bem, IMHO isso me parece muito mais um XGH…. ou um “Just Do-it Programming” disfarçado de scrum.
Acho que muita gente que está entrando no mercado de trabalho recentemente (a uns 3 ou 4 anos), diz que utiliza XP, Scrum, Lean ou qualquer metodolgia ágil porque tem a ilusão de que é fácil de implementar.

“Se não tem documentação… não tem formalidade alguma….se é só fazer uma reunião de 15 min durante a manhã e programar durante o resto do dia… eu também posso ser ágil… vamos implementar isso aqui na nossa empresa !!!”

Essa é uma das maiores falácias do desenvolvimento de software. Por experiência própria, eu posso dizer que aplicar uma metodologia como Scrum ou XP na prática numa empresa e obter resultados positivos é um trabalho árduo. É difícil e vai requerer uma paciência que você achava que não tinha. Ao contrário do que muitos pensam, aplicar algumas práticas do XP, como o TDD por exemplo, vai exigir muito mais disciplina de uma equipe, do que se ela estivesse trabalhando numa fábrica de software com CMM5.

Com tudo isso, surgiram inúmeros cursos Scrum e XP por aí… apareceram centanas de especialistas em agile, que prometem demonstrar um conjunto de práticas para tornar qualquer empresa ágil…acabando com seus problemas de escopo, prazo e relacionamento com o cliente.

A verdade é que não existe uma fórmula, ou receita de bolo pra isso. A bala de prata não existe. Cada empresa tem uma caracterísitca….cada projeto tem um contexto… que faz com que seja necessário escolher as melhores práticas em cada situação.

A melhor idéia de agile que tenho até o momento, foram as palavras de Philippe Kruchten no seu keynote no final semana passado, no agile brazil 2010:

“Software development is not a Natural Science like Physics or any other. In Agile Software Develpment, we have different methods (aka: scrum, xp, lean) for diferente issues. We have to ask ourselves which practices or methods will fit better in our project context”

“Why we’re using XP ? What practices will fit better in these project ? … and why we’re doing this any way?”

Você consegue imaginar a utilização de XP no desenvolvimento do software que contola um caça F-35 ?

Xispezeiro: “Sem problemas,  nessas duas primeiras semanas vamos entregar a parte que faz ligar o motor e você já pode decolar com o avião”
Piloto: “E o controlador de vôo ?”
Xispezeiro: “O que ? O controlador de vôo ? Mas você vai precisar disso mesmo ? O mais importante agora é decolar… depois conversamos sobre o controlador de vôo…”

Não conheço náda de aeronáutica, mas é bem provável que um projeto de desse tipo seja obrigado a ter uma fase muito detalhada de design e documentação, porque um erro de projeto, pode gerar um prejuízo estratosférico.
E gerar muita documentação nesse caso está errado? Você faria uma reunião de 4 horinhas pra modelar uma funcionalidade num F-35 ?
Claro que esse é um exemplo extremo, mas existem muitas organizações e ramos de negócio que precisam de mais formalidade e provavelmente teriam muitas dificuldades implementando métodos ágeis.
Por isso que contexto, é fundamental.

Com toda essa confusão de post-its e sprints do falso agile, os verdadeiros valores do manifesto ágil acabam ficando em segundo plano para maioria das pessoas. Acabamos desconsiderando o mais importante: o contexto no qual estamos tentando implementar agilidade.

Por que estamos utlizando essa metodologia ? Qual o problema que estamos tentando resolver ? Essas práticas se encaixam no contexto desse projeto ?