Metodologia XP (eXtreme Programming) – Boas Práticas da XP - Parte 1

Esta série de artigos sobre Metodologia XP de desenvolvimento é uma versão compacta do trabalho de conclusão de curso (TCC) onde o título original da monografia em que foi baseada esta série é:

O USO DA METODOLOGIA XP NO DESENVOLVIMENTO DE SOFTWARE E OS IMPACTOS NA GESTÃO DE RISCOS

Toda semana, sempre às segundas-feiras, postaremos uma parte ou capítulo da monografia, o que totalizará 10 semanas de postagens. No capitulo de hoje, abordaremos o tópico “Boas Práticas da XP – parte 1” que consiste em seis atividades práticas de desenvolvimento que as equipes de XP trabalham no dia a dia.

Sumário do artigo “Metodologia XP”:

Boas Práticas da XP – parte 1

Os valores apresentados até aqui são considerados os “alicerces” da XP, pois eles que oferecem sustentação às boas práticas adotadas pelas equipes de desenvolvimento.

As boas práticas da XP são um conjunto de atividades que as equipes XP utilizam enquanto produzem softwares. Antes de qualquer coisa, é necessário ter confiança nestas boas práticas e consciência de que elas devem ser aplicadas em conjunto. Quando aplicadas isoladamente, elas não trazem os mesmos resultados por que os pontos fracos de cada prática são protegidos pelos pontos fortes das outras práticas (BORBOREMA, 2007).

1.Cliente presente

Em projetos XP é essencial que o cliente participe ativamente do desenvolvimento. Essa talvez seja uma prática muito extrema, mas a XP acredita que é somente a presença constante do cliente que viabiliza a simplicidade dos processos e a clara comunicação com os desenvolvedores. Tendo o cliente sempre presente, quaisquer dúvidas dos desenvolvedores são sanadas rapidamente, mas para isso, o cliente deve possuir capacidade para responder perguntas sobre o negócio e autoridade suficiente para tomar decisões relativas a prioridades no projeto (ASTELS et al , 2002; TELES, 2006).

2. Releases e iterações

Release é um conjunto de funcionalidades que representa uma pequena versão do sistema com recursos completos e relevantes para o cliente. Dessa forma, a versão é colocada em produção o mais rápido possível, para que o cliente possa usufruir do investimento no software ao mesmo tempo em que avalia e retorna um feedback para os desenvolvedores sobre o release (TELES, 2006).

Além de fragmentar todo o projeto em releases, cada release é fragmentado em pequenas partes chamadas iterações. Elas são utilizadas para refinar cada vez mais os requisitos do release, para que ao término dela o cliente possa receber um produto que atenda o máximo de suas necessidades e expectativas daquele momento. O tempo de cada release e iteração depende da complexidade do projeto, mas em geral, releases costumam durar em torno de oito semanas, enquanto as iterações duram em torno de duas semanas (BORBOREMA, 2007).

Esta prática, segundo Astels et al (2002), deve ser utilizada para que alguns usuários possam utilizar o software e avaliar, pois dessa forma vários tipos de defeitos podem ser detectados rapidamente, possibilitando à equipe de desenvolvimento saber se está no caminho certo ou não.

3. Jogo do Planejamento

Segundo Astels et al (2002), é fato que em desenvolvimento de softwares, seja ele de que tamanho for, é preciso que haja um planejamento de projeto, mas isso não significa elaborar um plano minucioso e detalhado que demore semanas ou até meses para ser finalizado. Os planejamentos na maioria das vezes não são precisos e mudam consideravelmente durante o andamento do projeto, quanto mais longo for o prazo de planejamento, maior a probabilidade da imprecisão.

No início de cada iteração a equipe de desenvolvimento estimula o cliente a escrever as funcionalidades que deseja no sistema em pequenos cartões chamados user stories. Uma user story é a menor quantidade de informação que o cliente pode definir para uma determinada funcionalidade do projeto e de acordo com a complexidade da user story, a equipe de desenvolvimento estima o tempo e o custo que aquela funcionalidade irá custar para o cliente. Ciente do tempo e custo, o cliente deve decidir a ordem que cada user story deve ser desenvolvida, ou seja, ele tem a oportunidade de priorizar as funcionalidades sabendo exatamente o tempo e quanto irá lhe custar. Esta prática realizada no início de cada iteração é conhecida como Jogo de Planejamento e assegura que a equipe esteja sempre trabalhando no que é mais importante e gere mais valor para o cliente (ASTELS et al, 2002; TELES, 2006).

4. Metáfora

Segundo Teles (2006) as metáforas tem o poder de transmitir ideias complexas de forma simples e clara. Por isso, a XP as utilizam para criar uma visão comum do projeto entre cliente e desenvolvedores. Beck (2000, apud BORBOREMA, 2007) afirma também que as metáforas devem ser estabelecidas de acordo com o vocabulário que o cliente está habituado no dia a dia, pois assim a compreensão fica mais fácil e a comunicação é beneficiada.

5. Programação em par

Para Borborema (2007), na programação em par dois desenvolvedores escolhem uma user story e sentam-se em um único computador para codificar uma determinada funcionalidade. O desenvolvedor com menor experiência tem como responsabilidade assumir o controle do teclado e conduzir ativamente a programação do código fonte, enquanto o outro desenvolvedor com maior experiência inspeciona o código a procura de erros e defeitos, além de questionar decisões e pensar estrategicamente em soluções mais simples para o código.

Semelhante a outras boas práticas, a programação em par é um investimento que a equipe faz para sempre buscar as soluções mais eficientes e eficazes. Teles (2006) afirma que na programação em par os desenvolvedores estão constantemente discutindo sobre as melhores alternativas, dessa forma um ajuda o outro quando uma solução está muito complexa. Além disso, a programação em par trás outros benefícios para o projeto, como por exemplo, a revisão constante do código que ajuda na detecção de erros rapidamente, e a disseminação do conhecimento entre os pares, que ajuda no nivelamento técnico de toda a equipe.

Segundo Astels et al (2002), programar uma funcionalidade em par é tão produtivo quanto programar a mesma funcionalidade sozinho, ou seja, a programação em par não afeta a velocidade do desenvolvimento, mas afeta diretamente a qualidade do código, uma vez que o código gerado por um par tende a ser mais eficiente e a quantidade de erros é bem menor. Além das vantagens já citadas com a programação em par, essa prática também proporciona a “pressão do parceiro”, que é uma forma saudável de manter um senso de disciplina durante a jornada de trabalho.

6. Refactoring

Refactoring é o processo de reorganizar o código fonte de um software para melhorar sua qualidade interna, facilitar a leitura e diminuir o tempo gasto com manutenção, sem contudo prejudicar o desempenho e alterar seu comportamento externo. Aplicado em sistemas orientados a objetos, a técnica é fundamental para tornar o código mais legível e encontrar facilmente erros em algoritmos mal escritos (NETO, 2007).

Segundo Teles (2006), um projeto em XP não existe sem a prática de refactoring, pois a agilidade necessária para alterar e incluir novas funcionalidades constantemente em um sistema só é possível com um código de alta qualidade que seja organizado e de fácil compreensão. Para que isso aconteça, a XP determina que qualquer um da equipe faça o refactoring em qualquer parte do código que esteja pouco legível.

Ainda citando Teles, ele admite que a prática de refactoring traz um grande risco de fazer com que um código que estava funcionando corretamente pare de funcionar. No entanto, é possível reduzir esse risco conhecendo bem as técnicas de refactoring e testando constantemente o código. Os testes garantem uma segurança para aplicação de refactoring, pois após cada alteração, eles informam se o código continua produzindo os mesmos resultados.

Continue lendo essa série de artigos sobre em Metodologia XP ( eXtreme Programming ) – Boas Práticas da XP – parte 2

Observação: Todos as referências serão creditadas no último artigo da série.

Metodologia XP (eXtreme Programming) – Boas Práticas da XP – Parte 1