| Desenvolvimento
Orientado a Testes
Observando-se o trabalho de um desenvolvedor,
nota-se que boa parte do seu tempo é
dedicada à depuração de
bugs. Trata-se de uma atividade frequentemente
demorada que se repete inúmeras vezes
à medida que o desenvolvedor produz mais
código.
Idealmente, gostaríamos que softwares
nunca tivessem defeitos, mas infelizmente, em
função da complexidade dos sistemas,
esse objetivo dificilmente é factível,
levando à necessidade de depuração.
Entretanto, o tempo gasto com depuração
pode ser reduzido significativamente quando
se consegue assegurar que os erros sejam detectados
imediatamente, assim que são introduzidos.
Quando isso ocorre, é mais rápido
depurar e compreender o que pode ter causado
o problema porque o programador tem, em sua
memória, todo o contexto relativo à
funcionalidade que está desenvolvendo.
Não é necessário relembrar
algo que foi implementado meses atrás.
É possível detectar problemas
imediatamente desde que tenhamos o hábito
de implementar testes automatizados antes de
cada funcionalidade, de cada classe e de cada
método criados no sistema. Quando isso
é feito, criamos um mecanismo automatizado
que aponta os problemas assim que eles são
inseridos, o que reduz o tempo de depuração,
além de servir como um mecanismo para
testar o bom funcionamento do sistema a qualquer
momento.
Equipes que trabalham com XP se preocupam em
criar softwares saudáveis, que funcionem
corretamente e permaneçam assim ao longo
do tempo, à medida que recebem novas
funcionalidades e alterações.
Em se tratando de saúde, a prevenção
é o melhor remédio e no caso de
software não é diferente. Para
tornar os sistemas saudáveis, equipes
XP investem em testes automatizados, implementados
antes mesmo de escrever o código das
funcionalidades. Assim como a programação
em par, o desenvolvimento orientado a testes
ajuda a criar uma rede de proteção
em torno do software, para que ele se mantenha
saudável ao longo do tempo.
Refatoração
Quando deixamos de cuidar de nossa casa, a
poeira se acumula, a pia fica cheia de louça
suja, as lixeiras ficam entupidas e aquilo que
se costumava chamar de lar se transforma em
um lugar pouco agradável. Para evitar
que isso ocorra, investimos tempo frequentemente
para varrer, lavar a louça, arrumar a
cama, retirar o lixo, entre outras atividades.
Isso nos ajuda a ter mais conforto e permite
que utilizemos a nossa casa para o que desejarmos,
como por exemplo, convidar amigos para assistir
a um jogo conosco.
Assim como a nossa casa, sistemas também
se deterioram quando não investimos continuamente
na limpeza e na organização dos
mesmos. A estrutura de qualquer sistema tende
a se degradar ao longo do tempo, à medida
em que novas funcionalidades são inseridas,
alterações são feitas,
erros são corrigidos e mais código
é introduzido.
Para evitar que a aplicação se
transforme em uma casa suja, desorganizada e
difícil de manter, equipes XP utilizam
a prática de refatoração.
Elas alteram pequenas partes do sistema, frequentemente,
sempre que encontram uma oportunidade para melhorar
o código, tornando-o mais limpo, mais
claro e mais fácil de ser compreendido.
Tais alterações não mudam
o comportamento das funcionalidades, apenas
melhoram a estrutura do código. Agindo
assim, de forma sistemática e com frequência,
as equipes investem para que o software se mantenha
sempre fácil de alterar, gerando a velocidade
de desenvolvimento que os clientes de projetos
XP costumam vivenciar e apreciar.
Código Coletivo
Em um projeto XP, os pares se revezam, as pessoas
se revezam na formação dos pares
e todos têm acesso e autorização
para editar qualquer parte do código
da aplicação, a qualquer momento.
Ou seja, a propriedade do código é
coletiva e todos são igualmente responsáveis
por todas as partes. Com isso, os desenvolvedores
ganham tempo, pois não precisam esperar
a autorização de um colega para
editar uma área do código e há
maior disseminação de conhecimento.
Além disso, quando diversas pessoas têm
a chance de olhar uma mesma área do código,
torna-se mais freqüente a identificação
de oportunidades de melhoria, levando frequentemente
à refatoração em áreas
que precisam da mesma.
Design Simples
O design de uma aplicação surge
de forma incremental e evolutiva em projetos
que trabalham com XP. O objetivo é criar
a solução mais simples possível
que seja suficiente para implementar as funcionalidades
de cada iteração. Qualquer característica
que possa ser implementada para dar apoio a
funcionalidades futuras (fora da iteração),
só são codificadas de fato se
e quando tais funcionalidades forem priorizadas
para uma iteração. Assim, busca-se
concentrar os esforços da equipe naquilo
que se tem certeza absoluta de que será
necessário hoje, por já ter sido
priorizado pelo cliente para a iteração
corrente. Aquilo que poderia ser útil
no futuro, deixamos para resolver no futuro,
quando houver certeza da necessidade.
Isso levanta a preocupação de
que não sejamos capazes de solucionar
problemas futuros com rapidez. Entretanto, as
demais práticas do XP ajudam a equipe
a ter agilidade e segurança, de modo
que ela possa esperar o futuro chegar para lidar
com ele. Além disso, a prática
regular de tentar se antecipar ao futuro não
parece ser das mais adequadas quando se observa
os padrões da indústria de software
na qual, segundo estudos recentes do Standish
Group, 64% das funcionalidades de um sistema
comercial típico não são
usadas quando entram em produção.
Ritmo Sustentável
Os recorrentes problemas observados nos projetos
de software levam inúmeras equipes a
trabalharem longos períodos e, por exemplo,
fazer horas-extras com freqüência
como uma tentativa de reduzir atrasos. Entretanto,
sempre que fazem isso, se esquecem de que desenvolvedores
são seres humanos que, como tais, sentem
fome, se cansam, ficam com sono, perdem a atenção
em tais circunstâncias e introduzem bugs.
Assim, é comum o tempo extra ser gasto
em vão, pois o fato de trabalhar mais
não significa que o projeto avançou.
Para progredir, é necessário que
novas funcionalidades sejam implementadas e
finalizadas, sem que haja bugs esperando para
serem identificados nas mãos dos usuários.
Projetos XP respeitam isso e seguem a filosofia
de que o mais importante não é
trabalhar mais e sim trabalhar de forma mais
inteligente, em um período de tempo semanal
que as pessoas sejam capazes de sustentar sem
ficarem esgotadas e sem prejudicarem o trabalho
com o déficit de atenção
decorrente da fadiga.
Existe uma distinção importante
entre movimento e progresso. Uma equipe que
se movimenta muita, que trabalha muitas horas,
que "dá um gás" pelo
projeto, mas produz várias coisas erradas
não está progredindo. Está
apenas consumindo energia. O importante não
é se movimentar muito, é se mover
na direção certa, de forma inteligente
e sustentável.
Integração Contínua
Quando inúmeros desenvolvedores trabalham
juntos em um mesmo projeto, é necessário
sincronizar o que estão fazendo e assegurar
que o código de um se integre corretamente
com o de outro. Esse processo de sincronização
recebe o nome de integração contínua
em XP e é executado inúmeras vezes
ao dia, pois é mais fácil integrar
pequenos incrementos de código do que
grandes blocos de código implementados
ao longo de dias de trabalho. Quando há
pouco a ser sincronizado em cada integração,
eventuais conflitos no código são
solucionados de maneira mais rápida e
problemas não se acumulam uns sobre os
outros.
Releases Curtos
Com o objetivo de receber feedback rapidamente,
não apenas da pessoa que atua como cliente
junto à equipe de desenvolvimento, mas
de toda a comunidade de usuários do sistema,
projetos XP procuram criar versões pequenas
do software, contendo poucas funcionalidades
novas, mas que sejam colocadas em produção
com freqüência. Isso permite que
os usuários tenham acesso ao software
rapidamente, de modo que a equipe não
corra o risco de investir demais em algo que
não esteja correto, ou pior, em algo
que não se revele necessário e
valorizado pelos usuários.
Conclusão
Trabalhar com Extreme Programming equivale
a encarar o desenvolvimento de software de uma
forma diferente daquela a que estamos habituados.
Trata-se de uma forma mais humana, onde todos
- clientes, desenvolvedores e demais interessados
no projeto - são identificados como pessoas
que falham e que acertam. A estrutura de desenvolvimento
criada pelo XP procura ajudar o projeto a explorar
o que as pessoas têm de melhor e solucionar
suas falhas com rapidez e segurança.
XP procura agir continuamente com priorização
para evitar que trabalhos desnecessários
sejam executados. Isso ajuda a poupar tempo,
recursos e permite gerar maior valor para os
clientes. Extreme Programming é a arte
de maximizar o trabalho que não será
feito. Pois, mais importante que trabalhar muito
e produzir muito, é produzir a coisa
certa, aquilo que o cliente realmente identifica
como sendo valioso para resolver seus problemas,
fazendo isso de forma consistente, segura e
rápida ao longo de todo o andamento do
projeto.
Vinícius Manhães Teles
(vinicius@improveit.com.br) é Mestre
em Informática pela UFRJ (DCC-IM/NCE),
Diretor da Improve It e autor do livro “Extreme
Programming – Aprenda como encantar seus
usuários desenvolvendo software com agilidade
e alta qualidade”.
Livros
Extreme Programming, Vinícius Manhães
Teles (Novatec Editora, 2004)
Visão prática sobre Extreme Programming
em português.
Extreme Programming Explained, Second Edition
Kent Beck (Addison-Wesley, 2005)
Visão geral sobre XP em inglês.
Links
www.improveit.com.br/xp
Informações sobre XP em português.
c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Wiki internacional sobre Extreme Programming.
www.agilealliance.org/articles
Vasta biblioteca de artigos sobre desenvolvimento
ágil em geral.
|
