Metodologia Ágil Extreme Programming - Parte 1

Um pouco do Conceito

Neste artigo estarei abordando a Metodologia Ágil “Extreme Programming”, traduzindo para o português como Programação Extrema.

Esta Metodologia de desenvolvimento de softwares tem como base as empresas que sofrem constantes mudanças, e conseqüentemente tendo como estratégia o acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de softwares.

A “Extreme Programming”, conhecido também pela sigla XP, concentra os esforços da equipe de desenvolvimento em atividades que geram resultados rapidamente na forma de software intensamente testado e alinhado às necessidades de seus usuários.

Outra característica seria a organização e a simplificação do trabalho combinando técnicas comprovadamente eficazes e por fim eliminando atividades redundantes. Tem como finalidade reduzir o risco dos projetos desenvolvendo softwares de forma iterativa e de boa qualidade. Entende-se como iteratividade como o processo chamado na programação de repetição de uma ou mais ações.

Descreverei os quatro valores deste tipo de Metodologia Ágil, tais como:


-  FeedBack,

-  Comunicação,
-  Simplicidade,
-  Coragem.

Especificamente neste artigo explicarei também algumas práticas, tais como:

- Cliente Presente,
- Jogo de Planejamento,
- Stand Up Meeting,
- Programação em Par,
- Código Coletivo,
- Código Padronizado,
- Design Simples,
- Teste Orientado a Testes,
- Refactoring,
- Integração Contínua,
- Releases Curtos.

Os Valores

1-) FeedBack

É importante ressaltar que existem dois tipos de FeedBack, o do cliente em relação ao desenvolvedor e o do desenvolvedor em relação ao cliente.

Cliente x Desenvolvedor

Neste primeiro o Cliente aprende com o sistema que utiliza e com isto consegue reavaliar o produto recebido, podendo realimentar a equipe de desenvolvimento com as suas reais necessidades, conduzindo o desenvolvimento de seu produto, estabelecendo prioridades informando aquilo que é realmente importante.

Desenvolvedor x Cliente

O Feedback dado pelo desenvolvedor ao cliente, o mesmo aponta riscos, estimativas e alternativas de design. Em poucas palavras, este retorno é o aprendizado do desenvolvedor sobre o que o cliente deseja.

É interessante salientar a compreensão das necessidades dos usuários, sendo uma das atividades mais difíceis e importantes de serem realizadas pelos desenvolvedores de softwares. Uma das características do “Extreme Programming” seria a organização de ciclos curtos de feedback, possibilitando aos usuários solicitar funcionalidades e aprender sobre elas através de software funcionando em prazos curtos.

Irei salientar que esta técnica envolve a priorização de poucas funcionalidades a serem implementadas de cada vez, buscando a simplificação das mesmas na medida do possível.

Conseqüentemente a equipe segue adiante apenas se o resultado estiver correto, existindo alguma falha, as mesmas serão corrigidas rapidamente antes de efetuar o desenvolvimento de novas funcionalidades, tendo sempre um software livres de Bugs e códigos desnecessários.

2-) Comunicação

Para que o Feedback funcione com sucesso é necessário ter uma boa comunicação entre as partes envolvidas, que ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados.

Os projetos de Software envolvem a presença de pelo menos duas pessoas, um usuário e um desenvolvedor, portanto a comunicação entre elas é essencial para uma boa conduta.

Uma das características do “Extreme Programming” seria o envolvimento ativo de seus usuários, tornando-os parte integrante da equipe de desenvolvimento. Isto significa que o usuário estará sempre presente no local onde os desenvolvedores trabalham, possibilitando o acesso rápido às informações ali trocadas. Poderá ocorrer o inverso também, a equipe de desenvolvimento poderá trabalhar dentro da empresa onde o software está sendo desenvolvido.

Outra característica seria a quantidade de pessoas envolvidas no projeto, quanto maior o número de pessoas torna-se mais difícil para as pessoas saber o que os outros estão fazendo e como não sobrepor, duplicar ou interferir no trabalho um do outro, por este motivo o XP procura contar com um número reduzido de pessoas.

Abaixo segue a Imagem que é muito comum em exemplo de XP. Ela demonstra o que acontece quando a comunicação entre as partes é falha.

Figura 01: Resultado de uma comunicação falha. 

3-) Simplicidade

Um dado interessante para abordarmos seria a quantidade de tempo desperdiçado no desenvolvimento de software, os projetos freqüentemente investem grande parte dos recursos em esforços desnecessários.

Veja o Gráfico abaixo para podermos entender melhor.

Figura 02: Gráfico de utilização do Software.

Podemos observar que apenas 20% do que foi desenvolvido realmente é utilizado, ou seja, 80% do nosso tempo gastos com análise, programação foi jogado no lixo. Um erro comum cometido pelos desenvolvedores seria a implementação de funcionalidades adicionais na tentativa de antecipar o que o usuário certamente irá solicitar no futuro.

Os desenvolvedores que utilizam a metodologia XP procuram implementar as funcionalidades priorizadas para cada iteração com a maior qualidade possível, tendo o foco somente naquilo que é essencial. Procuram fazer apenas o “feijão com arroz” para que o software funcione corretamente.

Os princípios da “Extreme Programming” se baseiam de que as funcionalidades extras adicionam complexidade e não a flexibilidade, sendo assim procuram adiar a inclusão de qualquer funcionalidade até que ela realmente seja priorizada pelo cliente. 

4-) Coragem

No desenvolvimento de softwares existem alguns medos que assombram tanto os desenvolvedores quanto aos clientes, veja abaixo alguns dos principais:

      Os desenvolvedores

Ser solicitados a fazer mais do que sabem fazer;

Fazer coisas que não tem sentido;

Não receber definições claras sobre o que precisa ser feito;

Sacrificar qualidade por causa do prazo de entrega;

Ficar tecnicamente defasados.

Os Clientes

Não obter o que pediram;

Pedir coisas que não irão utilizar;

Pagar muito pelo software;

Focar apenas nas suas primeiras decisões e não serem capazes de realizar mudanças.

Na realidade estes temores existem e a equipe de XP os reconhece buscando formas para lidar com os mesmos.

Uma das técnicas utilizadas em XP seria adotar iterações curtas, isto protege sua equipe dos clientes que temem não obter o que pediu. Normalmente estas iterações curtas duram de uma a três semanas.

O desenvolvimento iterativo também ajuda a lidar com o medo que o cliente tem de pagar demais por muito pouco. Ao receber funcionalidades com freqüência, em prazos curtos, o cliente passa a ter diversas oportunidades de avaliar o trabalho da equipe com base em feedback concreto, ou seja, irá ver o software funcionando.

Resumindo, o desenvolvimento iterativo da equipe procura resolver praticamente todos estes temores encontrados tanto na parte do cliente quanto a do desenvolvedor.

As Práticas

1-) Cliente Presente

O XP sugere que o cliente o cliente esteja no dia-a-dia do projeto, acompanhando todos os passos do desenvolvedor, onde sua ausência representa sérios riscos no decorrer do projeto.

A presença do cliente ao longo do desenvolvimento viabiliza o ciclo contínuo de feedback entre ambas as partes, permitindo que sejam realizadas pequenas mudanças de uma forma rápida ao longo do projeto. O desenvolvedor sabe exatamente o que o cliente deseja de uma forma muito rápida.

Outro benefício desta proximidade seria uma melhoria na relação de confiança entre as partes envolvidas, tendo como resultado positivo no decorrer do projeto.

2-) Jogo do Planejamento

Planejar o que implementar é uma das atividades mais importantes a serem conduzidas durante o desenvolvimento de um sistema.

Este planejamento é realizado várias vezes durante o projeto, seria o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja os releases e as iterações.

Para entendermos melhor, o que seria uma estória?

Resposta: Estórias são as funcionalidades que o cliente espera receber na aplicação que será construída, que em outras abordagens seriam chamadas de requisitos, casos de usos ou pontos de função, sendo registradas em chamados “cartão de estória” pelo cliente em uma linguagem simples e comum, o suficiente para a compreensão de todos da equipe de desenvolvimento.

E uma iteração?

Resposta: Para um fácil entendimento, uma iteração é o tempo disposto a fim de gerar a implementação de um determinado número de estórias. Normalmente as iterações são curtas, durando em média uma semana.

E um release?

Resposta: Representa um marco no tempo no qual um conjunto coeso de funcionalidades é finalizado e lançado para consumo de seus usuários. Neste espaço de tempo do release a equipe trabalha com iterações curtas e fixas.

As imagens 03 e 04 abaixo nos auxiliam no entendimento destes conceitos.

Figura 03: Release e Iteração no XP.

Figura 04: Release, Iterações e Estórias no XP.

3-) Stand Up Meeting

É uma reunião rápida pela manhã, com aproximadamente 20 minutos, onde seus integrantes permaneçam preferencialmente em pé. Segundo estudos, uma reunião em pé é mais rápida evitando bate-papos paralelos fazendo os integrantes irem diretamente ao assunto. Esta reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e também permitindo que os participantes priorizem atividades do dia que se inicia.

Este tipo de reunião força a aproximação dos desenvolvedores de forma diária e contínua, diminuindo os tempos de feedback na medida que toda manhã cada desenvolvedor reporta suas atividades executadas no dia anterior.

4-) Programação em Par

É dada programação em par pois o XP exige que todo o desenvolvimento do projeto seja efetuado em dupla. Esta é uma técnica onde dois programadores trabalham no mesmo problema, ao mesmo tempo e no mesmo computador. Um deles seria o responsável pela digitação e o outro acompanha o trabalho.

Esta técnica implementa uma das diversas redes de proteção nos projetos XP, reduzindo os riscos de eventuais falhas.

Outra característica importante da programação em par seria o processo de inspeção, pois isto se torna uma parte natural do dia-a-dia da equipe de desenvolvimento, diminuindo os problemas que possam ocorrer no futuro.

Estas revisões em pares representam uma das formas mais eficazes para encontrar os denominados Bugs, pois às vezes um erro para um programador pode passar despercebido, tendo outro do seu lado estes tipos de problemas tem suas chances bastante diminuídas.

Outro fator importante neste tipo de programação é o diálogo constante entre os participantes, isto é, discutem novas idéias e abordagens.

É com esta prática que o XP uniformiza o nível dos desenvolvedores da equipe, através de troca de experiências. Após algum tempo trabalhando em dupla todos os desenvolvedores conhecerão todas as rotinas do sistema e estarão prontos para qualquer modificação ou para auxiliar algum programador iniciante.

5-) Código Coletivo

Todas as classes e métodos pertencem à equipe e qualquer membro da equipe pode melhorar o que for necessário, ou seja, o desenvolvedor tem acesso a todas as partes do sistema.

Esta prática tem como conseqüência um código revisado e testado por diversas pessoas e caso encontre algum problema este código poderá ser alterado por qualquer pessoa da equipe.

6-) Código Padronizado

O XP recomenda a adoção de um padrão de código desde o início do projeto. A adoção de um padrão ajuda a simplificar a comunicação entre os membros. Esta também é uma prática muito importante, pois em uma tarefa futura qualquer membro da equipe poderá modificar o código.

7-) Design Simples

Alguns itens são indispensáveis para os usuários de um software, tais como: Que o mesmo faça a coisa certa, seja fácil de utilizar, funcione corretamente e por fim possa evoluir com o tempo.

As práticas do XP se complementam formando um conjunto para atingir estes objetivos. É adotado Releases seguidos de Iterações Curtas os quais implementam um número pequeno de estórias, dando para o cliente um feedback rápido permitindo que o cliente saiba se o sistema está fazendo a coisa certa e se está funcionando.

As equipes procuram assegurar que o design seja mantido simples e eventuais flexibilidades sejam adiadas até que se tornem efetivamente necessárias em função das estórias solicitadas pelos usuários. Uma característica importante é que os desenvolvedores não tentam prever mudanças no futuro e nem procuram antecipar as flexibilidades que serão necessárias.

O Design deve ser simples, porém atendendo todas as necessidades do cliente acima descritas.

8-) Desenvolvimento Orientado a Testes

Todo código implementado deve coexistir com um teste automatizado, garantindo o pleno funcionamento da nova funcionalidade. É com base nestes testes que qualquer desenvolvedor terá coragem para alterar uma parte do código que não tenha sido implementada por ele.

Trata-se de uma técnica preventiva utilizada durante todo o projeto e a manutenção, ou seja, o programador evita os problemas que no futuro poderão acarretar em problemas muito maiores. Desta forma os testes automatizados procuram comprovar que as solicitações dos usuários estão sendo atendidas de forma correta.

O XP se concentra em dois tipos de testes:

Teste de Unidade

Tem por objetivo verificar se os resultados gerados por cada classe estão corretos. Estes tipos de testes são escritos antes de cada método produzido, seria uma forma para verificar se o sistema irá funcionar corretamente.

Teste de Aceitação ou Funcionais

Tem por objetivo verificar se a interação entre as classes que implementam uma estória atendem a necessidade de forma correta, sendo descritos pelo cliente ou orientados por ele e implementados pelo desenvolvedor.

Neste caso, o cliente escreve teste para uma estória de cada vez para realizar este tipo de teste, tendo o desenvolvedor o trabalho de traduzir as idéias dos testes.

Portanto, escrever um teste antes de cada estória representa uma maneira de aprimorar a análise sobre as características da mesma.

9-) Refactoring

Traduzindo para o português Refactoring significa Refatoração, esta técnica implica que todo desenvolvedor ao encontrar um código mal escrito, ilegível, sem padronização, lento tem por obrigação alterar este código deixando-o o mais simples e legível possível. É importante salientar que estas modificações não poderão alterar o comportamento do código em questão.

A necessidade de Refatoração aparece à medida que a arquitetura evolui e novas funcionalidades são solicitadas pelos clientes.

Ao longo do processo de Refatoração o sistema irá ter as seguintes características, tais como:

·         Simplicidade: Seria um design simples,

·         Clareza: Código de fácil entendimento,

·         Adequação ao Uso: O propósito deverá ser alcançado,

·         Ausência de Repetição: O código não pode ser repetido,

·         Ausência de Funcionalidades Extras: Funcionalidades que não são úteis ao sistema.

No processo de Refatoração os desenvolvedores procuram utilizar nomes que façam sentido, evitando abreviações e adotando um código padronizado. Este tipo de técnica anda de mãos dadas com a de Código Coletivo e Código Padronizado. Estas técnicas no XP se tornam muito importantes e relevantes quando são utilizadas corretamente.

10-) Integração Contínua

O XP defende uma integração contínua, deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém desenvolvido. Com esta prática o feedback sobre a alteração efetuada será retornado em um menor espaço de tempo. Diferentemente do desenvolvimento tradicional, onde temos a divisão por módulos.

Estas estratégias reduz a complexidade e as preocupações do desenvolvedor.

11-) Releases Curtos

Em XP, temos os denominados Releases curtos, que seriam um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente.

O XP recomenda que pequenos investimentos sejam efetuados de forma gradual, dando um retorno para o cliente em um espaço de tempo muito curto. Diferentemente do modelo tradicional que é dividido em fases, de um modo que o cliente tenha benefícios quase no término do sistema.

Uma das finalidades desta prática seria maximizar o retorno dos projetos assegurando que o maior valor do negócio seja entregue ao final de cada release.

Esta técnica consiste em colocar o sistema para funcionar em prazos muito curtos, geralmente alguns meses.

Conclusão

Vimos neste artigo um pouco da Metodologia “Extreme Programming” junto com seus valores e algumas práticas. Podemos perceber que este tipo de metodologia pode ser bem útil no âmbito de desenvolvimento de sistemas. Muitas empresas vêm aprimorando as concepções desta Metodologia para atender todas as necessidades, principalmente a das pessoas. Estarei abordando em artigos futuros um pouco mais desta Metodologia que tem como foco melhorar a condução de sua equipe de desenvolvimento e atender e entender todas as necessidades dos clientes.

Fico por aqui, um forte abraço e até o mês que vem.