Os quatro valores da XP são:
- Comunicação
- Simplicidade
- Feedback
- Coragem
Comunicação
Quando analisamos os problemas que ocorreram nos projetos, vemos que muitos deles forma provocados por alguém que não conversou com outro alguém sobre alguma coisa importante. Algumas vezes, o programador não fala para os outros sobre uma mudança fundamental no projeto. Outras vezes, o programador não faz a pergunta certa para o cliente, fazendo com que uma importante decisão de domínio seja prejudicada. Às vezes um gerente não faz a pergunta certa para o programador e o progresso de projeto é reportado de maneira errada.
A má comunicação não acontece por acaso. Existem muitas circunstancias que levam a um colapso nas comunicações. Um programador da más noticias ao gerente e o gerente pune o programador. O cliente diz algo importante e programador parece ignorar a informação.
A XP procura manter as comunicações certas fluindo através do emprego de muitas praticas que não podem ser feitas sem comunicação. São praticas que fazem sentido a curto prazo, como testar, programar em pares e estimar é a comunicação entre programadores, clientes e gerentes.
Isso não quer dizer que a comunicação não seja obstruída em um projeto XP. As pessoas ficam com medo, erram e se distraem. A XP emprega um “treinador” cujo trabalho é perceber quando as pessoas não estão se comunicando e restabelecer o vinculo entre elas.
Simplicidade
O treinador XP pergunta ao time: “Qual a coisa mais simples que poderia funcionar?”.
Simplicidade não é fácil. É muito difícil não antecipar aquilo que você precisara implementar amanha ou na próxima semana ou no próximo mês. Mas antecipar as coisas compulsivamente é ser influenciado pelo medo do custo exponencial da curva das modificações. Algumas vezes o treinador precisa gentilmente lembrar ao time de que eles estão sendo influenciados pelos seus medos: “Talvez você seja tão mais inteligente do que eu que possa fazer essa tal de arvore dinamicamente funcionar. Eu iria ingenuamente assumir que uma busca linear funcionaria”.
A XP esta fazendo uma aposta. Esta apostando que é melhor fazer uma coisa simples hoje e pagar um pouco mais amanha para fazer alguma modificação nela se for necessário do que fazer uma coisa mais complicada hoje que talvez nunca será usada.
Simplicidade e comunicação têm uma maravilhosa relação de suporte mutuo. Quando mais você se comunica mais claramente você vê o que precisa ser feito e tem mais certeza sobre o que não precisa. Quanto mais simples for o sistema menos você precisa comunicar sobre ele. O que nos leva a uma comunicação mais completa, especialmente se você pode simplificar o sistema o suficiente para precisar de menos programadores.
Feedback
O feedback funciona em diferentes escalas de tempo. Primeiramente o feedback funciona na escala de minutos e dias. Os programadores escrevem testes de unidade para toda a lógica do sistema que poderia não funcionar. Os programadores tem feedback concreto de minuto a minuto sobre o estado do sistema. Quando os clientes escrevem novas “historias” (descrições das características), os programadores as avaliam imediatamente. Assim os clientes tem feedback concreto sobre a qualidade de suas historias. A pessoa que rastreia o progresso observa o termino das tarefas para dar, a todo o time, feedback sobre a probabilidade de eles terminarem tudo o que foi definido para um dado período de tempo.
O feedback também funciona na escala de semanas e meses. Os clientes e testadores escrevem testes de funcionalidade para todas as historias (que na verdade são “casos de uso simplificados”) implementadas pelo sistema. Eles tem feedback concreto sobre o estado atual do sistema. Os clientes revisam o cronograma a cada duas horas ou três semanas para ver se a velocidade geral do time fecha com o plano e também para reajustar o plano. O sistema é colocado em produção assim que ele fizer sentido, para que os negócios possam começar a sentir como o sistema se comporta em ação e a descobrir como ele pode ser mais bem explorado.
Produções precoces precisam de uma pequena explicação. Uma das estratégias no processo de planejamento é o time colocar em produção as historias mais importantes assim que possível. Isso da aos programadores feedback concreto sobre a qualidade de suas decisões e sobre o processo de desenvolvimento que só é possível quando colocamos a mão na massa. Alguns programadores nunca experimentaram um sistema em produção. Com eles podem aprender a melhorar seu trabalho?
A maioria dos projetos parecem ter uma estratégia exatamente oposta. O pensamento parece ser: “Quando o sistema entrar em produção, você não pode fazer alterações interessantes, então mantenha o sistema em desenvolvimento o maior tempo possível”.
Na verdade, é o contrario. “Em desenvolvimento” é um estado temporário, em que o projeto fica uma pequena parte de sua vida. É muito melhor dar ao sistema uma vida independente, fazendo-o sobreviver por si mesmo. Você terá simultaneamente gerenciar a produção e desenvolver novas funcionalidade. É melhor se acostumar mais cedo a equilibrar a produção e o desenvolvimento do que faze-lo tarde demais.
O feedback concreto trabalha juntamente coma comunicação e a simplicidade.
Quanto mais feedback você tiver, mais fácil será se comunicar. Muitas horas de discussão podem ser poupadas se, quando alguém tiver alguma objeção ao seu código, ele lhe entregar um caso de teste que faz esse código falhar. Se você estiver se comunicando claramente, você saberá o que é preciso testar e medir para aprender sobre o sistema. Sistemas simples são mais fáceis de testar. Escrever o teste faz você se concentrar na simplicidade do sistema – antes de os teste executarem você ainda não terminou; e quando todos executarem, você terminou.
Coragem
A estratégia do projeto da XP se parece com um algoritmo para escalar uma colina. Você começa com um projeto simples, então você o transforma em algo um pouco mais complexo, e depois em um pouco mais simples, para então deixa-lo um pouco mis complexo. O problema com algoritmos para escalar colinas é alcançar o um local ótimo, onde uma pequena mudança não consegue melhorar a situação, mas uma grande mudança sim.
O que garante quer você nunca chegara a uma rua sem saída: Coragem. De vez em quando, alguém no time ira ter uma idéia louca, que talvez acabe com a complexibilidade de todo o sistema. Se eles tiverem coragem, irão colocar essa idéia em produção. Agora você esta escalando uma colina inteiramente nova. Se você não tiver definido os três primeiros valores, coragem por siso é apenas fuçar em seu próprio sistema. No entanto quando combinada com comunicação, simplicidade e feedback concreto, a coragem se torna extremamente valiosa.
A comunicação da suporte a coragem porque abre a possibilidade de mais experiências de alto risco e alta recompensa. “Você não gosta disso? Eu odeio esse código. Vamos ver o quanto dele podemos substituir em uma tarde.” A simplicidade da suporte a coragem porque você pode se dar ao luxo de ser muito mais corajoso com um sistema simples. É muito menos provável que você estrague o sistema inadvertidamente. Coragem da suporte a simplicidade porque assim que a oportunidade de simplificar o sistema é percebida, você a experimenta. O feedback concreto dá suporte à coragem porque você se sente muito mais seguro experimentando algo extremo no código se você puder pressionar um botão e ver resultados positivos nos testes (ou não, no caso de você jogar código fora).
