Tipicamente um cliente que necessita de um sistema informático tem um conjunto de problemas que pretende resolver, tendo já inclusive algumas ideias sobre como o fazer. Por outro lado as equipas que desenvolvem o software têm o Know-How técnico que lhes permite construir um sistema tendo em conta as melhores práticas. Para que exista um entendimento entre o cliente que fala uma linguagem mais voltada para o négocio e os programadores que falam uma linguagem mais técnica é necessário que exista um bom canal de comunicação.

Quanto melhor for o canal de comunicação menos possibilidades existem de criação de problemas, ambiguidades e desentendimentos.

Por norma, os diálogos cara a cara são superiores a uma videoconferência, que é superior a um telefonema que por sua vez é mais expressivo que um email.

Uma das ferramentas que é utilizada no XP é o diálogo cara a cara, permitindo desta forma que o entendimento entre todas as partes seja o mais correto possível. Desta forma evitam-se problemas que possam surgir mais tarde, até porque quanto mais cedo os problemas forem detetados menos custos estarão envolvidos na sua resolução.

Um projeto de software está constantemente sujeito à mudança. Os clientes mudam de ideias com alguma frequência, seja porque as prioridades mudam, seja porque percebem que existem formas mais eficazes de resolver os seus problemas. Qualquer mudança não planeada realizada a meio de um projeto acarreta riscos, pois por vezes é necessário alterar blocos do sistemas que já estavam fechados, existindo a possibilidade de provocar bugs (erros informáticos).

O XP não tem uma fórmula mágica para resolver este problema, mas utiliza uma série de mecanismos de proteção que permite enfrentar a mudança com uma coragem renovada.

Assim ao invés de bloquear a criatividade do cliente, uma equipa XP enfrenta com segurança e coragem o desconhecido.

Os projetos de software são normalmente iniciativas muito dispendiosas, arriscadas e com um histórico de falhas muito alto. As equipas XP sabem isso melhor que ninguém, e encaram todos os projetos como uma eventual potencialidade de problemas e falhas que possam advir.

Todas estas falhas podem ser minimizadas se forem identificadas rapidamente e numa fase inicial. É por isso que no XP estabelecem-se ciclos de desenvolvimento curtos, onde são apresentados pequenos pacotes de funcionalidades ao cliente. Assim é possível deste logo alinhar as expectativas do cliente com as expetativas da equipa de desenvolvimento, favorecendo ambas as partes. O cliente sai beneficiado pois desempenha um papel mais ativo na construção do sistema (aumentando a probabilidade de sucesso do projeto), e a equipa de desenvolvimento beneficia de uma menor probabilidade de falhas e problemas futuros (que originam muito rework).

Respeito é o valor mais importante de todos. Os membros de uma equipa só vão funcionar como “equipa” se existir respeito mútuo entre todos eles. Se não existir respeito mútuo no seio de uma equipa então não existe muito que se possa fazer para salvar um projeto de uma catástrofe.

Saber ouvir e saber compreender o ponto de vista de um colega é essencial para o sucesso de um projeto de software.

Estudos recentes demonstram que uma grande percentagem de todas as funcionalidades desenvolvidas num sistema informático não chegam sequer a ser utilizadas.

O XP baseia-se no princípio de simplicidade, onde se dá prioridade a funcionalidades realmente necessárias ao bom funcionamento do sistema, evitando funcionalidades que podem vir a ser necessárias no futuro, mas que ainda não o provaram ser.

Por outras palavras, primeiro construímos um automóvel capaz de circular, depois preocupamo-nos com a marca do auto-rádio e se o volante tem ou não botões que o controlam.

Por hoje é tudo, num post mais à frente prometo aprofundar um pouco mais sobre este tema.

Até à próxima :)