Extreme Programming

Aumente a produtividade no desenvolvimento de seus softwares

Introdução

O Extreme Programming ou “XP” - não confundir com o nome de um (in)popular sistema operacional - é uma metodologia de engenharia de software que vem ganhando adeptos nas áreas mais diversas pela simplicidade das suas práticas e pelos resultados surpreendentes que vem demonstrando.

Ao contrário das metodologias tradicionais de engenharia de software, o XP não gera uma grande quantidade de documentos nem uma sequência rígida de etapas a serem cumpridas. O XP prega simplicidade e um conjunto de práticas focadas em resultados concretos.

Nenhuma das práticas do XP é realmente novidade. O seu verdadeiro ponto é reunir todas essas práticas em um conjunto coerente, acrescentando uma visão de processo, para atacar o problema do desenvolvimento de software em sua forma real: como atingir um alvo móvel e como gerenciar riscos.

Histórico O Extreme Programming surgiu de um grupo de desenvolvimento dentro da Chrysler, um dos maiores fabricantes de automóveis do mundo. O sistema C3 seria o responsável pelo pagamento de 86.000 funcionários, entre diaristas, horistas e mensalistas, parte deles com direito a bonificações e bônus e vários sindicalizados. É um sistema grande e complexo, cujo desenvolvimento foi iniciado em maio de 1997 e, mais ou menos um ano depois, declarado oficialmente como um fracasso.

O projeto foi reiniciado do zero com a metodologia XP e, em outubro de 1998 (com menos de quatro meses de projeto), o pagamento de 10.000 mensalistas já estava em produção, e o pagamento de 16.000 executivos estava sendo migrado para o novo sistema.

As práticas essenciais do XP

O XP é baseado em simplicidade, ausência de burocracia e livre circulação de informações. Iniciamos pela composição junto ao usuário de “user stories”, que descrevem cenários de utilização do sistema. As user stories definem requisitos para o sistema e cenários de teste para validar os requisitos.

As user stories são reunidas e priorizadas em grupos que possam ser implementados em três semanas. A isto chamamos de uma interação do XP. Iniciamos pelas user stories mais importantes (de maior valor para o negócio) e por aquelas que sejam mais complexas sob o ponto de vista tecnológico.

Uma user story é considerada finalizada quando todos os seus casos de teste rodam com sucesso. Não existe uma user story parcialmente completada. Caso o prazo da iteração seja esgotado sem que os casos de teste tenham sido bem sucedidos, planeja-se uma, ou mais, iterações novas para resolver os problemas pendentes, ou a user story é quebrada em user stories menores que possam ser completadas em uma iteração.

Uma user story completada deve formar um produto que possa ser entregue ao usuário e operado por ele. Veja bem: a primeira iteração de três semanas já tem que entregar algo funcional para o usuário.

Os programadores trabalham sempre em pares, um par por micro, em toda e qualquer atividade de modelagem ou codificação. Duas cabeças pensam melhor do que uma, e o par produz muito mais, com maior qualidade, do que a soma dos dois programadores individualmente. A programação em pares mantém o código dentro dos padrões do projeto, inibe a implementação de “gambiarras” e distribui o conhecimento de cada componente do sistema por mais pessoas. As duplas devem mudar a cada três ou quatro iterações para que não se formem “ilhas de código” que apenas um programador é capaz de entender.

No início de cada iteração, a dupla deve criar casos de teste para todas as funcionalidades previstas. Não se programa sem antes gerar um caso de teste automatizado. Assim, uma iteração inicia com vários casos de teste de sistema (sobre as user stories) e vários casos de teste de unidade para cada módulo, classe ou sub-rotina, e todos eles falham. À medida que o código vai sendo escrito, os casos de teste são executados novamente e alguns são bem sucedidos, outros falham, indicando erros de programação ou funcionalidades ainda não implementadas. No final da iteração todos os casos de teste devem executar com sucesso.

Ao menos uma vez por dia, todo o sistema tem que ser integrado, ou seja, nenhum par de programadores pode passar o dia sem reunir o seu trabalho, mesmo que ainda incompleto, ao trabalho realizado pelos outros pares. Todos os casos de teste do sistema, não apenas os casos de teste criados para validar a iteração, são executados como parte da integração, e os resultados, bons ou ruins, são distribuídos para todos os envolvidos, inclusive os usuários!

Sempre que um bug é descoberto, deve-se criar um novo caso de testes que demonstre a sua existência. Só depois disso o trabalho de isolar e corrigir o bug é iniciado. Da mesma forma, uma nova feature do sistema ou mudanças nos requisitos implicam em novos casos de teste ou em casos de testes modificados.

Cada par de programadores é responsável por fazer suas user stories (e os respectivos casos de teste) funcionarem, não importa o que e onde deva ser codificado. O sistema não é compartimentado em módulos com “donos” que são responsáveis por quaisquer alterações. Como cada par deve rodar com sucesso os casos de teste de unidade de todas as classes ou sub-rotinas modificadas, não há risco de se quebrar um código que antes funcionava.

A cada iteração, programa-se apenas o mínimo necessário para implementar as respectivas user stories. Não se programa nada que “será útil no futuro”. Mas cada iteração também refatora (reescreve) agressivamente o código pré-existente para adequá-lo e otimizá-lo para as novas necessidades da iteração corrente. A existência dos casos de teste permite que se refatore um código existente, sem perda de produtividade ou de qualidade.

Porque o XP funciona

No XP o usuário é parte integrante da equipe de desenvolvimento o tempo todo, não uma entidade externa que encomenda um sistema e meses depois recebe o programa. É importante que se estabeleça um relacionamento de participação e confiança com o usuário desde o princípio e que este relacionamento seja mantido até o final.

A transparência é fundamental, e o XP dá uma grande importância a manter o usuário informado de forma honesta e que ele possa compreender sobre a situação corrente do sistema. Os casos de teste viabilizam isto, pois o usuário sempre sabe quantos testes foram bem-sucedidos e quantos falharam. Ele nunca tem uma visão irreal de que o sistema está “80% pronto”, sem saber 80% de quê.

A participação do usuário e a transparência permitem que se lide de forma efetiva com o maior problema do desenvolvimento de sistemas: requisitos incompletos e incorretos. O fato é que o usuário (e os analistas) não sabe o que deve realmente ser feito por um sistema até que o sistema esteja em uso. O conceito abstrato que se tem no início de um projeto nunca sobrevive ao teste da realidade e, inevitavelmente, surgem mudanças a serem feitas para que qualquer sistema atinja seus objetivos de negócio. O processo interativo do XP permite que o usuário e analistas aprendam mais cedo o que o sistema realmente deve fazer e aumenta as chances de que ele seja implementado dentro de prazo e custos aceitáveis.

Como não sabemos o que o sistema deve fazer antes de iniciarmos, o XP estipula que entre cada iteração as user stories, casos de teste e cenários devem ser revistos e todas as estimativas de prazo reavaliadas. Ao contrário das metodologias tradicionais, o XP não congela requisitos, prazos e custos no início do projeto: ele parte de uma estimativa inicial grosseira, que vai melhorando à medida que se avança no desenvolvimento (e aprendizado) do sistema.

O Xunit

Testes automatizados são essenciais para o XP. Os testes são o fio condutor de todo o processo e não um item que realizamos depois de todo o trabalho importante, se der tempo. Os testes são executados várias vezes ao dia e é sobre eles que se realiza o controle e gerenciamento do projeto. Por isso, os criadores do XP desenvolveram o framework Xunit para facilitar a codificação dos casos de teste e a sua execução e tabulação automatizada.

A ampla variedade de implementações do Xunit atesta a popularidade e eficiência do XP. Existe o Junit, phpUnit, PyUnit e outros Xunit para praticamente todas as linguagens de programação existentes, desde C e Perl até Visual Basic e Delphi. Existem ainda módulos especializados para teste de aplicações web ou GUI que simulam a iteração do usuário com o sistema.

XP e o Software Livre

O leitor atento irá notar uma série de semelhanças entre o XP e o Software Livre: Tanto o XP quanto o Software Livre surgiram da iniciativa dos usuários (técnicos) que necessitavam resolver seus problemas reais, não vender produtos.

Ambos só começaram a receber atenção da mídia e das empresas de informática depois que já estavam em uso por uma grande quantidade de empresas; ambos priorizam a participação do usuário e a qualidade do produto final, e ambos valorizam transparência acima de tudo.

Nos dois existe o princípio de liberar freqüentemente novas versões do software para teste pelos usuários (o “mantra” release early, release often)

Se você ler documentos como “A Catedral e o Bazar” de Eric Raymond ou participar de alguns projetos de software livre irá notar ainda mais semelhanças. Veja por exemplo o “make test” presente em muitos pacotes (testes automatizados e freqüentes) ou a forma de se trabalhar com o CVS (não existem travas nem donos de módulos).

Podemos dizer que ambos são caminhos diferentes para se chegar a um mesmo resultado, de modo que um reforça e valida o outro. O XP pode ser visto como uma versão “comercial” do modelo de desenvolvimento de Software Livre, ao qual foram agregados mecanismos para acompanhamento e gerenciamento de projeto.

Para saber mais:
Sobre o extreme programming - www.xprogramming.com
Outro site sobre o XP - www.extremeprogramming.org
Discussão sobre o XP - c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Sobre a produtividade da programação em pares - www.pairprogramming.com
A Catedral e o Bazar - www.opensource.org
Faça uma busca por Xunit e veja os resultados... - www.sourceforge.net
Ferramenta de gerenciamento de projeto baseada no XP - xplanner.sourceforge.net
Integra o Xunit ao CVS, aceitando o commit somente se todos os testes forem bem sucedidos - iguard.sourceforge.net