4.2.4. [XP] Coragem

4.2.4. Coragem

Ter coragem é agir de forma efetiva em face do medo. Certamente é verdade que as pessoas envolvidas no desenvolvimento de software sentem medo. É como elas lidam com seus medos que vai influenciar na qualidade do trabalho ou não.

Às vezes a coragem manifesta-se como uma propensão a uma ação. Se você souber qual é o problema, faça algo sobre ele. Às vezes coragem manifesta-se como paciência. Se você sabe que há um problema mas não sabe a solução, é preciso coragem para esperar o problema tornar-se claro [BECK, 2004].

Os valores da XP trabalham melhor em conjunto e em muitos casos são essenciais uns aos outros. O feedback é melhor com comunicação e simplicidade. A simplicidade é melhor com comunicação e feedback. A comunicação é melhor com simplicidade e feedback. Com o valor coragem não é diferente.

Utilizar o valor coragem de forma isolada é agir sem se preocupar com as conseqüências, o que é muito perigoso e desestimulante para o trabalho em equipe. Para diminuir riscos e encorajar o trabalho em equipe é recomendável sempre considerar todos os valores, não somente a coragem, na hora de tomar uma decisão numa situação em que o medo estiver presente.

Se a coragem sozinha é perigosa, em harmonia com os outros valores é poderosa. A coragem para falar verdades, agradáveis ou desagradáveis, estimula a comunicação e a confiança. A coragem para descartar soluções fracassadas e buscar novas, estimula a simplicidade. A coragem para sempre buscar respostas concretas cria feedback [BECK, 2004].

A XP é uma metodologia de software nova que se baseia em diversas premissas. Algumas destas premissas já foram detalhadas nesta monografia, as outras estão detalhadas nos próximos capítulos. Todas as premissas são novas e contrariam os processos tradicionais de desenvolvimento, por isto mesmo, é preciso ter coragem para adotá-las. Segue abaixo uma listagem [TELES, 2004, pg. 50] das principais premissas da XP:

· Desenvolver o software de forma incremental;

· Manter o sistema simples;

· Permitir que o cliente priorize as funcionalidades;

· Fazer os desenvolvedores trabalharem em par;

· Investir tempo em refactoring;

· Investir tempo em testes automatizados;

· Estimar as estórias na presença do cliente;

· Expor o código a todos os membros da equipe;

· Integrar o sistema diversas vezes ao dia;

· Adotar um ritmo sustentável;

· Abrir mão de documentações que servem como defesa;

· Propor contratos de escopo variável;

· Propor a adoção de um processo novo.

\o ‘s,
ViniciusAC.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s