O método Programação eXtrema (XP, do inglês eXtreming Programming) é uma proposta de desenvolvimento ágil e iterativa. O método XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes da funcionalidade do software. As partes devem ser incrementadas e requerem a melhoria constante do código (re-trabalho).
A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Isto no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um membro ativo da equipe de desenvolvimento. Esta é uma das características importantes para o método funcionar bem. No entanto, nem sempre o cliente está disponível para a participação ativa.
Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.
O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe. Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design.
Estórias de Usuários
A elaboração de estórias de usuário é uma das atividades fundamentais no XP. As estórias de usuário descrevem cenários com situações de utilização que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer. Elas deve devem ser escritas pelos próprios usuários. As estórias de usuário são semelhantes aos casos de uso da UML, mas não são a mesma coisa. A diferença é que elas não se limitam a descrever o processo de interação do usuário com o sistema.
No XP, as estórias de usuário ocupam o lugar dos longos documentos de requisitos nos métodos tradicionais. Cada estória deve ser um texto escrito com aproximadamente 3 sentenças.
As estórias de usuário são a base para a criação de estimativas de tempo que serão utilizadas nas reuniões de planejamento de entregas (releases). O plano de entregas direciona todo o planejamento do desenvolvimento e do plano de iterações para cada iteração individual. Cada estória deve levar de 2 a 3 semanas para ser implementada em uma iteração individual. Se levar mais do que isso, a estória precisa ser dividida em duas. Um número de 80 estórias aproximadamente é suficiente para definir um plano de entregas.
As estórias de usuário são também a base para a elaboração dos testes de aceitação. Um ou mais testes de aceitação automatizados deve ser criados para verificar se o programa implementa a estória corretamente.
O envolvimento do usuário, portanto, como autor das estórias, é fundamental para a elaboração do plano de entregas e dos testes de aceitação em cada iteração de desenvolvimento.
Práticas de programação
O processo de programação tem como características a programação em pares e a propriedade coletiva do código.
Na programação em pares, dois programadores ocupam um único computador. Embora, a princípio, isto possa ser visto como um desperdício de esforços, várias vantagens podem ser obtidas. Esta estratégia aumenta a qualidade do código e não altera o tempo de entrega, uma vez que haverá um ganho posterior nas etapas de retirada de erros (defeitos). Os dois programadores atuam de forma colaborativa. Enquanto o que está com o teclado e mouse está pensando diretamente na codificação (sintaxe, variáveis, fluxos de controle, etc.), o outro pode pensar estrategicamente em como o código irá interagir como outras partes do programa. Além disso, um atua com uma visão mais crítica corrigindo erros dos companheiros e pode pensar nas futuras mudanças e etapas posteriores. Isto permite que a tradicionalmente prática do codifica-e-conserta, criticada nas origens do desenvolvimento de software, possa ser realiza sem perda da qualidade do software.
A propriedade coletiva do código é outra característica fundamental do método XP, com a rotatividade do código entre os programadores e reuniões freqüentes para estabilizar o código. A propriedade coletiva encoraja o time todo a contribuir com novas idéias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do arquiteto chefe. Todos são responsáveis pelo código inteiro. Não existe alguém para aprovar as mudanças. Reuniões freqüentes devem ser definidas como parte do processo iterativo de programação. Estas reuniões devem ser curtas e são realizadas com todos de pé.
A prática do codifica-e-conserta também requer um processo constante de teste de unidade e integração. Para isto funcionar bem, os desenvolvedores devem trabalhar com uma ferramenta de testes automático e um repositório coletivo do código fonte. Os desenvolvedores devem criar testes de unidades e liberar o código apenas quando estiver 100% testado. Uma vez no repositório, qualquer um pode fazer alterações e adicionar novas funcionalidades. Uma ferramenta de controle de versões é fundamental.
O re-trabalho ou re-fabricação é uma atividade fundamental e necessária para o XP funcionar. Mesmo que o código esteja 100% testado, para viabilizar reuso, ele precisa ser revisto para remover redundâncias, retirar funcionalidades desnecessárias e modificar arquitetura obsoletas. O re-trabalho do código ao longo de todo o ciclo de vida reduz o tempo total de entrega do código e aumenta a qualidade do software produzido.
Regras e Práticas
Planejando
Projetando (designing)
Codificando
Testando
A programação extrema tem sido bem sucedida em projetos pequenos com times pequenos. Relatos mostram que para projetos grandes o método XP não é recomendado.
Para saber mais, consulte www.extremeprogramming.org
A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Isto no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um membro ativo da equipe de desenvolvimento. Esta é uma das características importantes para o método funcionar bem. No entanto, nem sempre o cliente está disponível para a participação ativa.
Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.
O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe. Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design.
Estórias de Usuários
A elaboração de estórias de usuário é uma das atividades fundamentais no XP. As estórias de usuário descrevem cenários com situações de utilização que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer. Elas deve devem ser escritas pelos próprios usuários. As estórias de usuário são semelhantes aos casos de uso da UML, mas não são a mesma coisa. A diferença é que elas não se limitam a descrever o processo de interação do usuário com o sistema.
No XP, as estórias de usuário ocupam o lugar dos longos documentos de requisitos nos métodos tradicionais. Cada estória deve ser um texto escrito com aproximadamente 3 sentenças.
As estórias de usuário são a base para a criação de estimativas de tempo que serão utilizadas nas reuniões de planejamento de entregas (releases). O plano de entregas direciona todo o planejamento do desenvolvimento e do plano de iterações para cada iteração individual. Cada estória deve levar de 2 a 3 semanas para ser implementada em uma iteração individual. Se levar mais do que isso, a estória precisa ser dividida em duas. Um número de 80 estórias aproximadamente é suficiente para definir um plano de entregas.
As estórias de usuário são também a base para a elaboração dos testes de aceitação. Um ou mais testes de aceitação automatizados deve ser criados para verificar se o programa implementa a estória corretamente.
O envolvimento do usuário, portanto, como autor das estórias, é fundamental para a elaboração do plano de entregas e dos testes de aceitação em cada iteração de desenvolvimento.
Práticas de programação
O processo de programação tem como características a programação em pares e a propriedade coletiva do código.
Na programação em pares, dois programadores ocupam um único computador. Embora, a princípio, isto possa ser visto como um desperdício de esforços, várias vantagens podem ser obtidas. Esta estratégia aumenta a qualidade do código e não altera o tempo de entrega, uma vez que haverá um ganho posterior nas etapas de retirada de erros (defeitos). Os dois programadores atuam de forma colaborativa. Enquanto o que está com o teclado e mouse está pensando diretamente na codificação (sintaxe, variáveis, fluxos de controle, etc.), o outro pode pensar estrategicamente em como o código irá interagir como outras partes do programa. Além disso, um atua com uma visão mais crítica corrigindo erros dos companheiros e pode pensar nas futuras mudanças e etapas posteriores. Isto permite que a tradicionalmente prática do codifica-e-conserta, criticada nas origens do desenvolvimento de software, possa ser realiza sem perda da qualidade do software.
A propriedade coletiva do código é outra característica fundamental do método XP, com a rotatividade do código entre os programadores e reuniões freqüentes para estabilizar o código. A propriedade coletiva encoraja o time todo a contribuir com novas idéias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do arquiteto chefe. Todos são responsáveis pelo código inteiro. Não existe alguém para aprovar as mudanças. Reuniões freqüentes devem ser definidas como parte do processo iterativo de programação. Estas reuniões devem ser curtas e são realizadas com todos de pé.
A prática do codifica-e-conserta também requer um processo constante de teste de unidade e integração. Para isto funcionar bem, os desenvolvedores devem trabalhar com uma ferramenta de testes automático e um repositório coletivo do código fonte. Os desenvolvedores devem criar testes de unidades e liberar o código apenas quando estiver 100% testado. Uma vez no repositório, qualquer um pode fazer alterações e adicionar novas funcionalidades. Uma ferramenta de controle de versões é fundamental.
O re-trabalho ou re-fabricação é uma atividade fundamental e necessária para o XP funcionar. Mesmo que o código esteja 100% testado, para viabilizar reuso, ele precisa ser revisto para remover redundâncias, retirar funcionalidades desnecessárias e modificar arquitetura obsoletas. O re-trabalho do código ao longo de todo o ciclo de vida reduz o tempo total de entrega do código e aumenta a qualidade do software produzido.
Regras e Práticas
Planejando
- Estórias do usuário
- Planejando liberações (releases) e pequenas liberações
- Dividir projetos em iterações (ciclos)
- Medindo velocidade do projeto
- Dinâmica de pessoal
- Reuniões diárias em pé
Projetando (designing)
- Simplicidade (não adicione funcionalidades antes do tempo)
- Metáfora
- Cartões CRC (Classes, Responsabilidades e Colaboração)
- Re-fabricar (refactor)
Codificando
- O cliente deve estar sempre disponível.
- Programação em pares.
- Codificar de acordo com padrões acordados.
- Codificar testes de unidade primeiro.
- Integrar com freqüência.
- O código é propriedade coletiva.
- Não atrase.
Testando
- Todo código deve ter os testes de unidade.
- Cada unidade deve ser testada antes de liberada.
- Quando um erro é encontrado, testes devem ser realizados.
- Testes de aceitação devem ser freqüentes.
A programação extrema tem sido bem sucedida em projetos pequenos com times pequenos. Relatos mostram que para projetos grandes o método XP não é recomendado.
Para saber mais, consulte www.extremeprogramming.org
Comentários
Atualmente estou cursando Especialização em Analise de Sistemas e preciso desenvolver uma monografia em um determinado assunto. Tinha escolhido o tema SOA mas estou tendo dificuldades em encontrar material em portugues. Meu amigo deu a sugestão para fazer sobre XP, mas estou com dúvida no que abordar.
Você teria alguma sugestão do que poderia aprofundar em XP para a monografia?
Para definir um tema de monografia, você precisa identificar uma necessidade: o que precisa ser lido sobre XP que ainda não foi publicado.
A melhor forma é iniciar uma pesquisa bibliográfica em fontes confiáveis: bibliotecas digitais ACM, IEEE, ScienceDirect, etc.
O seu orientador no curso deve ajuda-lo nestas tarefas. Muitas vezes, a sua experiência deve indicar para você os possíveis temas.
Uma sugestão específica é fazer um levantamento de como a qualidade de produção em uma organização de desenvolvimento de software pode ser alcançada com XP. Para isto, é preciso definir critérios para verificar a qualidade do processo e uma forma de medi-los, antes e depois da adoção do XP.
Boa sorte!