Práticas ágeis são o caminho para a qualidade de software?

“Se você não mudar a direção, terminará exatamente
onde partiu” (provérbio chinês)

Nossa área de desenvolvimento de software é muito nova e, como
consequência disso, ainda estamos aprendendo quais são as técnicas que
funcionam e quais só atrapalham o dia-a-dia dos nossos projetos. É dever
de todo profissional da área buscar meios para melhorar o nosso
objetivo principal: construir softwares que atendam aos clientes, aos
usuários e às equipes de desenvolvimento.

Práticas ágeis são um meio e não um fim; as técnicas não devem ser utilizadas se não é evidente quais problemas elas tentam resolver. Usar por
usar não melhora em nada o resultado final do seu projeto. Você só deve
usar essas práticas se realmente entender por que elas são necessárias, e
não porque estão na moda.

Vamos observar os benefícios de algumas técnicas utilizadas no meio
ágil:

Com TDD o
programador cria o hábito de planejar suas tarefas antes de
executá-las, isso se deve ao fato de que nessa técnica você começa pela
elaboração de uma lista de testes para o artefato que será desenvolvido,
e só depois começa a codificá-lo. Outro benefício do TDD é que o
programador deve usar o seu código antes de implementá-lo. Apesar de
parecer estranho, é uma quebra de paradigma excelente começar a
codificação pelo teste e tomar as decisões de design do código antes de
implementá-lo, isso reduz o retrabalho pois o programador percebe no
início da codificação como ficará seu código ao final dela.

Muitos gestores ainda não acreditam nos benefícios da programação
em par, sendo um dos motivos a sensação de perda de
produtividade quando dois programadores são alocados para a mesma
tarefa. Essa sensação é falsa, pois existe uma série de fatores que
devem ser levados em consideração quando falamos de produtividade. O
ritmo de desenvolvimento da dupla é garantido pela  falta de distrações
que um programador sozinho teria, dificilmente durante o desenvolvimento
em par o “piloto” irá desviar do foco. Outro benefício da programação
em par é a revisão que o “co-piloto” faz, observando a
codificação do piloto; muitos problemas podem ser identificados em tempo
de codificação. A comunicação constante entre os programadores faz com
que cada decisão seja mais bem pensada, e ainda traz um grande
benefício: dois membros da equipe vão conhecer aquele trecho do código, o que é essencial para contornar problemas de comunicação e troca de
membros da equipe durante o desenvolvimento dos projetos.  A programação
em par protege o investimento do projeto pois reduz a taxa de
retrabalho da equipe e gera um código de qualidade superior, afinal,
duas cabeças pensam melhor do que uma.

Desenvolver um software de forma iterativa e incremental
traz uma série de benefícios. Porém, também traz uma série de
problemas. Desenvolver software em ciclos de tempo fechados faz com que
cada minuto seja precioso, por isso vários impedimentos são
identificados ao longo do desenvolvimento e resolvidos à medida que as
entregas são realizadas no final de cada ciclo. Como o desenvolvimento
acontece em ciclos, a equipe de desenvolvimento pode aprender com os
problemas enfrentados no ciclo anterior, isso permite que o processo de
cada equipe possa ser melhorado continuamente, e essas melhorias sempre
atacam um grande impedimento do ciclo anterior, ou seja, não são melhorias apenas por melhorias.

Processos iterativos e incrementais também
auxiliam a contornar o grande vilão dos projetos de software que é a
mudança de escopo. Caso o cliente descubra uma nova necessidade, ela poderá ser implementada no próximo ciclo, já que o ciclo em
desenvolvimento não deve ter seu objetivo alterado. Caso a necessidade
do cliente mude (ou melhor, quando a necessidade do cliente mudar) e o
ciclo desenvolvido não for mais necessário, o cliente só “perde” aquele
ciclo, ou seja, o custo da alteração de escopo fica sendo o custo do
desenvolvimento do novo ciclo. Outra característica interessante é que
nessa forma de desenvolvimento os feedbacks dos usuários chegam muito
mais cedo do que no modelo tradicional, já que no final do ciclo a
equipe entrega um parte funcional do software. Também, como o software entra
em produção mais cedo, o cliente também começa a usufruir dos benefícios
do sistema mais cedo.

As técnicas ágeis são um meio para solucionar alguns dos problemas
mais comuns dos ambientes de desenvolvimento como conhecemos (falta de
comunicação, retrabalho, escopos rígidos, custos altos, falta de testes,
etc.), elas propõem uma nova forma de trabalho, que tem se mostrado
muito eficiente para equipes com o perfil adequado. Essas técnicas
influenciam positivamente em todas as vertentes de avaliação da
qualidade de um software desde que sejam aplicadas de forma correta.

Quer saber mais sobre as técnicas citadas? Seguem algumas
referências:

Sobre TDD:

• TDD no Wikipédia
• Desenvolvimento
  orientado a teste Por @viniciusteles
• Portal TDD
• Tudo sobre TDD Por @victorhg
• Apresentação que utilizo em treinamentos Por
  Fabrício Mattos
• Podcast TDD não existe

Sobre Programação em Par:

• Dicas sobre Programação em Par Por @lucianofelix
• Par Programming no Wikipédia
• Programação em Par Por @viniciusteles

Sobre desenvolvimento iterativo e incremental:

• Desenvolvimento iterativo e incremental no Wikipédia
• Escopo Iterativo e Incremental para o gerenciamento
  Ágil de requisitos Por @visaoagil
• Scrum
  no Wikipédia
• Scrum –
  Por @viniciusteles
• Scrum
  Alliance
• Scrum.org

Qual a sua experiência sobre as técnicas ágeis? Você acha que elas
são o caminho para aumentarmos a qualidade dos softwares que
desenvolvemos?

Aguardo feedbacks!