eXtreme Programming (XP) e Crystal: Modelos de Processos Ágeis

O modelo mais amplamente utilizado de todos os modelos de processos ágeis é o Extreme Programming (XP). Porém, ultimamente têm surgido cada vez mais modelos de processos como Desenvolvimento de software adaptativo (ASD), Scrum, DSDM, Crystal, entre outros. Apesar de cada modelo ter suas características próprias que diferenciam uns dos outros todos os modelos estão em conformidade com o Manifesto Ágil.

Extreme Programming (XP)

Programação Extrema ou Extremme Programming (XP) é considerada a abordagem mais utilizada para desenvolvimento de software ágil. Este método foi concebido por Kent Beck durante o final dos anos 1980.

A Extremme Programming possui um conjunto de cinco valores que são considerados como sendo as bases para a XP, são eles: comunicação, simplicidade, feedback, coragem e respeito. Esses valores são utilizados como um direcionador das atividades, ações e tarefas específicas da XP. O primeiro valor é a comunicação que tem como principal objetivo estabelecer uma colaboração estreita, embora informal (verbal), entre clientes e desenvolvedores. Dessa forma, temos feedbacks contínuos dos nossos clientes e evitamos a velha e volumosa documentação como meio de comunicação. O segundo valor é a simplicidade que tem como objetivo restringir os desenvolvedores a projetar apenas aquilo que for uma necessidade imediata, ao invés de considerarem necessidades futuras. Dessa forma, temos um projeto simples que é facilmente implementado. Se o projeto tiver que sofrer alguma alteração ele poderá ser refatorado mais tarde. A refatoração é uma técnica que permite que os desenvolvedores aperfeiçoem a estrutura interna de um projeto sem alterar a sua funcionalidade ou comportamento externo. O terceiro valor é o feedback que é obtido por três fonte diferentes: através do software implementado, do cliente e de outros membros da equipe. Na implementação do software obtermos feedback através dos testes de unidade que a equipe realiza. O cliente por sua vez retorna feedback conforme a equipe vai liberando incrementos do software para que ele possa testar. Por fim, conforme novas necessidades surgem ao longo do projeto a equipe dá ao cliente um rápido feedback referente ao impacto nos custo e no cronograma. O quarto valor é a coragem que tem como objetivo adotar certas práticas da XP que podem trazer muitas objeções pelos superiores do projeto. Por fim, o quinto valor é o respeito que sempre deve existir entre os membros da equipe.

Além dos valores já citados anteriormente, a XP também emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento e envolve um conjunto de regras e práticas constantes no contexto de quatro atividades metodológicas, são eles: planejamento, projeto, codificação e testes.

Na atividade de Planejamento temos inicialmente uma atividade de levantamento de requisitos que tem como objetivo capacitar os membros técnicos da equipe XP a entender o ambiente de negócios do software e possibilita que todos tenham uma percepção ampla sobre os resultados solicitados, dos principais fatores e das funcionalidades a serem agregadas ao software proposto. Nesta atividade teremos um conjunto de histórias (chamadas de histórias de usuário) que tem como objetivo descrever o resultado, as características e a funcionalidade requisitada para o software a ser construído. Cada uma das histórias é descrita pelo cliente e atribuída uma prioridade à história, baseando-se no quanto essa história acrescenta de valor ao negócio do cliente. Por outro lado, os membros da equipe de desenvolvimento avaliam essa história e atribuem um custo a essa história, que é medido em semanas ou horas de desenvolvimento. Se a história durar mais do que três semanas é solicitado ao cliente dividir mais essa tarefa para que ela ocorra no máximo no prazo de três semanas. Novas histórias podem ser escritas a qualquer momento.

Podemos ter diversas histórias para um software, dessa forma, os clientes e desenvolvedores decidem juntos como agrupar essas histórias para a versão seguinte (próximo incremento) a ser desenvolvido pela equipe. Após a entrega de cada incremento a equipe calcula como está sendo a sua velocidade. Essa velocidade define o número de histórias de cliente implementadas durante uma versão. Essa velocidade ajuda a estimar as datas de entrega e cronograma para as próximas versões e determina se a equipe exagerou no compromisso assumido. Se ocorrer um exagero, o conteúdo das versões é modificado ou as datas finais de entrega são alteradas. Conforme prossegue o desenvolvimento o cliente está livre para acrescentar histórias, mudar o valor das histórias existentes, dividir ou até eliminar algumas histórias. A equipe XP sempre reconsidera essas histórias nas próximas versões, modificando seus planos.

Na atividade de projeto temos o princípio KIS (Keep It Single) que deve ser seguido rigorosamente afim de sempre mantermos o projeto simples. Nunca devemos acrescentar funcionalidades extras. A XP também encoraja todos da equipe a usam os cartões CRC (classe-responsabilidade-desenvolvedor) que serve como um mecanismo bastante eficaz para pensar sobre o software em um contexto OO (orientado a objetos). Esses cartões permitem identificarmos e organizarmos as classes OO para o incremente sendo desenvolvido. Os cartões CRC são o único artefato de projeto produzido como parte do projeto XP.

Outra recomendação da XP é a criação de protótipos quando encontramos um problema difícil. O protótipo é implementado e avaliado reduzindo o risco quando a verdadeira implementação iniciar além de podermos validar as estimativas originais para a história que contém o problema.

Portanto, o projeto no XP não usa praticamente nenhuma notação e produz pouco ou nenhum artefato. Dessa forma, o projeto é visto como sendo algo transitório que pode ser modificado a qualquer momento. Com isso a refatoração é bastante utilizada de forma a adicionarmos pequenas mudanças capazes de melhorar radicalmente o projeto.

Na atividade de Codificação temos a implementação do software. Essa atividade ocorre depois das histórias de usuários terem sido desenvolvidas e do trabalho preliminar de elaboração do projeto ter sido feito. Inicialmente a equipe não vai diretamente para a codificação do software propriamente dito. A equipe realizará inicialmente uma série de teste de unidades que exercitarão cada uma das histórias que serão incluídas na versão corrente. Após os testes de unidade terem sido criados, o desenvolvedor poderá focar-se melhor no que deve ser codificado e o que deve ser implementado para passar nos testes. Após implementarmos a funcionalidade podemos testar imediatamente o software, e dessa forma, os desenvolvedores podem ter um feedback instantâneo. Essa implementação dos testes antes de fazer a implementação do código também é chamada de TDD (Test Driven Development) ou Desenvolvimento guiado por testes.

Outro conceito chave na atividade de codificação é o Peer Programming ou programação em pares. A XP recomenda que duas pessoas trabalhem em duplas num mesmo computador para criar código para uma história. Isso fornece um mecanismo incrível para resolução de problemas em tempo real e garante também qualidade em tempo real, visto que o código é revisto à medida que ele é criado. Essa programação em pares é muitas vezes desencorajada pelos gerentes e chefes de equipe. Nas minhas equipes eu tenho adotado continuamente esse tipo de programação, é realmente incrível o relato dos programadores quanto ao ganho que esse tipo de programação oferece. Os desenvolvedores ficam focados e pensando o tempo todo em como resolver o problema em questão. O foco é total nesse tipo de atividade. Quando desenvolvo em pares me sinto muito mais cansado ao fim do dia do que quando eu trabalho sozinho. Esses conceitos de programação em pares devem ser utilizados principalmente para os novos integrantes da equipe, coloca-los ao lado dos mais experientes num projeto irá alavancar o iniciante e manter o experiente mais focado no problema além de ter diferentes visões trazidas pelo iniciante. Uma dica importante é tentar alternar quem está codificando, ora um ora outro codifica.

Por fim, na atividade de teste temos a criação dos testes de unidade que é iniciada antes da codificação. Os testes de unidade devem ser automatizados permitindo que possamos testar novamente a qualquer momento de forma fácil e repetida. Com isso também temos o encorajamento dos testes de regressão toda vez que o código for modificado. Os testes também permitem que possamos encontrar problemas logo no início. Os testes de unidade, integração e validação do sistema podem ocorrer diariamente. Outro teste que temos é o de aceitação que é realizado pelo cliente. Os testes de aceitação são obtidos de histórias de usuários.

Crystal

O Crystal foi criado por Alistair Cockburn e Jim Highsmith. O Crystal foi criado com o princípio de ser uma abordagem de desenvolvimento de software que priorizasse a adaptabilidade. Cockburn ainda afirma que o Crystal tem como característica a comunicação cooperativa e a entrega de software útil em funcionamento. O Crystal é uma família de métodos ágeis. Para conseguir a adaptabilidade efetivamente Cockburn e Hoghsmith definiram um conjunto de elementos essenciais comuns a todas, mas com papéis, padrões de processos, produtos de trabalho e prática única para cada uma das metodologias. Portanto, a família Crystal caracteriza-se por ser um conjunto de exemplos de processos ágeis que provaram ser efetivos para os mais diferentes tipos de projetos. Dessa forma, fica a critério de cada equipe selecionar o membro da família Crystal mais apropriado para o projeto e ambiente na qual a equipe está inserida.