Todos em um projeto XP fazem parte de uma equipe. A equipe deve incluir um representante do cliente.

      O cliente deve ter o poder de responder perguntas e tomar decisões relativas à prioridade de recursos, riscos e assim por diante. Tomarão parte no planejamento escrevendo e priorizando histórias e resolvendo sobre o conteúdo liberado. Quando trabalham junto com a equipe de desenvolvimento, eles fornecem feedback constante, bem como respondem todas as perguntas da equipe sobre o que realmente queriam dizer as escrever histórias. O cliente também é responsável por escrever os testes de aceitação que verificam se cada história é implementada corretamente. Geralmente, os clientes não são desenvolvedores de software, e, assim, eles precisam da ajuda da equipe para automatizar os testes de aceitação.

      Além do cliente, deve haver um representante (ou um de seus assessores) é usuário final que conhece o domínio do problema e suas necessidades.

      Outros papéis assumidos pelos integrantes da equipe:

• Programadores
• Testadores (que ajudam o cliente com os testes de aceitação)
• Analistas (que ajudam o cliente a definir os requisitos)
• Gerente (que garante os recursos necessários)
• Coach (que orienta a equipe, controla a aplicação do XP)
• Tracker (coleta as métricas)

Jogo de Planejamento (Planning Game)

      Os jogadores do jogo de planejamento são os técnicos e o cliente. Os projetos de desenvolvimento de software de qualquer tamanho significativo precisam ser planejados. O planejamento serve para fornecer uma compreensão mútua para todas as partes de quanto tempo, aproximadamente, levará o projeto. Serve também como um medidor do tamanho do projeto com relação à capacidade da organização. Deve definir as estimativas de prazo para cada tarefa e as prioridades (quais tarefas são mais importantes).

      Dois passos chave:

1.      Planejamento de um release:

• O cliente propõe funcionalidades desejadas (estórias), precisa definir o escopo (o que o sistema deve fazer), o conteúdo e a data das releases.
• Os programadores avaliam a dificuldade de implementá-las.

2.      Planejamento de uma iteração (de duas semanas):

• O cliente define as funcionalidades prioritárias para a iteração. São determinadas as partes mais importantes e o que é excluído ou retardado quando o escopo se torna grande demais.
• Os programadores quebram as funcionalidades priorizadas em tarefas e avaliam o seu custo (tempo de implementação).

      O planejamento é um ótimo feedback para que cliente possa dirigir o projeto. Com ele é possível ter uma idéia clara do avanço do projeto, reduzindo riscos e aumentando as chances de sucesso.

Testes de Aceitação (Customer Tests)

      No planejamento, o usuário-cliente elabora “estórias” que descrevem cada funcionalidade desejada. O programador as implementa.

      Cada estória deve ser entendida suficientemente bem para que programadores possam estimar sua dificuldade e deve ser testável.

      Os testes de aceitação são elaborados pelo cliente, algumas de suas características:

·        São testes automáticos

·        Quando rodarem com sucesso significa que a funcionalidade foi implementada

·        Devem ser rodados novamente em cada iteração futura

·        Oferecem feedback, pois pode se saber, a qualquer momento, quantos % do sistema já foi implementado e quanto falta implementar.

Pequenos Releases (Small Releases)

      “Releases antecipados, releases freqüentes.“ “Resultados freqüentes, tangíveis e funcionais.” Essas são as duas frases que resumem a idéia do uso dos releases pequenos. Com os releases pequenos, se coloca as novas funcionalidades na mão dos verdadeiros usuários o mais cedo possível. Fornecendo um feedback valioso sobre estar no caminho certo. Além de detectar os defeitos o mais cedo possível. Um release com um recurso implementado pela metade não tem muita utilidade. A regra para uma equipe de XP é que o release não pode ser liberado enquanto não estiver completamente acabado.

      A cada iteração é disponibilizado um software 100% funcional, onde cada release possui funcionalidades prioritárias, já que os valores de negócio implementados foram escolhidos pelo cliente. O release pode ser destinado ao usuário-cliente ou ao usuário final do sistema.

      O design simples e a integração contínua são práticas essenciais para viabilizar os pequenos releases.

Design Simples (Simple Design)

      O design está presente em todas as etapas do XP. O projeto começa simples e se mantém simples através de testes e refinamento do design (refatoramento).

      Buscar o design simples e claro é levado a extremo no XP. Não é permitido que se implemente nenhuma função adicional que não será usada na atual iteração.

      A implementação ideal é aquela que roda todos os testes, expressa todas as idéias que se deseja expressar, não contém código duplicado e que tem o mínimo de classes e métodos. O que não é necessário agora não deve ser implementado. Prever o futuro é “anti-XP” e impossível (requisitos mudam).

Programação em Pares (Pair Programming)

      No XP as pessoas desenvolvem em pares. Cada código de linha de produção é escrito por um par de desenvolvedores.

      O piloto tem o controle escreve ativamente os testes, codifica, integra ou faz o refatoramento. O co-piloto observa, tendo em mente os objetivos estratégicos, encontrando os erros de ortografia e sintaxe e oferecendo idéias e sugestões.

      Os papéis são alternados frequentemente e os pares são trocados periodicamente.

      Com a programação em pares é obtido os seguintes benefícios:

• Melhor qualidade de design, código e testes.
• Revisão constante de código
• Nivelamento da equipe
• Maior comunicação

      Apesar de se ter uma pessoa programando pelo preço de duas pessoas, as pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores trabalhando sozinho e 90% dos que aprendem programação em duplas a preferem.

Testes (Test Driven-Development)

      O desenvolvimento de software que não é guiado por testes não é XP. O feedback é um dos valores fundamentais do XP e sem os testes não há como obter feedback.

      Os testes “puxam” o desenvolvimento do software. Os programadores XP escrevem os testes primeiro, em seguida escrevem o código e rodam os testes para validar o código escrito.

      Cada unidade de código só tem valor se seu teste funcionar 100%. Todos os testes são executados automaticamente, o tempo todo. Os testes são a documentação executável do sistema.

      Algumas das vantagens de adotar a abordagem de testar primeiro:

• Maior segurança – código testado é mais confiável e pode ser alterado sem medo
• Testes fornecem uma definição ou documentação do comportamento desejado
• Certeza de ter a funcionalidade total e corretamente implementada quando um teste é aprovado

Refinamento do Design (Refactoring)

      Não existe uma etapa isolada de design em XP, o próprio código é o design.

      De acordo com Martin Fowler [Fowler, 1999]:

      “Refactoring é o processo de alterar um sistema de software de tal forma que ele não altere o comportamento externo do código e melhore sua estrutura interna. Essa é uma forma disciplinada de limpar o código que minimiza as chances de introdução de bugs”.

      O design é melhorado continuamente através do refinamento. Ao escrever os testes é possível fazer o refactoring para tornar algo mais fácil de ser testado. Ao codificar alguma funcionalidade, o refactoring pode ser feito para facilitar a inclusão ou remoção de código duplicado. Além de poder utilizar um código existente e reestruturá-lo para que seja compatível com um padrão de projeto.

      Antes de fazer uma mudança, deve ser feito um refactoring no código. De acordo com Ron Jeffries [Jeffries, 2001A]:

      “Existem dois momentos em que se considera o refactoring como parte da execução de uma tarefa: antes de a tarefa começar, para “criar espaço” para o código novo, e após a tarefa ser implementada, para tornar os códigos novo e antigo o mais claro e simples possível”.

Integração Contínua (Continuous Integration)

      Os Projetos XP mantém o sistema continuamente integrado. A integração de todo o sistema pode ocorrer várias vezes ao dia (pelo menos uma vez ao dia). Geralmente após a conclusão de cada tarefa. Todos os testes (unidade e integração) devem ser executados.

      Segundo Fowler a integração contínua “reduz o tempo passado no inferno da integração”. Quanto mais tempo durarem os bugs de integração, mais difícil serão de eliminar.

      Entre os benefícios alcançados com a integração estão:

• Exposição do estado atual do desenvolvimento (viabilizando releases pequenos e freqüentes).
• Estimular design simples, tarefas curtas e a agilidade.
• Oferecer feedback sobre todo o sistema.
• Permitir encontrar problemas de design rapidamente.

Propriedade Coletiva (Collective Ownership)

      Em um projeto XP qualquer dupla de programadores pode melhorar o sistema a qualquer momento. Não é preciso pedir autorização para realizar alterações em qualquer arquivo.

      Todo o código em XP pertence a um único dono: a equipe.

• O código recebe a atenção de todos os participantes resultando em maior comunicação.
• Maior qualidade (menos duplicação, maior coesão).
• Menos riscos e menos dependência de indivíduos

      Todos da equipe compartilham a responsabilidade pelas alterações. Os testes e a integração contínua são essenciais e dão segurança aos desenvolvedores.

Programação em pares reduz os riscos de danos.

Padrões de Codificação (Coding Standards)

      O código escrito em projetos XP segue um padrão de codificação definido pela equipe. Todos os membros da equipe devem concordar voluntariamente em seguir esses padrões.

      O padrão de codificação define um padrão para nomes de métodos, classes e variáveis. Todo o código parece que foi escrito por um único indivíduo, competente e organizado.

      O código com uma estrutura familiar facilita e estimula:

• Propriedade Coletiva – todos podem ter a propriedade do código porque todos escreveram o código com o mesmo estilo.
• Comunicação mais eficiente
• Simplicidade
• Programação em pares – ambos os parceiros trabalham no mesmo formato.
• Refinamento do Design – porque você entende o formato do código que está alterando e os outros entenderão o formato do seu trabalho.
• Trabalhar com velocidade – não é preciso reformatar o código durante o trabalho, nem estar constantemente alternando de um estilo para outro ou tentando entender a formatação e o estilo, bem como o próprio código.

Metáforas (Metaphor)

      Uma metáfora é uma forma poderosa de relacionar uma idéia difícil em uma área desconhecida. Equipes XP devem utilizar metáforas para manter uma visão compartilhada do funcionamento do sistema.

      Tendo uma metáfora compartilhada, todas as pessoas envolvidas compartilham de uma compreensão da visão do quadro geral do sistema e do problema que deve ser solucionado. A metáfora também serve como uma definição da arquitetura conceitual geral do sistema. Servem de base para estabelecimento de padrões de codificação, facilitando a escolha de nomes de métodos, classes, campos de dados, etc. Fornecem um contexto para discutir os problemas e suas soluções.

Ritmo Saudável (Sustainable Pace)

      Os Projetos XP estão na arena para ganhar com o objetivo de entregar softwares de melhor qualidade, obtendo a maior produtividade dos programados e a satisfação do cliente.

      Projetos com cronogramas apertados que sugam todas as energias dos programadores não são projetos XP.

      “Semanas de 80 horas” levam à baixa produtividade. E produtividade baixa leva à código ruim, relaxamento da disciplina (testes, refactoring, simplicidade), além de dificultar a comunicação, aumentar a irritação e o stress da equipe. O tempo ganho será perdido depois.

      Os projetos devem ter um ritmo sustentável por longos prazos. Eventuais horas extras são aceitáveis quando a produtividade é maximizada no longo prazo.