Metodologia XP (eXtreme Programming) – Boas Práticas da XP – parte 2

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, continuaremos abordando o tópico “Boas Práticas da XP – parte 2” que consiste em mais 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 2

7. Testes de unidade

Uma das preocupações da XP é a qualidade do código produzido e nada garante tão bem que um código esteja funcionando corretamente do que um teste. Por isso, os programadores da XP escrevem testes automatizados antes mesmos de codificar uma funcionalidade. Dessa forma eles aprofundam o conhecimento da funcionalidade em questão, além de poder sempre contar com testes que validem o sistema em qualquer momento do projeto (CASTRO, 2007; TELES, 2006).

Segundo Astels et al (2002), existem dois motivos para fazer testes:

Eles descrevem a tarefa que o código a ser testado deve executar e com base nisso o desenvolvedor consegue se concentrar apenas no essencial para passar no teste, evitando assim que ele perda de tempo em algo que não será utilizado.

Eles são uma garantia de que o sistema está funcionando da forma como deveria, dessa forma o desenvolver avança mais rapidamente no projeto, pois tem a confiança de que o código não foi quebrado durante uma alteração qualquer.

Ainda citando este autor, ele aponta três momentos durante o desenvolvimento que se devem aplicar os testes:

Antes o refactoring – para ter certeza que o código está funcionado corretamente antes de qualquer alteração.
Após o refactoring – para ter certeza que as modificações não alteraram o comportamento externo do sistema.
Após a integração – para ter certeza que não houve conflitos entre os códigos integrados.

As metodologias tradicionais encaram os testes como um gasto desnecessário no projeto, mas em XP eles são vistos como uma forma de investimento que garante produtividade no médio e longo prazo. Certamente que as equipe consomem um tempo considerável na criação dos testes, entretanto eles ajudam a reduzir a ocorrência de erros e defeitos no sistema e quando ocorre, o tempo gasto na busca por esses erros é infinitamente menor, graças aos testes automatizados (TELES, 2006).

8. Código coletivo

Uma equipe de XP trabalha com a prática de propriedade coletiva do código, ou seja, cada membro da equipe pode trabalhar em qualquer parte do sistema a qualquer momento. Caso um desenvolvedor encontre alguma coisa que possa ser melhorada, ele não precisa solicitar que outra pessoa o faça por não seu o “dono” daquele código. Essa prática permite que o sistema evolua mantendo o código o mais simples possível, pois sempre que um membro encontra algo confuso, ele tem a liberdade de aplicar o refactoring (Astels et al, 2002).

Equipes que trabalham com propriedade de código tendem a criar pessoas dentro da equipe com conhecimento especializado, e isso se torna um transtorno quando ocorre um imprevisto e tais pessoas são afastadas do projeto por uma razão, como por exemplo, em casos de doenças ou demissões. Para evitar este tipo de problema a XP utiliza-se do código coletivo, que além de evitar “ilhas de conhecimento”, cria mais um mecanismo de revisão constante, uma vez que um código escrito hoje por uma dupla acaba sendo manipulado por outra no dia seguinte (TELES, 2006).

9. Código padronizado

Como todos os desenvolvedores têm acesso a todo o código, é necessário que se estabeleça um padrão de codificação e que todos concordem voluntariamente em segui-lo, assim o sistema será homogêneo e permitirá que qualquer um compreenda facilmente e não tenha dificuldades para manipulá-lo caso seja necessário (TELES, 2006).

Segundo Beck (2000, apud CASTRO, 2007) a equipe deve adotar um padrão que exigia a menor quantidade possível de trabalho, ou seja, quanto menos código duplicado tiver, melhor. Além disso, a padronização do código deve ser encarada como um meio de comunicação entre a equipe. Por isso, ela deve ser clara, objetiva e entendida por todos da equipe.

10. Integração continua

Segundo Soares (2006), integração continua é a prática de construir o software várias vezes por dia, o que possibilita uma constante sincronia entre os desenvolvedores. Esta prática é aconselhada para evitar surpresas e assegurar que o sistema esteja sempre funcionando de forma harmoniosa a cada nova integração. Não é raro uma integração causar erros no sistema. Por isso, a cada integração, os pares devem executar todos os testes para verificar a integridade do sistema. Dessa forma é possível descobrir os defeitos rapidamente e corrigi-los antes que se tornem problemas maiores no futuro.

11. Reunião diária

De acordo com Teles (2006), as equipes XP sempre começam um dia de trabalho com uma reunião de no máximo 10 minutos. Nesse momento, cada desenvolvedor têm oportunidade de comentar rapidamente sobre o que realizou no dia anterior, e assim todos tem conhecimento sobre o andamento geral do projeto. Ainda nessa reunião, a equipe aproveita para priorizar as atividades que serão realizadas ao longo do dia.

12. Ritmo sustentável

Segundo Borborema (2007), essa prática consiste em trabalhar respeitando os limites físicos e demonstrando respeito pela individualidade de cada membro da equipe. Dessa forma, para que uma equipe seja criativa e produza software com qualidade, ela precisa estar saudável do ponto de vista físico e mental. Para isso, a XP recomenda que a carga horária de trabalho não ultrapasse 8 horas diárias e 40 horas semanais.

Muitos gerentes de projetos utilizam a prática de estender a jornada de trabalho para compensar atrasos no cronograma do projeto, mas estudos comprovam que essa solução tem resultados apenas nos primeiros dias. Trabalhar vários dias além do horário, além de causar um cansaço físico e mental, causa um sentimento desmotivador e conseqüentemente o desempenho da equipe será bem menor (TELES, 2006).

Continue lendo essa série de artigos sobre em Metodologia XP ( eXtreme Programming ) – Comparativos entre as metodologias

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