Estou lendo um livro bem interessante chamado “Sustainable Software Development: An Agile Perspective” de Kevin Tate. Há muito conteúdo sobre aquilo que eu acho ser o ponto chave para quem pretende usar abordagens ágeis para o desenvolvimento de software: Princípios Ágeis.
Quando eu comecei a trabalhar com métodos ágeis eu fiz o que 90% das pessoas fazem quando descobrem e se encantam por essa abordagem. Comecei a estudar e implementar as práticas propostas pelas diversas metodologias, mesmo sem ter uma visão clara sobre os princípios sobre as quais elas se baseiam.
Hoje, depois de alguns anos e já com alguma experiência eu tenho muito claro o quão importantes são os princípios propostos pelo movimento ágil e como as práticas perdem rapidamente o seu efeito quando tais princípios não são bem compreendidos por aqueles que as aplicam.
Veja o que diz o autor:
Principles define what you want to accomplish and the practices how you want to go about it. Too much of the mantra in software development is around sets of practices. We hear "follow this set of practices" or "if you aren't following these practices, you aren't using this technique." If only it were that simple! These practice-oriented approaches put the cart before the horse by defining the features before the vision. While there is no doubt that in every case the practices are valuable and can be learned from, if you don't know what you are trying to achieve, then your efforts are going to be misdirected.
Para quem está começando a estudar ou implementar uma metodologia ágil como XP, SCRUM ou FDD eu recomendo enfaticamente que tente abrir um pouco o foco do seu estudo de forma a tentar identificar o que está por trás dos métodos. Quando os princípios são seguidos, as práticas se encaixarão com muito mais eficácia no seu ambiente de trabalho. Ao entender os princípios, você também terá muito mais capacidade para montar aquele conjunto de práticas – às vezes resgatadas de uma ou mais metodologias – que se aplicam com mais naturalidade ao seu projeto.
Onde encontrar estes princípios?
Os princípios ágeis podem ser encontrados em vários lugares: Na fonte original que é o Manifesto Ágil; nas próprias metodologias ou ainda em trabalhos ou livros pontuais sobre o assunto. Muitas vezes, autores diferentes abordam os mesmos princípios com enfoques diferentes, ou os agrupam de forma a criar uma base para o estabelecimento de uma direção ou de um conjunto de práticas. Mas invariavelmente todos convergem para aquilo que está estabelecido no Manifesto Ágil. Por exemplo, o autor do livro supra-citado estabelece 4 princípios-chave para o desenvolvimento sustentável de software:
• Refinamento Contínuo do Produto e das Práticas de Projeto;
• Produtos funcionais liberados a todo o tempo;
• Investimento e ênfase contínua no design(arquitetura) do sofware;
• Valorização da prevenção de defeitos sobre a detecção de defeitos;
Já a abordagem Lean Software Development (Mary/Tom Popendieck) traz sete princípios que convergem de uma forma ou de outra para os princípios ágeis já estabelecidos e em alguns pontos os estendem criando novas maneiras de se obter aquele que é o objetivo primário de qualquer projeto ágil: Gerar o maior valor agregado para os clientes de um produto por meio de entregas freqüentes de software em efetivo funcionamento.
Você também vai encontrar abordagens interessantes para lidar com os princípios estudando a teoria e os conceitos por trás do Crystal Clear (Alistair Cockburn) e do Adaptive Software Development (Jim Highsmith). Às vezes uma leitura rápida no trabalho dessas pessoas pode lhe dar idéias que vão realmente mudar a vida do seu projeto.
Finalmente, há um outro ponto importante nessa questão. Cada metodologia sugere práticas diferentes que atendem a esses princípios de maneira diferente. Assim se você não se adaptar a uma determinada prática de uma metodologia, você pode tentar fazer as seguintes perguntas: Primeiro, que princípios esta prática endereça? Segundo, como outras metodologias trabalham estes mesmos princípios? Por fim, Será que há alguma prática de outra metodologia que pode ser mais aderente ao meu projeto?
Gosto sempre de dar o exemplo da retrospectiva. Particularmente, acho o modelo sugerido pelo XP e pelo SCRUM meio burocrático. Criar timeline, escrever em cartões, estabelecer responsáveis, criar zonas de segurança, votar, etc. Acho muito trabalho para uma atividade que deveria ser simples: conversar e debater com a equipe o quê pode ser melhorado para a próxima iteração. O Crystal sugere uma prática que eu acho bem mais interessante e que se adaptou bem melhor ao meu projeto: o Reflection Workshop. Mais simples, mais prático, mais aderente e, o que é importante, nos leva a endereçar o princípio de auto-improvement do projeto tão bem quanto as práticas tradicionais.
Moral da história: Não desanime se você não faz aquela prática badalada do XP ou aquela reunião super importante do SCRUM. Seu projeto não precisa de um rótulo, precisa apenas ser *mais ágil*.