Metodologia XP (eXtreme Programming) – Valores da XP

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 “Valores da XP” onde estudaremos os quatros valores que fundamentam a razão das boas práticas de desenvolvimento utilizadas na extreme programming.

Sumário do artigo “Metodologia XP”:

Valores da XP

O XP tem como base quatro valores fundamentais que sustentam as boas práticas de desenvolvimento de software: comunicação, feedback, simplicidade e coragem. De acordo com Beck (2005, apud CASTRO, 2007) esses valores são essenciais para guiar o desenvolvimento de software, mas cada equipe XP pode definir outros valores que acreditem ser relevantes dentro da sua realidade. O importante é que a equipe tenha entendido muito bem esses quatro primeiros valores, pois eles são fundamentais para compreender a razão e os motivos de cada boa prática de desenvolvimento.

1. Comunicação

Tradicionalmente na indústria do software, as equipes de desenvolvimento gastam um valioso esforço na tentativa de trocar informações por meio de extensos documentos escritos. Devido à ineficiência desse meio, nem sempre é possível reproduzir com exatidão uma informação e dessa forma elas são freqüentemente interpretadas de forma incorreta ou incompleta (TELES, 2006).

Geralmente, projetos de software são produzidos por uma equipe de desenvolvedores, sendo assim, cada componente da equipe precisa trocar informações entre si e com o cliente sobre cada detalhe do projeto. Segundo Beck (2000, apud BORBOREMA, 2007), os problemas mais comuns ocorrem por erro de comunicação entre as pessoas, algumas vezes o cliente não conversou sobre algo importante e, outras vezes, o desenvolvedor não soube fazer as perguntas corretas para o cliente. Justamente por isso que a comunicação é tida como um dos elementos mais importantes no desenvolvimento de software.

Soares (2004) afirma que a melhor forma de comunicação em XP é a conversa face-a-face, pois ela permite que o interlocutor leve em conta o conteúdo emocional da fala, dos gestos e da expressão facial para interpretar a informação transmitida. Além disso, em caso de dúvidas, o interlocutor pode saná-las instantaneamente.

A XP procura assegurar que a comunicação seja a mais eficiente possível, de modo a diminuir as falhas na comunicação e evitar re-trabalhos desnecessários. Por isso, a comunicação face-a-face é fortemente recomendada, por ser uma forma de interação direta entre as pessoas, evitando-se ao máximo o uso de telefones, e-mail e outros meios de comunicação (TELES, 2006).

2. Feedback

Segundo o dicionário Sensagent (2009), feedback é:

“A mechanism of communication within a system in that the input signal generates an output response which returns to influence the continued activity or productivity of that system.” [1]

Tradução livre: “Um mecanismo de comunicação dentro de um sistema em que o sinal de entrada gera uma saída que retorna resposta continua a influenciar a atividade ou a produtividade do sistema”.

Trazendo este conceito para a realidade de desenvolvimento de software, feedback é o processo de troca de informações que ocorre entre cliente e a equipe de desenvolvimento durante a produção de um software.

Para Teles (2006) um feedback constante é a base de todos os processos ágeis de desenvolvimento, e é a filosofia fundamental da XP, pois é ele que permite uma maior produtividade, uma vez que os trabalhos da equipe de desenvolvimento são influenciados e direcionados de acordo com a constante resposta do cliente sobre determinada atividade. Ainda citando este autor, o feedback não é exclusividade do XP ou das metodologias ágeis, ela também está presente nos processos tradicionais. O diferencial está nos tempos de execução, pois nos processos tradicionais há uma defasagem muito grande no tempo da troca de informação entre cliente e desenvolvedores, isto é ruim tanto para o cliente como para a equipe que precisa encontrar rapidamente a solução que atenda as necessidades de ambas as partes.

O contato incessante entre o cliente e a equipe de desenvolvimento é o que se pode chamar de feedback constante. Dessa forma, o cliente pode freqüentemente ter uma parte do software funcional para avaliar e com isso, pode sugerir novas características ao mesmo tempo em que pode identificar eventuais não conformidades com os requisitos. E assim, os desenvolvedores podem implementar rapidamente novas características e corrigir eventuais erros já nas próximas versões a serem entregues ao cliente (SOARES, 2004).

Da mesma forma que os desenvolvedores se beneficiam com o constante feedback do cliente, o contrário também acontece quando os desenvolvedores fornecem ao cliente o seu feedback. Segundo Teles (2006) isto acontece quando eles apresentam estimativas, riscos técnicos, alternativas de design, entre outros. A partir dessas informações e da manipulação constante de um protótipo funcional, o cliente aprende mais sobre aquilo que seria adequado para se produzir no software. Para este autor, perceber que o cliente aprende na medida em que utiliza o software e se envolve em discussões sobre o mesmo, é fundamental para compreender os desafios que existe no desenvolvimento de software.

3. Simplicidade

Simplicidade em XP refere-se a desenvolver apenas o suficiente para atender as necessidades atuais do cliente, desprezando qualquer funcionalidade não essencial. Mesmo que tal funcionalidade esteja ligada com a evolução do produto, ela deve ser descartada até que se tenha absoluta certeza da sua necessidade. Assume-se assim a seguinte estratégia: desenvolver algo simples hoje e fazer modificações futuramente, ao invés de desenvolver algo complexo hoje e correr o risco de não ser utilizado no futuro (SOARES, 2004).

Segundo Teles (2006), ao codificar uma funcionalidade pensando em problemas futuros, o desenvolvedor recorre a um erro muito freqüente: o trabalho especulativo. Trabalho este em que o desenvolvedor para “ganhar tempo” assume algumas premissas das quais não tem absoluta certeza e implementa uma funcionalidade que possa ser utilizada no futuro, mas na maioria das vezes ele erra ao assumir essas premissas e dessa forma é preciso refazer todo o trabalho. Teles ainda afirma sobre os riscos de assumir o trabalho especulativo, pois quando o desenvolvedor implementa uma funcionalidade além do necessário, ele investe tempo e dinheiro em algo que pode nunca ser utilizado.

Conclui-se então que o principal objetivo da simplicidade na XP é evitar o retrabalho resultante da precipitação em especular requisitos futuros.

4. Coragem

A XP é uma metodologia de software que se baseia em diversas premissas que contrariam os processos tradicionais de desenvolvimento, justamente por isso, é preciso que a equipe tenha convicção da sua eficiência e tenham determinação em adotar as boas práticas. A coragem é acima de tudo uma forma de pensamento diferenciado que deve ser adotado por todos os membros da equipe. Isto significa que as mudanças que ocorrem no projeto não devem ser encaradas negativamente apenas como problemas a serem resolvidos, mas sim como oportunidades a serem exploradas para a melhoria como um todo da equipe e do projeto.

De acordo com Soares (2004) é preciso coragem para implantar comunicação entre desenvolvedores e clientes, pois não são todas as pessoas que possuem facilidade de comunicação e conseguem manter um bom relacionamento. É necessário também coragem para aplicar refactoring em um código que está funcionando corretamente somente para torná-lo mais simples.

Segundo Teles (2006), XP não tem uma fórmula mágica para eliminar todos os riscos presentes no desenvolvimento de software, eles existem como em qualquer outra forma de desenvolvimento, o que diferencia XP das outras metodologias é a forma de lidar com estes riscos. Em XP, por exemplo, é natural quebrar o que estava funcionando simplesmente para aplicar uma prática recomendada. Os riscos de aplicar tais técnicas são conhecidos, mas a confiança de que elas serão benéficas para o projeto encorajam a equipe a sempre aplicá-las quando forem necessárias.

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

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