Um fator interessante do desenvolvimento ágil é a nova proposta de desenvolvimento. Quem está acostumado com desenvolvimento de software tradicional está acostumado no desenvolvimento "cachoeira". Esta desenvolvimento se dá num programa de tarefas como:

• Fazer especificação
  Aqui você vai ouvir seu cliente. O analista pega sua pastinha debaixo do braço e vai perguntar. Qual é a necessidade do cliente? A partir disto ele vai modelar o problema, como as partes vão se interagir e vai partindo do nível mais alto da modelagem até chegar no próximo passo.
  
  
• Codificar
  Aqui é colocada a mão na massa e no teclado. Seguindo cegamente a especificação. Geralmente mudar a especificação é voltar um passo. Então a relação com o cliente é mais reduzida e quando é preciso mudar a especificação tenta-se convencer o cliente que isto não é desejável.
  
  
• Testar
  Aqui pode se incluir uns releases beta e criação de bugs e fechamento dos mesmos.
  
  
• Lançamento
  Seu cliente passa a ter acesso ao software e conhece o programa que ele tanto queria e pagou por isso.
  
  
• Fechamento de bugs
  Aqui sua relação é mais de suporte. Adição de novas funcionalidades eventualmente e principalmente correção de problemas.

Existe uma possibilidade grande de que no final o software não seja nem o que o cliente queria. O XP condena isso e aponta outros meios. Analisemos abaixo cada agente dessa relação:

Seu cliente:

Ele é o financiador do projeto. É a peça mais importante do desenvolvimento, sem ele não existiria projeto, não existiria salário, não existiria nada! Ouvir ele é fundamental. E ouvir ele é saber as necessidades dele. Importante analisar com cuidado esta questão. O cliente muitas vezes não tem conhecimento técnico. Pra ele é indiferente a forma como você desenvolve, ele quer resultados e vai cobrar por isso. A tarefa do analista ou gerente de projeto é entender ele de forma a entrar no mundo dele. Não queremos menosprezar o cliente. O que acontece é que ele não é técnico e as vezes até não sabe como atingir seus objetivos.

O desenvolvedor:

Muitas vezes o que ocorre é no sentido inverso. O desenvolvedor é muito técnico e não consegue entender o cliente. O desenvolvedor pode ser o mais cego de todos. Não ter a capacidade de enxergar as necessidades do usuário e não ter a capacidade de enxergar as necessidades do cliente. Um lição importante que o tempo ensina para as pessoas da área da computação é que GERALMENTE o melhor padrão técnico nunca se torna um padrão de mercado. Isso porque para os usuários suas necessidades são imediatistas. São os técnicos que apontam tendências mas são os usuários que fazem um padrão se tornar consolidado. E os usuários não olham tendências.

Usuários:

Estes, como já foi dito, são seres de necessidades imediatistas. Eles não tem visão geral. Em algumas categorias de software costumam ser chatos com coisas pequenas e serem tolerantes a coisas consideradas grandes para os técnicos. É um grupo heterogêneo difícil de estudar. São resistentes a mudanças, e é pra eles que o software é produzido. Isto mostra como é difícil fazer um software ter sucesso.

Reforçar a relação entre estes três agentes nunca é demais e é sempre crucial. O XP propõe uma interação intensa com o cliente. Ele deve estar sempre presente em todos os passos, possivelmente o desenvolvedor deve estar dentro do prédio do cliente.

Os releases:

([McConnell 1996], p. 72, estima que "a correção de um bug não detectado no início mas detectado na entrega ou manutenção custa 50 a 200 vezes mais a correção na especificação")

O modelo proposto pelo XP é de releases atômicos. Você ouve seu cliente e desenvolve, testa e ouve de novo ele, desenvolve, testa e assim com iterações tão curtas que se torne impossível que o resultado não seja o esperado. O inventor do XP Kent Beck recomenda um ciclo de 1 semana. Ou seja, na primeira semana você já deve ter um software, pelo menos um screenshot dele. Mesmo que não faça nada!