Metodologias de Desenvolvimento Ágil – Parte 3: Extreme Programmimg (XP)


Metodologias AgeisEsta é a terceira parte da série de artigos sobre Metodologias de Desenvolvimento Ágil. Estes artigos são baseados no Trabalho de Conclusão de Curso apresentado como exigência para a obtenção do grau de Bacharel em Ciência da Computação da Faculdade Anhanguera de Campinas – Unidade 3, denominado “Metodologias de Desenvolvimento Ágil Aplicadas No Desenvolvimento De Softwares Em Empresas De Pequeno Porte“, escrito por Felipe Morandin, Fernando Fonte e Tiago Souza.

Espero que você aproveite a leitura.

2.2 – Extreme Programmimg

2.2.1 – Características do conceito

Extreme Programmimg, mais conhecido como XP, é uma das metodologias de desenvolvimento ágeis mais populares.  Foi criada por Kent Back e Want Cunningham entre a década de 80 e 90, tendo como principal ponto de referência a experiência no desenvolvimento em Smalltalk , cujas suas principais práticas são: refatoração, programação em par, mudanças rápidas e não previstas, feedback constante do cliente, desenvolvimento iterativo e testes automatizados, analisando o Smalltalk sobre esse ponto de vista o XP pode ser o modo de agir do Smalltalk para outros ambientes, sem muitas novidades (Beck, 1999).

 2.2.2 – Metodologias

O Extreme Programmimg por sua vez define um conjunto de doze práticas de desenvolvimento, sobre os quatros valores adotados pelo XP como sendo os pontos mais relevantes no desenvolvimento.

 2.2.2.1 – Valores

Os quatros valores adotados pelo XP são feedback, comunicação, simplicidade e coragem, descritos nas seguintes seções (Beck, 1999).

 2.2.2.2 – Feedback

A compreensão dos requisitos por parte dos desenvolvedores é uma das atividades mais complexas em todo o desenvolvimento, isso por sua vez é tão difícil quanto o cliente transmitir suas necessidades e desejos do software, assim para amenizar essa dificuldade, é fundamental que haja uma forte interação entre o cliente e os desenvolvedores ao longo do desenvolvimento.

Por sua vez a compreensão das necessidades vem de um aprendizado contínuo, nela o desenvolvedor apreende sobre os problemas do negócio e as limitações técnicas (Weinberg, 1971, p.102).

Com a diminuição da defasagem do sistema, o desempenho do mesmo só tende aumentar, isso é obtido através da ampliação do aprendizado do software obtido pelos desenvolvedores e o entendimento das possibilidades tecnológicas e suas limitações (Senge, 2002, p.119).

 2.2.2.3 – Comunicação

Os projetos de software sempre envolvem duas partes e por isso para o desenvolvimento a comunicação é essencial, através dessa comunicação é que o usuário informa o que ele necessita, e, que o desenvolvedor apresenta as considerações que afetam a solução e a velocidade de implementação da mesma.

Ambas as partes podem ser compostas por várias pessoas e com isso a frequência da comunicação entre elas tende a ser cada vez mais dinâmica o que faz com que haja desentendimentos ou incompreensão de algum aspecto do projeto.

A transmissão das idéias dentro da equipe que está desenvolvendo o projeto precisa ser eficaz, e isso pode ser resolvido de forma simples. Um dos melhores mecanismos é colocar todos da mesma equipe em um único local, onde todos poderão compartilhar suas idéias através do diálogo e consequentemente os vários elementos que compõem a comunicação, tais como expressões faciais, gestos, postura, palavras verbalizadas e tom de voz estarão ao alcance de todos. (Teles, 2004, p.48)

A velocidade com que a comunicação se estabelece entre as partes envolvidas no projeto é de extrema importância para o andamento e o custo do projeto (Cockburn, 2002, p.81).

 2.2.2.4 – Simplicidade

Segundo estudos grande parte dos recursos gastos no desenvolvimento de software, são esforços desnecessários, pois são funcionalidades que nem sequer serão utilizadas. A ocorrência de “fenômenos” durante o desenvolvimento ajudam a esclarecer esse esforço desnecessário, são eles:

Com o escopo fechado do projeto, quando as alterações surgem os desenvolvedores evitam implantá-las assim que mencionadas.

Desenvolvem-se soluções genéricas para facilitar as alterações solicitadas.

Produção de funcionalidades adicionais na tentativa de antecipar as solicitações de alterações.

Os casos acima são influenciados devido às preocupações que são justificáveis, pois fixar o escopo no inicio do projeto é arriscado, já que as verdadeiras necessidades são notadas quando o software é implantado, por isso a adoção de um modelo de desenvolvimento iterativo com iterações curtas, assim como o XP proporciona (Poppendieck & Poppendieck, 2003).

Para que uma equipe de desenvolvimento seja capaz de suprir essas necessidades é necessário desenvolver funcionalidades com um pequeno escopo, isso leva ao desenvolvimento somente dos itens essenciais com a maior qualidade possível e de forma que novas funcionalidades sejam inseridas com facilidade (Boehm & Turner, 2003, p.41).

 2.2.2.5 – Coragem

Alguns temores costumam assombrar os desenvolvedores e os clientes envolvidos no projeto, esses temores por sua vez exercem influência significativa no desenvolvimento.

  • Clientes temem:
  • Não obter o que pediram;
  • Pedir a coisa errada;
  • Pagar demais por muito pouco;
  • Jamais ver um plano relevante;
  • Não saber o que está acontecendo e
  • Fixarem-se em suas primeiras decisões e não serem capazes de reagir a mudanças nos negócios.
  • Desenvolvedores, por sua vez, temem:
  • Ser solicitados a fazer mais do que sabem fazer;
  • Ser ordenados a fazer coisas que não façam sentido;
  • Ficar defasados tecnicamente;
  • Receber responsabilidades, sem autoridade;
  • Não receber definições claras sobre o que precisa ser feito;
  • Sacrificar a qualidade em função de prazo;
  • Ter que resolver problemas complicados sem ajuda e
  • Não ter tempo suficiente para fazer um bom trabalho.

As equipes XP reconhecem esses temores e buscam formas de lidar com eles utilizando mecanismos de segurança para garantir a qualidade do projeto, minimizando o risco desses temores (Beck e Fowler, 2001).

O cliente teme não obter o que foi solicitado, ou mesmo solicitar algo de que não precisa, para protegê-lo o XP é constituído de iterações curtas, e mesmo que o cliente solicite algo que não precisa ou a equipe de desenvolvimento implemente algo de maneira errada, isso logo é descoberto devido ao curto tempo entre as iterações no desenvolvimento (Poppendieck & Poppendieck, 2003).

Outra preocupação dos desenvolvedores é não ter tempo suficiente para desenvolver as funcionalidades necessárias com qualidade, o XP trata dessa preocupação dividindo a responsabilidade pelas decisões técnicas e de negócio, o cliente escolhe as funcionalidades a serem implementadas e em que ordem e os desenvolvedores estimam os prazos necessários para o desenvolvimento (Beck e Fowler, 2001).

 2.2.3 – Práticas

As práticas citadas abaixo devem ser aplicadas em conjunto, pois aplicadas de modo isolado podem não produzir a agilidade esperada, isso se deve ao fato das práticas apoiarem umas as outras.

 2.2.3.1 – Jogo de planejamento (The Planning Game)

Através desse planejamento é possível determinar o escopo das próximas versões, baseando-se na combinação das prioridades do negócio e estimativas técnicas. O planejamento assegura que toda a equipe siga trabalhando no mais importante a cada momento do projeto.

O planejamento de projetos com metodologia XP procurar dividir o projeto utilizando dois conceitos: releases[1] e iterações. Dentro desses dois conceitos são encontradas subdivisões; o release tem duração de poucos meses e se divide em iterações que tem a duração de aproximadamente duas semanas. Dentro dessas iterações as tarefas são dividas de forma que ocupem alguns dias (Beck & Fowler, 2001, p.139).

O release representa um conjunto de funcionalidades fechadas que são liberadas para o uso do usuário após o término do tempo determinado no planejamento, neste momento o cliente, junto com a equipe de desenvolvimento, realiza testes e avalia as novas prioridades para o próximo release, com isso os ajustes e erros encontrados são detectados antes do próximo desenvolvimento (Jeffries & Anderson, 2001, p.55).

Como foi dito anteriormente a responsabilidade pela definição das prioridades é feita pelo cliente e a estimativa é feita pela equipe responsável pelo desenvolvimento, o que faz com que o cliente tenha uma visão sobre o custo e tempo que o próximo release levará para ser concluído e qual o seu custo estimado (Jeffries & Anderson, 2001, p.14).

 2.2.3.2 – Pequenas Versões (Small releases)

O XP procura maximizar o retorno dos projetos assegurando que o maior valor de negócio possível seja entregue ao final de cada release e que cada release tenha uma duração curta. Isso é feito através do processo contínuo de priorização que seleciona sempre as funcionalidades de maior valor para serem implementadas primeiro. Além disso, procura antecipar o retorno entregando software rapidamente.

Essa metodologia trabalha com a prática de releases curtos que consistem em colocar o sistema em produção com freqüência, em prazos curtos, normalmente de dois ou três meses. Isso costuma ser bem-vindo, porque clientes querem entregas rápidas (Poppendieck & Poppendieck, 2003, p.70-71).

Colocando releases em produção rapidamente, o cliente tem a oportunidade de receber feedback concreto sobre o real potencial de retorno do projeto. Portanto, tem a chance de decidir cedo, quando ainda não gastou muito, se continua ou não com o projeto e particularmente se continua ou não investindo na mesma equipe de desenvolvimento. Portanto, a adoção de releases curtos funciona como uma estratégia de gestão de risco do projeto (Teles, 2004).

 2.2.3.3 – Metáfora (Metaphor)

Uma equipe de desenvolvimento formada por diversos programadores convive, entre outros, com o desafio de manter a integridade conceitual do sistema mesmo havendo diversos projetistas criando estruturas novas na arquitetura ao longo do tempo. Isso pode ser resolvido caso exista um mecanismo capaz de alinhar as idéias dos diversos projetistas assegurando que todos compartilhem uma visão única de como adicionar e manter as funcionalidades do sistema. O XP utiliza o conceito de metáfora para atingir este objetivo (Cockburn, 2002, p.227).

Segundo Cockburn (2002, p.227) a programação é vista como uma atividade através da qual os programadores formam ou atingem uma certa idéia, uma teoria, sobre os problemas que têm nas mãos, ou seja, o programador é capaz de explicar o que cada parte do programa é capaz de fazer e responder de imediato sobre qualquer modificação do sistema. Essas teorias representam a visão de como as decisões influenciam na estrutura do software.

 2.2.3.4 – Projeto Simples (Simple design)

Existem pelo menos quatro coisas que os usuários de um software esperam dele:

  • Que faça a coisa certa;
  • Que funcione;
  • Que seja fácil de utilizar;
  • Que possa evoluir com o tempo.

As práticas do XP se complementam formando um conjunto que busca atingir estes objetivos. Para assegurar que o sistema esteja fazendo a coisa certa e esteja funcionando, o desenvolvimento é executado em iterações curtas nas quais se implementa um pequeno conjunto de funcionalidades e por sua vez o feedback gerado ao final de cada iteração permite que os usuários avaliem se o sistema realmente está fazendo a coisa certa e se está funcionando.

Adotar iterações curtas, portanto, é um mecanismo importante para atingir parte destes objetivos, entretanto, impõe um desafio. Como fazer a análise, design, implementação, teste e depuração de um conjunto de funcionalidades em uma ou duas semanas? Isso só é possível se os desenvolvedores mantiverem o design da aplicação suficientemente simples (Beck, 2000).

 2.2.3.5 – Testes (Testing)

Sistemas computacionais e projetos de software costumam vivenciar diversas dificuldades ao longo do tempo. Um dos problemas mais caros e recorrentes é a incidência de defeitos.

Quando um defeito é identificado, faz-se necessário depurar o software. Por isso, é essencial que as equipes de desenvolvimento sejam capazes de reduzir a incidência de bug[2]’s e o custo associado à depuração e eliminação dos mesmos. Isso é válido durante o projeto, porém é ainda mais relevante durante a manutenção do sistema.

Os desenvolvedores se concentram em dois aspectos durante a programação. O código deve se manter limpo e precisa funcionar. O XP se concentra sobretudo em dois tipos de testes: o teste de unidade e o teste de aceitação. O primeiro tenta assegurar que cada componente do sistema funcione corretamente. O segundo procura testar a interação entre os componentes, as quais dão origem às funcionalidades (Beck, 2000).

 2.2.3.6 – Refatoração (Refactoring)

Sistemas mudam ao longo do tempo, especialmente quando são desenvolvidos de forma interativa. Tradicionalmente os reparos tendem a prejudicar a estrutura e, além disso, sem melhoria contínua qualquer sistema de software ficará com vários problemas. As estruturas internas irão se calcificar e se tornar frágeis (BROOKS, 1995, p.243).

Por esta razão, projetos XP investem diariamente no aprimoramento do design e na identificação de pontos da arquitetura que estejam se degradando, a medida que eles são encontrados, são corrigidos através de uma técnica conhecida como refatoração.

A refatoração é o processo de fazer mudanças em um código existente e funcional sem alterar seu comportamento externo. Em outras palavras, alterar como ele faz, mas não o que ele faz. O objetivo é aprimorar a estrutura interna (Astels, 2003, p.15).

Tal processo é conduzido permanentemente por todos os desenvolvedores como uma forma disciplinada de limpar o código minimizando a chance de introduzir bugs (Fowler, 2000, p.xvi)

Portanto, o objetivo é elaborar programas que sejam fáceis de ler, tenham toda a lógica em um e apenas um lugar, não permitam que mudanças ameacem o comportamento existente e permitam que lógicas condicionais sejam expressas da maneira mais simples possível (Fowler, 2000, p.60).

 2.2.3.7 – Programação em par (Pair Programming)

Segundo Williams e Kessler (2003, p.3) programação em par é “um estilo de programação no qual dois programadores trabalham lado a lado em um computador, continuamente colaborando no mesmo design, algoritmo, código e teste.” Durante um projeto XP as equipes utilizam essa técnica.

Esta técnica é implementada para reduzir os riscos de eventuais falhas. Quando um programador desenvolve em par, ele conta com a presença de outro desenvolvedor que faz uma inspeção imediata de todo o código que é produzido.

A programação em par torna-se um processo diário de teste, no qual a equipe de desenvolvimento consegue utilizar inspeções com freqüência sem incorrer nos problemas que tornam os testes tradicionalmente desagradáveis.

A programação em par também é útil no processo de aprendizado dos desenvolvedores, já que os desenvolvedores compartilham seus conhecimentos (Williams & Kessler, 2003, p.29).

Finalmente, a programação em par também ajuda a elevar a motivação dos desenvolvedores, tornando o trabalho mais divertido e facilitando a comunicação.  Naturalmente, quanto mais agradável e divertido for o trabalho de programação, mais produtivo o mesmo tenderá a ser (Williams & Kessler, 2003, p.239).

 2.2.3.8 – Propriedade Coletiva (Collective owneship)

Equipe XP pratica o conceito de código coletivo, ou seja, todo o código desenvolvido pertence à equipe, isto é, qualquer um da equipe pode melhorar o que for necessário (Jeffries & Anderson, 2001, p.122).

Isto significa que os desenvolvedores têm a oportunidade de trabalhar com pessoas diferentes e em partes diferentes do código. Como as alterações no código podem causar erros, a prática de código coletivo só pode ser adotada com segurança se a equipe investir em testes automatizados (Beck, 2000, p.99-100)

A adoção do código coletivo também permite que a equipe avance mais rapidamente. O código permanece mais limpo porque os programadores não são forçados a contornar uma deficiência em um objeto criando um outro (Jefries & Anderson, 2001, p.122).

A propriedade coletiva do código é bastante utilizada juntamente com a programação em par, pois é possível identificar códigos complexos dentro de pouco tempo (em algumas horas) e com isso os programadores são obrigados a colocar no sistema códigos simples e eficazes.

2.2.3.9 – Interação continua (Continuous integration)

Equipes XP normalmente são compostas por diversos programadores, trabalhando em pares de acordo com a prática de código coletivo. Isso cria dois problemas práticos. O primeiro é que diversos indivíduos estão trabalhando na mesma funcionalidade e ocorre uma necessidade de sincronização. O segundo é que os pares precisam ser capazes de evoluir rapidamente sem interferir no trabalho uns dos outros (Poppendieck & Poppendieck, 2003, p.34).

Esta questão é resolvida no XP utilizando-se uma prática conhecida como integração contínua. Os pares trabalham de forma isolada, porém integram, diversas vezes ao dia, o que produzem com a versão mais recente do código em produção. Isto é, os pares se sincronizam com freqüência à medida que terminam pequenas atividades de codificação (Beck, 2000).

O processo de integração é serial, ou seja, somente um par pode integrar o seu código de cada vez, assim assegura-se que eventuais erros de integração estarão sempre relacionados a um único par: aquele que está integrando no momento. Somente após assegurar que a integração está perfeita, todos os testes executam com sucesso e o sistema encontra-se em um estado consistente poderá outro par fazer a integração (Beck, 2000).

 2.2.3.10 – Semana de 40 horas (40-hour week)

O XP defende um ritmo de trabalho que possa ser mantido, sem prejudicar o bem estar da equipe. Trabalho além do horário normal pode ser necessário, mas fazer horas extras por períodos maiores que uma semana é sinal de que algo está errado com o projeto.

 2.2.3.11 – Cliente junto ao desenvolvedor (On-site customer)

No desenvolvimento de software medir o tempo necessário que será gasto até o fim do desenvolvimento é uma tarefa completamente complexa, pois o tempo está atrelado a diversos problemas que podem ocorrer durante o desenvolvimento.

Para facilitar o cumprimento do prazo que foi estabelecido para o desenvolvimento é preciso que o cliente como os desenvolvedores cumpram seus papéis, infelizmente a falta de feedback[3] entre o cliente e os desenvolvedores gera falhas nos projetos. O XP se preocupa com esta questão e, por isso, tenta trazer o cliente para próximo da equipe durante o desenvolvimento, em outras palavras, colocar o cliente no mesmo ambiente que a equipe de desenvolvimento (Cockburn, 2002, p.179).

Com o cliente presente durante o desenvolvimento, o ciclo continuo de feedback é viabilizado e permite que mudanças sejam feitas ao longo do desenvolvimento e de forma rápida. É importante lembrar que para que o feedback tenha efeito deve haver proximidade física (Jeffries & Anderson, 2001, p.18).

A proximidade entre o cliente e os desenvolvedores também produz outros pontos positivos, um deles é o aumento de confiança entre a equipe e o cliente, no qual o cliente é capaz de perceber os esforços aplicados pela equipe de desenvolvimento (Teles, 2004).

 2.2.3.12 – Padronização de código (Coding Standards)

Para um bom desenvolvimento é preciso que a equipe adote um padrão a ser seguido. Este padrão ajuda toda a equipe simplificando o desenvolvimento e a comunicação e, através da programação em par e da propriedade coletiva, pode-se assegurar que este padrão será seguido.

Como o código passa por várias revisões durante as etapas de testes é fácil detectar a falta de padrão e corrigir antes que a versão do software evolua para o próximo release (Demarco, 2001, p.109).

 


[1]              Release é o nome dado ao lançamento de uma nova versão.

[2]              Bug é o nome dado para os defeitos que são achados no sistema.

[3]              Feedback é o termo usado para caracterizar as interações do cliente com a equipe no sentido de troca de informações sobre a qualidade e desempenho.

Índice:

Últimos 5 artigos de Fernando Fonte

Sobre Fernando Fonte

De Campinas-SP, bacharel em Ciência da Computação. Atua como Analista Programador em uma empresa de tecnologia. Tem experiência no desenvolvendo de softwares para comunicação e controle de hadware via porta serial e sistemas ERP. Possui conhecimento em sistemas operacionais Windows, programação Delphi e Visual Basic 6 e Banco de Dados SQL Server e MySQL. Atualmente estuda C# e Android. Tem interesse em Jogos, Celulares, Smartphones, Notebooks e tudo que for relacionado a tecnologia. Fundador deste site e editor chefe, convidou amigos para lhe ajudar com este projeto.

Deixe uma resposta