o projeto, uma vez que facilita a comunicacao e fixacao dos assuntos entre as partes. Esta pratica anda em conjunto com o ritmo sustentavel, ja que para o desenvolvedor criar boas metaforas exige criatividade e desenvolvimento de ideias, o que torna necessario uma boa condicao fisica e bem estar por parte do desenvolvedor. 2.2.11 Ritmo sustentavel Uma grande problema nos projetos de software e a falta de tempo para encerrar o mesmo, e uma das tecnicas mais adotadas para compensar a falta de tempo e submeter os desenvolvedores (humanos) a trabalharem ate mais tarde e muitas vezes sacrificarem seus finais de semana. Nos primeiros momentos este tipo de atitude tem efeitos positivos, porem passado alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentracao no desenvolvimento, justamente pelo cansaco fisico do desenvolvedor. O XP proibe que os desenvolvedores trabalhem ate mais tarde. O XP sugere um ritmo sustentavel de 40 horas semanais, respeitando assim a individualidade e o fisico de cada desenvolvedor. Desta forma a equipe estara sempre concentrada e muito menos propensa a pequenas falhas na implementacao. 2.2.12 Integracao continua No desenvolvimento tradicional geralmente as equipes sao organizadas de modo que uma parte (modulo) fiquei sob responsabilidade de um desenvolvedor, cabe a esta pessoa efetuar testes e codificacao que dizem respeito a sua parte. Esta estrategia reduz a complexidade e as preocupacoes de um desenvolvedor. Interfaces de integracao sao convencionadas para que futuramente estas partes possam se comunicar, este tipo de desenvolvimento esta propenso a serios erros de integracao, uma vez que os periodos em que as partes sao integradas e testadas sao extremamente longos. O XP propoe uma integracao continua, se possivel deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do codigo recem desenvolvido. Com esta pratica o feedback sobre a alteracao efetuada sera retornado em um menor espaco de tempo. 2.2.13 Releases curtos No modelo tradicional o projeto e dividido em fases, de um modo que o cliente comecara a ter beneficio com o sistema muito proximo de o mesmo estar finalizado. A maior parte do investimento do projeto e feita antes mesmo de estar concluido, sem ter gerado qualquer tipo de valor economico ao cliente. O XP recomenda que pequenos investimento sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possivel. Com a pratica de releases curtos, o XP pretende dar o maximo de valor economico ao cliente em um curto espaco de tempo. Release e um conjunto de funcionalidade bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento. 2.3 Equipe XP Em uma equipe de XP existem papeis a serem desempenhados por um ou mais desenvolvedores. Estes papeis serao listados a seguir. 2.3.1 Gerente de projeto Pessoa responsavel pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento. O gerente de projeto e responsavel por filtrar assuntos nao relevantes aos desenvolvedores e aspectos que so