continua representando um tempo muito longo para o feedback do cliente. Por esta razao os releases sao divididos em espacos menores, chamados de iteracoes .Uma iteracao contem um conjunto de estorias a serem implementadas, com duracao entre uma a tres semanas, onde ao final da mesma o cliente possa validar as implementacoes efetuadas e fornecer o feedback necessario a equipe.2.2.3 Stand up meetingO dia de trabalho de uma equipe XP sempre comeca com um stand up meeting . e uma reuniao rapida pela manha, com aproximadamente 20 minutos de duracao e onde seus integrantes permanecam preferencialmente em pe.Segundo estudos uma reuniao em pe e mais rapida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, agil e simples.A reuniao tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiencias das dificuldades enfrentadas. Neste momento tambem sao decididas as estorias que serao implementadas no dia e em conjunto definir os responsaveis por cada uma delas.2.2.4 Programacao em parO XP exige que todo e qualquer codigo implementado no projeto seja efetuado em dupla, chamada de programacao em par. e uma tecnica onde dois desenvolvedores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles e responsavel pela digitacao (condutor) e outro acompanhando o trabalho do parceiro (navegador).Esta pratica agrega diversas tecnicas de programacao, enquanto o condutor codifica o problema o navegador permanentemente revisa o codigo digitado, onde pequenos erros de programacao que demoraria algumas horas para serem depurados, facilmente sao percebidos pelo navegador da dupla.Um dos grandes beneficios da programacao em par e a troca de experiencias e ideias entre os desenvolvedores. A solucao para um problema geralmente e a soma das ideias da dupla, tornando uma solucao e codificacao muito mais simples e eficaz.e com esta pratica que o XP uniformiza o nivel dos desenvolvedores da equipe, atraves da troca de experiencias. Apos alguns meses trabalhando em duplas todos os desenvolvedores conhecerao todas rotinas do sistema, prontos para qualquer modificacao ou para auxiliar algum iniciante.Um grande questionamento sobre esta pratica e com questao a produtividade dos desenvolvedores. Porem, e um erro pensar que somente uma pessoa estara codificando enquanto o outro apenas observa. O membro que nao esta codificando nao apenas observa, mas tambem troca ideias, gera solucoes e evita praticamente todos erros de codificacao alem de cobrar padroes de desenvolvimento da equipe.Estudos indicam que a produtividade de uma equipe que utiliza pair programming e de equipes que tenham desenvolvedores sozinhos e praticamente a mesma, porem a qualidade do codigo gera facilidade de manutencao e outros ganhos a medio e longo prazo.2.2.5 RefactoringUm desenvolvedor ao deparar com um codigo mal escrito ou pouco legivel mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alteracoes neste codigo, mesmo que tivesse que implementar novas funcionalidades.O XP prega que todo desenvolvedor ao encontrar um codigo duplicado, pouco legivel, mal codificado, sem padronizacao, lento, com codigo legado ou uso incorreto de outras implementacoes, tem por obrigacao alterar este codigo deixando-o mais legivel e simples, porem esta alteracao nao pode mudar