Valores da XP

O XP tem como base quatro valores fundamentais que sustentam as boas prticas
de desenvolvimento de software: comunicao, feedback, simplicidade e coragem.
De acordo com Beck (2005, apud CASTRO, 2007) esses valores so 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 so
fundamentais para compreender a razo e os motivos de cada boa prtica de
desenvolvimento.

1. Comunicao
Tradicionalmente na indstria do software, as equipes de desenvolvimento gastam
um valioso esforo na tentativa de trocar informaes por meio de extensos
documentos escritos. Devido ineficincia desse meio, nem sempre possvel
reproduzir com exatido uma informao e dessa forma elas so freqentemente
interpretadas de forma incorreta ou incompleta (TELES, 2006).
Geralmente,

projetos

de

software

so

produzidos

desenvolvedores, sendo assim, cada componente

por

uma

da equipe

equipe

de

precisa trocar

informaes 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
comunicao entre as pessoas, algumas vezes o cliente no conversou sobre algo
importante e, outras vezes, o desenvolvedor no soube fazer as perguntas corretas
para o cliente. Justamente por isso que a comunicao tida como um dos
elementos mais importantes no desenvolvimento de software.
Soares (2004) afirma que a melhor forma de comunicao em XP a conversa
face-a-face, pois ela permite que o interlocutor leve em conta o contedo emocional
da fala, dos gestos e da expresso facial para interpretar a informao transmitida.
Alm disso, em caso de dvidas, o interlocutor pode san-las instantaneamente.
A XP procura assegurar que a comunicao seja a mais eficiente possvel, de modo
a diminuir as falhas na comunicao e evitar re-trabalhos desnecessrios. Por isso,
a comunicao face-a-face fortemente recomendada,

por ser uma forma de

interao direta entre as pessoas, evitando-se ao mximo o uso de telefones, email e outros meios de comunicao (TELES, 2006).

2. Feedback

Segundo o dicionrio 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]
Trazendo este conceito para a realidade de desenvolvimento de software, feedback
o processo de troca de informaes que ocorre entre cliente e a equipe de
desenvolvimento durante a produo 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 so
influenciados e direcionados de acordo com a constante resposta do cliente sobre
determinada atividade. Ainda citando este autor, o feedback no exclusividade do
XP ou das metodologias geis, ela tambm est presente nos processos
tradicionais. O diferencial est nos tempos de execuo, pois nos processos
tradicionais h uma defasagem muito grande no tempo da troca de informao
entre cliente e desenvolvedores, isto ruim tanto para o cliente como para a equipe
que precisa encontrar rapidamente a soluo 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 freqentemente ter
uma parte do software funcional para avaliar e com isso, pode sugerir novas
caractersticas

ao

mesmo

tempo

em

que

pode

identificar

eventuais

no

conformidades com os requisitos. E assim, os desenvolvedores podem implementar

rapidamente novas caractersticas e corrigir

eventuais erros j nas prximas

verses a serem entregues ao cliente (SOARES, 2004).

Da mesma forma que os desenvolvedores se beneficiam com o constante feedback
do cliente, o contrrio tambm acontece quando os desenvolvedores fornecem ao
cliente o seu feedback. Segundo Teles (2006) isto acontece quando eles
apresentam estimativas, riscos tcnicos, alternativas de design, entre outros. A
partir dessas informaes e da manipulao constante de um prottipo 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 discusses sobre o mesmo, fundamental para
compreender os desafios que existe no desenvolvimento de software.

Traduo livre: Um mecanismo de comunicao dentro de um sistema em que o

sinal de entrada gera uma sada que retorna resposta continua a influenciar a
atividade ou a produtividade do sistema.

3. Simplicidade
Simplicidade em XP refere-se a desenvolver apenas o suficiente para atender as
necessidades atuais do cliente, desprezando qualquer funcionalidade no essencial.
Mesmo que tal funcionalidade esteja ligada com a evoluo do produto, ela deve
ser descartada at que se tenha absoluta certeza da sua necessidade. Assume-se
assim a seguinte estratgia: desenvolver algo simples hoje e fazer modificaes
futuramente, ao invs de desenvolver algo complexo hoje e correr o risco de no
ser utilizado no futuro (SOARES, 2004).
Segundo Teles (2006), ao codificar uma funcionalidade pensando em problemas
futuros, o desenvolvedor recorre a um erro muito

freqente: o trabalho

especulativo. Trabalho este em que o desenvolvedor para ganhar tempo assume

algumas premissas das quais no 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 alm do necessrio, ele investe
tempo e dinheiro em algo que pode nunca ser utilizado.
Conclui-se ento que o principal objetivo da simplicidade na XP evitar o retrabalho
resultante da precipitao 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 convico da sua eficincia e tenham determinao em
adotar as boas prticas. A coragem acima de tudo uma forma de pensamento
diferenciado que deve ser adotado por todos os membros da equipe. Isto significa
que as mudanas que ocorrem no projeto no 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 comunicao entre
desenvolvedores e clientes, pois no so todas as pessoas que possuem facilidade

de comunicao e conseguem manter um bom relacionamento. necessrio

tambm coragem para aplicar refactoring em um cdigo que est funcionando
corretamente somente para torn-lo mais simples.
Segundo Teles (2006), XP no tem uma frmula mgica 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 prtica recomendada. Os riscos
de aplicar tais tcnicas so conhecidos, mas a confiana de que elas sero
benficas para o projeto encorajam a equipe a sempre aplic-las quando forem
necessrias.