Olá pessoal, um dia desses, a Sara Barbosa colocou a seguinte questão no twitter: “Agilidade não é o mesmo que qualidade, Qualidade não é o mesmo que agilidade ?!” Preferi não responder na hora pois essa é uma questão que envolve muitos pontos de vista, e são inúmero os fatores que podem influenciar um projeto. A interpretação que dei a essa questão é se um produto desenvolvido de forma ágil sempre terá qualidade e se um produto de qualidade significa que foi desenvolvido de forma ágil.

Bom, primeiro precisamos ter uma definição sobre o que é qualidade de software. O primeiro ponto, sobre esse assunto é, qualidade para quem? Cliente ou desenvolvedor ou ambos? Claro que o ideal é que o produto tenha qualidade para o cliente e para o desenvolvedor, pois isso resultará em bons resultados na entrega, manutenção e evolução do software.

Os processos ágeis têm como principal objetivo a adaptação as mudanças, pois sabemos que elas são inevitáveis. A partir do momento em que começamos a parar de lutar contra as mudanças e passamos a utilizá-las para atingir o nosso objetivo, teremos como resultado um produto com maior qualidade para o nosso cliente e também para os desenvolvedores. Existem práticas ágeis de desenvolvimento que contribuem muito para obter um código mais limpo, mais legível e consequentemente mais fácil de manter e evoluir. Práticas da XP (Extreme Programming) como programação em par e TDD são bons exemplos que podemos utilizar. Portanto, quando trabalhamos com processos ágeis, estamos mais próximos dos objetivos e consequentemente da qualidade do produto.

Quando temos um produto de software de boa qualidade nas mãos, não necessariamente isso significa que ele foi desenvolvido por um processo ágil. Em primeiro lugar, vamos analisar a seguinte questão: Qual é a metodologia (ou processo) de desenvolvimento mais ágil que existe? Talvez muitas coisas venham em sua mente agora, mas a resposta a essa pergunta, é o famoso DEPENDE. Por que? Porque a agilidade empregada em uma organização pode variar, ela depende do tamanho do time de desenvolvimento, depende dos recursos disponíveis, do tamanho do projeto, da presença de alguém fornecendo feedback e acompanhando o desenvolvimento do produto, etc. Para uma organização envolvida em um projeto de grande porte, geograficamente distribuído e envolvendo dezenas de desenvolvedores, talvez um RUP seja o processo mais ágil que eles consigam trabalhar, ou até mesmo um Waterfall. Nesse cenário, o caminho até o objetivo final pode ser mais oneroso, mas isso não significa que o resultado não seja um produto de boa qualidade.

Portanto, adotando processos ágeis estamos caminhando para um resultado de qualidade, tanto para o cliente quanto para o desenvolvedor, porém a agilidade não é o único caminho para se atingir a qualidade esperada num produto de software, sendo assim, qualidade não necessariamente significa agilidade.

Recomendo fortemente dar uma lida no texto produzido por Klaus Wuestefeld entitulado:  O Círculo Vicioso do Software Retranqueiro, retrata bem o cenário que vivemos no desenvolvimento de softwares.