Produções em Tecnologia da Informação

Estudo Sobre Extreme Programming
Written by Adonai Estrela Medrado   
Tuesday, 01 July 2008 14:55

Sobre

Este trabalho foi apresentado em novembro/2002 na Universidade Católica do Salvador e é de autoria de Adonai Medrado, Nancy Takahashi, David Nunes e Edmilson Santana.

Resumo

Este trabalho apresenta Extreme Programming começando por mostrar seu surgimento como uma metodologia de desenvolvimento de software.

Avança-se mostrando o objetivo e funcionamento dos principais conceitos de Extreme Programming, dentre eles a divisão da equipe do projeto, as formas de planejamento e a programação em par.

Em seguida explicitam-se as vantagens, desvantagens e restrições desta metodologia em cada conceito mostrando também os problemas que ela enfrenta com equipes e projetos muito grande.

Conclui-se que é importante estudar uma metodologia com conceitos tão extremos e inovadores para que se possa ou colocá-la em prática por completo ou mesmo aproveitar algumas de suas idéias para fortalecer outras metodologias.

Introdução

Os problemas encontrados no desenvolvimento de software são muitos e geralmente estão relacionados à adoção de uma metodologia inadequada, resultando em produtos que não atingem seus objetivos ou o fazem de forma desorganizada e penosa. Este fato já foi verificado e analisado por diversos consultores e estudiosos da área. Observemos o que diz [Reed 00] e [Coad 91]:

São poucos os projetos que transcorrem conforme o planejado. Muitos começam com grande entusiasmo, mas, geralmente, terminam em uma corrida desenfreada para conseguir produzir alguma coisa. O resultado freqüentemente é prejudicado por imprecisão ou, pior ainda, provoca respostas inenarráveis dos patrocinadores do projeto. [Reed 00]

(...) [em um grande projeto de controle de tráfego aéreo] Uma equipe de analistas (a “Equipe de DFDs”) iniciou o projeto usando diagramas de fluxo de dados para desenvolver uma decomposição funcional global que servisse de base para especificações posteriores. Enquanto isso, uma segunda equipe de análise (a “Equipe de Dados”) começou concentrando-se nas informações de que o sistema precisava e depois elaborando um modelo de informações (...). O tempo passou, e a equipe de DFDs continuava tentando entender aspectos básicos do domínio do problema (...). Por outro lado, a Equipe de Bancos de Dados passou a entender profundamente tudo o que dizia respeito ao controle do tráfego aéreo. Contudo, os resultados obtidos pelas duas equipes não se casavam; pior ainda, eram contraditórios. A princípio, os dois modelos deveriam convergir. Entretanto, devido às pressões de cronograma e orçamento, decidiu-se partir assim mesmo para o projeto preliminar, na esperança de que as discrepâncias fossem resolvidas nesta fase. Infelizmente, a Equipe de Bancos de Dados passou a ser vista como um grupo de pessoas inflexíveis e até problemáticas; as pessoas (e suas carreiras) pagaram um alto preço por esta situação e sua resolução inadequada. [Coad 91]

Os exemplos de outros autores são muitos e diversos. Todos, no entanto, concordam que o problema está na metodologia, nos meios utilizados para produzir o software.

Várias metodologias foram propostas, as mais recentes tomando como base o modelo em espiral. [Reed 00], por exemplo, propôs o processo de desenvolvimento Synergy; já [Coad 91] propões uma abordagem clássica voltada à análise e projeto orientado a objeto.

Uma metodologia proposta por Kent Beck em 1998, denominada Extreme Programming, chama atenção pela sua filosofia inovadora, buscando identificar e solucionar os problemas através de soluções extremas.

Seu conceito é, relativamente novo, e está sendo estudado e aplicado por vários interessados (ver referência bibliográfica) e também está servindo como suporte para a Modelagem Ágil.

Baseia-se na idéia de resolver os problemas do desenvolvimento de forma a dar menor margem possível a erros. Por exemplo, tendo uma equipe de clientes trabalhando lado a lado com os desenvolvedores espera-se resolver o problema de desenvolver um software que atenda as necessidades e expectativa do cliente.

O potencial da metodologia proposta por Kent Beck deve ser estudado com afinco, pois os sucessos relatados são importantíssimos, e mesmo que ela não se mostre eficiente no decorrer dos anos pode servir como base para outras metodologias mais aprimoradas.

Objetivo

Este trabalho tem como objetivo estudar a metodologia de desenvolvimento de software proposta por Kent Beck, denominada Extreme Programming (Programação Extrema). Para tanto serão estudados os seus principais conceitos, no que diz respeito à funcionalmente, aplicação e vantagens.

Será adotada uma abordagem detalhada o bastante para que os conceitos vistos possam ser adaptados a outras metodologias caso não haja a possibilidade de aplicar a Extreme Programming em sua totalidade.

Conceitos

A Extreme Programming se baseia em uma série de conceitos que são ou novos ou só eram utilizados para desenvolvimento no nível acadêmico.

Cada um destes conceitos podem ser localizados inteiramente ou parcialmente em cada uma das etapas do desenvolvimento de software. Por exemplo, a programação em par é parte tanto do processo de análise quanto do processo de desenvolvimento; as histórias dos usuários estão diretamente ligadas à parte de planejamento.

A compreensão completa de cada um dos conceitos da Extreme Programming tem importância fundamental e sua parcela de colaboração no sucesso da Extreme Programming.

Os principais conceitos da Extreme Programming são:

  • Equipe;

  • Planejamento;

  • Versões do Software;

  • Programação em Par;

  • Design Evolucional;

  • Integração do Sistema;

  • Estilo Consistente;

  • Protótipo.

Equipe

A área de recursos humanos das organizações tem sido muito estudada por um motivo muito simples: não existe organização sem pessoas. Segundo [Carvalho 01] “para verificar de forma simples isto, basta imaginarmos nosso local de trabalho com computadores, máquinas, mesas e sem nenhuma pessoa”.

[Carvalho 01] ainda faz uma análise sobre as relações de trabalho e sua evolução em algumas organizações e atraso em outras assinalando ainda que os funcionários estão deixando de ser funcionário e passando a ser colaboradores no sentido que todos devem ajudar para que a empresa atinja o seu objetivo.

A Extreme Programming segue baseada na linha de valorização do recurso humano observando as relações interpessoais. Cada membro da equipe exerce um papel diferente e tem direitos que implicam em deveres dos outros membros. Existe então um comprometimento geral no crescimento e formação dos integrantes do grupo de trabalho. Para qualquer empresa este crescimento implica em agregar valor ao capital intelectual. Nas palavras de [Carvalho 01]:

Todos os trabalhadores de uma organização, independente da posição hierárquica, do mais baixo ao presidente da empresa, não só pode, como deve contribuir para a formação do capital intelectual desta organização, mas para isso deve haver uma política clara, definida e principalmente um sistema de informações por trás de tudo, que não precisa ser complexo, mas deve possuir as funções básicas de armazenar, criando um banco de dados, tratar e divulgar a informação de forma objetiva e possivelmente agregando valor. [Carvalho 01]

As Duas Equipes

A Extreme Programming, sempre se preocupando com a relação entre os indivíduos, divide a equipe responsável pelo software a ser desenvolvido em duas: a equipe do cliente e a equipe dos desenvolvedores. Estas equipes devem colaborar em tudo que for necessário para que o melhor software possível seja desenvolvido.

No entanto, como parte do processo de divisão de tarefas cada equipe tem seus objetivos específicos, direitos e participantes.

Equipe do Cliente

A equipe do cliente é composta por pessoas que vivenciam o problema e serão diretamente beneficiadas pela solução que o software desenvolvido implementará.

A tarefa da equipe do cliente é de cobrar e colaborar para que tudo seja feito para que o produto final atenda completamente aquilo que é esperado para a solução do problema.

É requisito da Extreme Programming que a equipe de cliente esteja sempre junto auxiliando a equipe de desenvolvimento em todos os passos, podendo estar alojada fisicamente, por exemplo, na mesma sala.

Contadores de Histórias

Na maioria dos casos os desenvolvedores não estão familiarizados com o problema a ser resolvido computacionalmente. Então os clientes necessitam colocá-los a par. Em Extreme Programming isto é feito através de histórias.

História (substantivo feminino): (...) (7) conjunto de dados concernentes a um indivíduo ou coisa; (8) caso, aventura ou problema particular (...) [Houaiss 01]

Com a ajuda da definição de história pode-se entender claramente que o papel dos Contadores de Histórias é fazer com que a equipe de desenvolvimento entenda o problema a ser resolvido bem como os fatores a ele relacionados.

É já conhecida a importância que as histórias têm no processo de conhecimento de um problema. Este estudo é desenvolvido principalmente com crianças, segue a conclusão da [TV Cultura 02]:

Histórias são muito importantes para o desenvolvimento das crianças, pois dão aos jovens uma oportunidade de projetar seus pensamentos e sentimentos em personagens. Além disso, permitem que as crianças explorem dúvidas e questionamentos para chegarem a um entendimento. [TV Cultura 02]

Para os programadores, que não conhecem os problemas as histórias são úteis de forma análoga à utilidade que uma determinada história tem para uma criança.

Segundo [Astels 02] “os melhores contadores de histórias experimentaram primeiro o problema (...) [e são] responsáveis por garantir a convergência para uma solução sob o ponto de vista dos requisitos”.

Os Aceitantes

Os aceitantes podem (1) ser os próprios contadores de história ou (2) serem pessoas agindo sob ordem destes para executar os testes de aceitação.

A responsabilidade do aceitante está em verificar se o que foi desenvolvido pela equipe de cliente está de acordo com o que desejava o contador de história ao contar sua história.

Os Proprietários do Ouro

Proprietários do ouro são as pessoas responsáveis por controlar e responder sobre os aspectos financeiros do projeto.

Eles garantem que o projeto tenha pessoas, o financiamento e o equipamento adequados para atingir o seu objetivo pretendido, um sistema que possa ser distribuído. [Astels 02]

Planejadores

Os planejadores são as pessoas que vêem as necessidades de distribuição do corpo de usuários pretendidos. Eles entendem os ciclos de negócios envolvidos nessa base de usuários e programam a distribuição adequada. [Astels 02]

Verifica-se que o planejador tem o papel de verificar aquilo que é necessário e quando é necessário. O planejador acompanha e ajuda a planejar as versões do software.

O Chefão

Hierarquicamente localizado como gerente das duas equipes tentando garantir que não existam obstáculos na organização para a implementação da solução informatizada.

Equipe de Desenvolvimento

Os desenvolvedores são responsáveis por estimar as tarefas, ajudar os clientes a verem as conseqüências de suas decisões, adaptar os seus processos de desenvolvimento e entregar o sistema. Essa não é uma tarefa fácil. [Astels 02]

Para ajudar na tarefa de desenvolvimento a Extreme Programming desenvolveu uma série de métodos, entre eles a metáfora e as histórias do usuário, que ajudam os desenvolvedores.

Existem ainda outros conceitos aplicados e que também colaboram para o sucesso do trabalho da equipe. Por exemplo, aspectos do paradigma adotado. No caso do paradigma orientado a objeto têm-se os objetos e suas relações como facilitador na construção, alteração e entendimento do sistema.

Como ocorre na equipe do cliente, na equipe dos desenvolvedores cada individuo recebe uma tarefa específica que deve cumprir para que os objetivos sejam atingidos.

O Técnico

O técnico deve ser uma pessoa com experiência capaz de ajudar a equipe para que o processo de desenvolvimento ocorra normalmente, da forma que estava programado. Segundo [Astels 02] “os técnicos são a voz da razão nas crises”.

Normalmente são pessoas que já desenvolveram sistemas similares ou possuem uma história maior em análise e desenvolvimento do que o resto dos componentes da equipe.

O Acompanhador

Extreme Programming propõe que a todo momento as tarefas estejam sendo checadas. O acompanhador é o indivíduo responsável por fazer este acompanhamento identificando o progresso e garantindo que tudo ocorra como o planejado. Os atrasos e as dificuldades por seguir o cronograma de uma ou várias tarefas devem ser identificados pelo acompanhador sobre pena de ocorrerem atrasos.

O Facilitador

O facilitador é responsável por facilitar as relações entre as equipes de cliente e dos desenvolvedores. A importância do seu papel é notada principalmente nas reuniões. Quando surgem conflitos, ele é responsável por encontrar uma solução mais próxima da ótima que atenda os interesses gerais.

O facilitador é a pessoa que na equipe de desenvolvimento tem a melhor comunicação e as melhores habilidades pessoais. [Astels 02]

O Arquiteto

Os arquitetos são entidades responsáveis por dar uma arquitetura do sistema conforme as necessidades, não fornecer uma arquitetura completa do sistema desde o início. Esta forma de trabalho faz parte da visão evolucional de Extreme Programming. É muito complicado para os desenvolvedores entenderem tudo que os clientes desejam desde o início como também é muito difícil para os clientes terem uma visão final daquele sistema que precisam. Desta forma o sistema é construído por partes (conceito de interação e versões do software) e o responsável por dar esta arquitetura para estas partes é o arquiteto.

Planejamento

Na Extreme Programming, o planejamento é dividido em planejamento de releases, de interações e tático. Todos eles de igual importância e com políticas bem definidas. A maior parte do planejamento e do desenvolvimento propriamente dito é baseado nas histórias contadas pelo contador de história, denominadas histórias do usuário.

Fisicamente as histórias dos usuários são anotadas em pedaços de papel (cartões) e segue uma padronização utilizada para as estimativas e testes do sistema. Será percebido ao longo da análise de cada parte do planejamento a importância das histórias do usuário.

Requisitos

De forma genérica o planejamento em Extreme Programming depende principalmente da visão do sistema e das histórias dos usuários.

Visão do Sistema

As visões do sistema são, de forma simplificada, os objetivos do sistema. Preferencialmente devem ser curtas e escritas em um pedaço de papel, denominado cartão de visão.

Segundo [Astels 02], William C. Wake, um estudioso em Extreme Programming, sugeria que a visão do sistema deve ser curta, 25 palavras ou menos. Acrescenta ainda que deve existir uma voga e mesmo uma adaptação, pois alguns sistemas, devido a sua complexidade, exigem mais palavras.

Histórias do Usuário

Como já referenciadas na seção 2.1.1.1.1 as histórias contadas pelos contadores de história têm importância fundamental no entendimento do sistema e são escritas em cartões que serão referenciados durante boa parte do desenvolvimento e teste.

Cabe esclarecer que inicialmente devem-se levantar todas as histórias do usuário, mas eventualmente pode-se adicionar ou remover alguma, conforme as necessidades dos clientes.

[Wells 99-1] acha importante chamar atenção para a diferença entre as histórias do usuário e a especificação do sistema.

A grande diferença está no nível de detalhes. As histórias dos usuários devem ter um nível de detalhe suficiente para estimar, com pouca possibilidade de erro, quanto tempo à funcionalidade demorará a ser implementada. No momento certo, os desenvolvedores daquela funcionalidade iram ao cliente e receberá pessoalmente uma descrição detalhada.

[Wells 99-1] e também [Astels 02] ainda acrescentam que as histórias do usuário não devem recair sobre detalhes de tecnologia, layout de banco de dados e algoritmos.

Fornecimento de Estimativas

Como parte do planejamento do sistema estão as estimativas que em algumas metodologias fazem parte de cronogramas. Em Extreme Programming, as estimativas são colocadas nos cartões das histórias do usuário no canto superior direito.

O papel de fornecer estimativas é de toda a equipe, mas principalmente dos técnicos que possuem uma experiência maior no desenvolvimento de softwares.

[Astels 02] aconselha que as histórias não tenham estimativas para mais de três semanas, pois tais histórias demorariam a sair nas versões liberadas aos clientes para implantação que geralmente possuem intervalo de no máximo três semanas, demorando para a equipe receber um feedback e do cliente receber a funcionalidade acordada.

Se uma história obtiver estimativa maior que três semanas, deve-se então dividi-la.

As estimativas devem se basear em (1) quanto tempo um desenvolvedor levará para executar aquela tarefa trabalhando sozinho se (2) não tiver mais nenhuma outra tarefa para fazer.

Planejamento de Releases

Releases são as versões do software liberadas para implantação. É aconselhado por [Astels 02] que o tempo entre um release e outro seja de no máximo três semanas.

O planejamento dos releases ocorre nas reuniões de planejamento. Nestas reuniões cada equipe, bem como cada participante da equipe, tem seu papel.

É importante que desenvolvedores tomem as decisões técnicas e os clientes tomem as decisões relativas ao negocio. O planejamento de releases possui uma série de regras que permitem que todos os envolvidos no projeto tomem as suas próprias decisões. As regras definem um método para negociar uma agenda a que todos devem se comprometer. [Wells 99-2]

Nas reuniões de planejamento de versão as histórias devem ser divididas por versão cabendo a equipe de clientes definir prioridades e a equipe de desenvolvimento verificar a possibilidade e os prazos baseando-se nas estimativas já feitas nos cartões das histórias de usuários.

Segundo [Wells 99-2] existe o planejamento baseado em tempo e baseado em escopo. No primeiro, as datas das versões estão fixadas por algum motivo. Cabe aos clientes definir o que deve estar incluído no sistema em cada data e os desenvolvedores analisarão as possibilidades. Já no segundo, as datas serão definidas segundo as versões que os clientes desejam. Chamando atenção que as versões não devem ser muito distantes como aconselha [Astels 02].

Planejamento de Interações

[Reed 00], que propôs o modelo de desenvolvimento de software Synergy, definiu interativo como sendo “a aplicação de tarefas de uma forma repetitiva que funciona no sentido de melhorar um produto intermediário ou final”.

Inicialmente o produto não existe, depois é criada uma versão que atenda às funcionalidades básicas que é melhorada até atingir o sistema completo que é desejado necessário para o cliente.

Pode-se dizer que cada interação tem um resultado final. Existe, por exemplo, uma interação que leva ao release, mas esta interação é formada de outras interações que deram origem às partes integrantes do release.

Para uma equipe que está desenvolvendo em Extreme Programming pela primeira vez ou mesmo para um cliente que nunca participou de um projeto em Extreme Programming, é importante que a primeira interação que dará origem a um release, denominado sistema central, seja executada com perfeição.

A entrega desse sistema central é um marco importante. Ele prova para a equipe do cliente que a XP [Extreme Programming] funciona. Ele prova para a equipe de desenvolvimento que eles podem fazer com que ela aconteça. [Astels 02]

O planejamento de interações é desenvolvido a todo o momento, principalmente quando se faz o planejamento de releases.

Planejamento Tático

O planejamento tático baseia-se principalmente na separação de tarefas para uma determinada versão do software a ser desenvolvida.

Geralmente uma tarefa é feita por um desenvolvedor voluntário e um outro que desejou ajudá-lo. Aqui entra os aspectos de desenvolvimento em par, chamado em Extreme Programming de pair programming. Este conceito será detalhado em seções subseqüentes.

Controle

Todo o planejamento deve ser acompanhado e controlado para realmente se ter certeza de que será possível entregar no prazo aquilo que foi planejado para um release. Em Extreme Programming, as reuniões no início de cada dia servem exatamente para este fim.

As reuniões são feitas em pé, pois segundo [Astels 02], tendem a ser mais rápidas e ajudam a equipe a identificar problemas.

Outra função importante das reuniões de controle é que a equipe se mantém em sincronia.

Integração Contínua

Se um módulo de um sistema funciona perfeitamente quando executado sozinho isto não significa que ele funcionará perfeitamente quando estiver sendo executado em conjunto com os outros módulos.

Nos métodos de desenvolvimento tradicionais, onde muitas vezes os programadores não têm uma visão do sistema como um todo e sim apenas a visão específica do módulo construído por ele, cada programador ao terminar de escrever um novo módulo, o testa, e o integra ao sistema de forma paralela com outros programadores. Sem ao menos verificar se o resultado de toda esta integração foi satisfatório ou não.

Ao se fazer integrações periódicas do sistema inteiro assim como um teste conciso destas integrações à medida que pequenas partes do projeto são criadas a equipe de desenvolvimento tem um trabalho extra que é recompensado mais tarde na hora da integração final.

Times de programação em extreme programming chegam a fazer integrações e testes do sistema várias vezes ao dia (cerca de oito a dez vezes) evitando o tão conhecido “inferno da integração” que tanto acomete os sistemas desenvolvidos usando-se os métodos tradicionais.

Programação em Par

Toda produção de código em Extreme Programming é feita por dois programadores sentados lado a lado em uma mesma máquina. Esta prática assegura que toda a produção de código é revisada por ao menos duas pessoas, resultando assim em melhor desenho, melhor teste e melhor código.

Apesar de parecer ineficiente se ter dois programadores fazendo o trabalho de um programador, alguns estudos feitos por [Willians 00], docente da North Carolina State University em Raleigh, mostram que apesar do trabalho feito em dupla produzir menos código ele produz um código mais livre de erros do que o código produzido por um programador trabalhando sozinho.

Alguns programadores opõem-se a programação em par sem nunca terem ao menos a tentado. É necessário alguma pratica para fazer isto bem, e você precisa fazer isto bem por algumas semanas para poder ver os resultados. Noventa por cento dos programadores que aprendem a programar em par preferem este modo de programação, portanto programação em par é altamente recomendado para todos os times.

Programação em par, além de fornecer melhor código e teste também auxilia na comunicação do conhecimento através do time. Como os pares são mudados periodicamente, todos têm o beneficio de um conhecimento distribuído pelo grupo. Programadores aprendem, suas habilidades são aprimoradas ao mesmo tempo em que eles se tornam mais valiosos para o time e para a empresa. Mesmo fora da Extreme Programming, Programação em par representa um grande ganho para todos.

Design Evolucional

Seguindo a metodologia extreme programming um sistema, para ser construído, deve possuir um protótipo que servirá de base para a implementação do mesmo aos poucos, abstraindo as rotinas que não interessam às regras do negócio em questão e concentrando-se em modularizar o problema ao máximo, assim um grande sistema é construído através de pequenos pedaços que compõem o todo.

Ainda pela metodologia várias versões do software devem ser lançadas, e a cada uma delas uma funcionalidade é liberada após testada e homologada, ou seja o sistema tem uma evolução através de rápidas e pequenas implementações.

Integração do Sistema

Por possuir um protótipo em parte funcional, um sistema construído segundo esta metodologia pode ter seus módulos facilmente integrados, porém é necessário que haja alguém responsável por manter tal integração. A harmonia entre os pedaços do sistema deve ser considerada durante o desenvolvimento, e não em uma fase separada, para que ao término do desenvolvimento o trabalho de integração esteja automaticamente concluído.

Para que a integração possa proceder de maneira contínua é necessário que exista um repositório único onde estarão os códigos fontes do sistema, tal repositório possui um mecanismo de travas de versões de cada arquivo fonte, assim, evita-se perda de códigos acidentais e garante-se a integridade dos mesmos, permitindo verificar se alguns trechos de código foram alterados simultaneamente e dando a possibilidade a quem estiver atualizando o repositório escolher a melhor versão para ser integrada.

Além de possibilitar manter sempre a versão mais recente do sistema rodando, mesmo que este ainda possua partes não homologadas, pois cada desenvolvedor apenas colocará no repositório o código que julgar suficientemente estável para começar a ser testado para entrar em produção no próximo release liberado, integrado ou homologado.

Por ter a filosofia de integração contínua, o sistema deve sempre ser revisado para que este se mantenha rodando durante toda a fase de desenvolvimento. Assim, sempre um par de programadores deverá estar adequando todo o código que for adicionado ao repositório.

Estilo Consistente

Consiste em uma padronização do código escrito pela equipe de desenvolvimento e tem como objetivo otimizar a criação dos módulos do sistema, centralizando trechos de código que mais tarde poderão sofrer eventuais alterações, a depender das necessidades, seja por conta da adição de funcionalidades, modificação de regras de negócio ou até mesmo correção de erros, que por ventura não tenham sido detectados antes da liberação da funcionalidade.

Antes de desenvolver cada funcionalidade, unidades de testes devem ser desenvolvidas para que no momento em que estas estejam prontas, possam ser validadas de forma quase que automática. Em resumo a fase de testes começa antes da codificação de fato.

O Extreme Programming utiliza o conceito de código compartilhado, isto quer dizer que qualquer um dos desenvolvedores da equipe está apto a mexer em qualquer ponto do sistema sem a necessidade de realizar uma análise muito aprofundada do código em si, bastando apenas se focar mais na regra de negócio em si. O principal neste caso é a preocupação com a finalidade da funcionalidade em si e não com a forma de como é codificada.

O uso de padronização de código em outras formas de desenvolvimento também poderia otimizar o desenvolvimento do projeto. Mesmo que não seja utilizado o pair programming, quando da união dos módulos, é mais fácil de entender o que o outro desenvolvedor codificou.

Para que o estilo consistente possa funcionar da melhor forma possível todos devem estar atentos para os padrões que estão sendo definidos, e tais padrões são definidos em tempo real, por isso é interessante para a equipe que todos os desenvolvedores estejam sincronizados com as maneiras como o projeto é ‘governado’. Além disso torna-se importante que todos os elementos da equipe sejam proativos para que os padrões continuem num constante aperfeiçoamento.

Para exemplificar podemos citar um grupo de desenvolvedores que utiliza bibliotecas de códigos como frameworks, componentes personalizados para facilitar a criação das funcionalidades. Um framework em sua essência é uma biblioteca de códigos que oferece além de código pronto, uma padronização da maneira de criar os novos pedaços de códigos que são realmente necessários à regra de negócio em questão, são nesses trechos que se encontram de fato a ‘inteligência’ do sistema em desenvolvimento.

Simple Picture - Protótipo Evolutivo

Simple picture para a metodologia de desenvolvimento Extreme Programming significa ter um protótipo que além de conter toda a cara do sistema servirá como base para a construção do mesmo, por esse motivo tal protótipo deve ser feito de forma que toda a estrutura do sistema esteja pronta ao final da construção deste protótipo tenhamos todo o escopo do sistema funcional. Assim a navegação deve estar construída ao final desta fase e, portanto, a integração do sistema será facilitada pois, toda a estrutura de interface entre os módulos estará pronta.

Devemos observar que todos os membros da equipe de desenvolvimento devem compartilhar do mesmo protótipo gerado para que durante a fase de desenvolvimento dos componentes do sistema não tenhamos versões concorrentes do mesmo caminhando em paralelo.

O objetivo deste procedimento no projeto é a facilidade da realização dos testes e consequentemente na criação do código. Como vimos, devemos fazer os testes antes da codificação, o protótipo fica no intermédio destes processos. Pois além de fazer o interfaceamento entre as funcionalidades do sistema, ele serve também como meio de auxilio à comunicação entre cliente e desenvolvedores.

Refactoring

Está é uma técnica que consiste em reavaliar o código escrito para verificar a necessidade, possibilidade de reimplementar trechos que podem vir a ser comuns, podem ser melhorados em função de performance e também para facilitar a compreensão em possíveis futuras manutenções.

Os objetivos principais são tornar o código mais comunicável, menos duplicado e mais simples. Torná-lo mais comunicável significa fazer com que torne-se auto explicativo, ou seja, este deve rapidamente demonstrar sua intenção e seu comportamento sem que uma análise aprofundada seja necessária. Fazê-lo menos duplicado é fazer uso das técnicas possíveis de reutilização de código, desta forma durante o refactoring surgem idéias para a criação de frameworks. Tornar um código mais simples é uma questão que torna-se obvia no tocante a manutenção porém é interessante também no aspecto da própria compreensão do problema.

Não pode-se esquecer que o refactoring leva um tempo considerável do desenvolvimento e deve também ser executado por pares programadores. Este tempo deve ser levado em conta no planejamento.

Em [Kerievsky 02] são apresentados vários padrões de implementação para facilitar e agilizar o processo de refactoring. Analisando a obra podemos verificar que tais padrões são baseados nos Design Patterns, porém focados na engenharia de software.

A seguir vamos mostrar alguns exemplos de padrão de refactoring apresentados por [Kerievsky 02], vale ressaltar que a quase todos são direcionados para as tecnologias baseadas em Orientação a Objetos.

Construtores em Cascata

Se houver múltiplos construtores com código replicados. Cascateie-os para obter a menor duplicação de código possível.

A motivação apresentada pelo autor para se usar esta técnica é que o código implementado em um dos construtores deve ser gradualmente incrementado pelos outros aproveitando o existente.

Composição de Métodos.

Se a lógica do método estiver difícil de ser compreendida, encapsule a sua lógica em outros pequenos métodos que revelem a intenção da implementação de forma mais detalhada.

A motivação apresentada pelo autor para utilizar este padrão é justificada pela simplicidade de entendimento e extensibilidade proporcionada pela divisão do método em questão. Além disso, a procura e correção dos erros são mais precisas por se tratar de novos métodos que atuam em um escopo menor da lógica do algoritmo em questão.

Pode-se concluir que as técnicas de refactoring são custosas em curto prazo, porém em longo prazo podem trazer benefícios maiores inclusive economia de tempo ao se utilizar rotinas genéricas. Outro grande benefício é a reutilização de código, portanto precisa-se apenas testar o funcionamento deste no contexto de negócio no qual foi inserido.

Vantagens

Edson S. Gomi em entrevista em [Sucesu-SP] relatou que a Extreme Programming tem a vantagem do ganho de eficiência e eficácia no desenvolvimento de sistemas. Outros autores como [Romero 02] relata as vantagens focando o negócio, pois a Extreme Programming é capaz de suportar as mudanças contínuas de mercado e também oferecer ao cliente maneiras para verificar de forma rápida o retorno que o projeto de software dará a empresa.

Esta seção é dedicada a analisar as diversas vantagens da Extreme Programming nos principais conceituados vistos na seção 2.

Equipe

Com visto anteriormente, a equipe responsável pelo projeto é dividida em duas: a equipe dos clientes e a equipe dos desenvolvedores. O cliente traz a informação do problema e a equipe de desenvolvimento tenta encontrar a solução. O trabalho em conjunto, formando uma única equipe, tende a levar a resultados vantajosos para ambos os lados.

Os clientes conseguem o produto mais próximo daquilo que deseja, pois está sempre acompanhando o processo, testando e fazendo comentários que ajudaram em muito os desenvolvedores a criarem softwares mais adequados.

Os desenvolvedores conseguem desenvolver códigos úteis, com maior probabilidade de eficiência, pois os pontos de checagem ocorrem a todo o momento.

Tudo está baseado na maturidade das equipes. Ambas devem entender que é necessário ajudar a outra em seu trabalho para que o produto final possa atender as expectativas e solucionar o problema a que se propõe.

A Extreme Programming oferece vantagens sobre o desenvolvimento tradicional, pois têm maior possibilidades de corrigir erros na fase de criações do software, onde as alterações tem um custo menor, segundo [Astels 02].

Planejamento

Como coloca [Romero 02] as mudanças nas organizações ocorrem de forma rápida. Uma metodologia de desenvolvimento de software que não seja capaz de reagir a estas mudanças tende ao fracasso.

Extreme Programming como uma metodologia moderna foi construída levando em conta a existência destas mudanças. As histórias do usuário levantadas no início do processo não são estáticas. Pode-se acrescentar novas histórias ou mesmo remover outras.

O planejamento em Extreme Programming, em oposição ao que ocorre em outras metodologias, é feito ao logo do projeto e com o cliente. É o cliente quem decide o que será feito primeiro e o que pode esperar.

Extreme Programming, devido a seu planejamento de releases, herda vantagens de metodologias interativas e incrementais, como a Synergy de [Reed 00] uma vez que as versões do software oferecem uma maneira para que a empresa possa verificar os rendimentos do investimento que fez.


Programação em Par

[Williams 00] fez um ótimo trabalho estudando a Extreme Programming. Como relatado em experiência na Universidade de Utah (University of Utah) os programas escritos por indivíduos têm até 15% mais erros do que aqueles escritos em par.

Em um projeto real estes 15% significam um grande ganho com uma das fases, que pode ser a mais custosa do projeto: correção de erros.

Segundo [Yourdon 92], que segue estudos de J.C. Dickson, J. L. Hesse, A.C. Kientz e M.L. Shooman a maioria dos sistemas possui uma padrão constante para erros podendo estes terem custo significativo para o projeto e a equipe de desenvolvimento. Então, que quanto menor a quantidade de erros criados, melhor será visto o sistema pelos usuários e menos será o custo de desenvolvimento.

Seguindo esta filosofia, é vantagem trabalhar em pares, pois se evitando erros se ganha tempo para resolver o problema do negócio.

Design Evolucional

Nesta técnica o mesmo protótipo utilizado para apresentar o sistema ao cliente poderá ser utilizado para iniciar o desenvolvimento, desta forma a preocupação com layout de interface está separada da preocupação com codificação da lógica de negócio.

Outro ponto importante é a entrega de várias versões com pequenas melhorias sendo implementadas evolutivamente. Desta forma se o cliente não estiver satisfeito com uma funcionalidade poderá sinalizar para a equipe de desenvolvimento que não terá que varrer uma área muito grande de código para corrigir tal funcionalidade.

Constent Styile

Nesta técnica a equipe como um todo deve desenvolver um estilo próprio e comum a todos os membros. Para isso é necessário que todos conheçam a metodologia e se dediquem, torna-se imprescindível que todos conheçam e cumpram as técnicas e regras propostas pela metodologia XP, desta forma o desenvolvimento poderá acontecer de forma transparente e ágil.

Protótipo

Com a criação de um protótipo é mais rápido realizar a codificação pois todo o desenvolvimento é padronizado, além disso torna-se mais fácil testar pois o código é mais homogêneo e é de conhecimento de todos os membros da equipe de desenvolvimento.

O cliente pode entender melhor a solução do problema proposta pela equipe de desenvolvimento, inclusive o cliente pode verificar se o layout de interface proposto está bom ou não. Em resumo o cliente pode ver melhor como estarão arrumadas as funcionalidades do sistema.

Refactoring

Nesta técnica é importante que apenas os pares de membros da equipe que estão mais ambientados com a solução tecnológica adotada estejam envolvidos, pois se torna necessário que as novas soluções propostas, sejam consistentes, altamente padronizadas e não interfiram na lógica de negócio implementada.

Se a análise dos novos padrões a serem empregados for bem feita, estas novas soluções devem introduzir melhorias relacionadas à performance, legibilidade da lógica implementada, padronização e expansibilidade da funcionalidade proposta.

Desvantagens e Restrições

Diz-se, segundo [Astels 02], que uma das condições-limite da Extreme Programming é a quantidade de pessoas com que ela consegue lidar e, Segundo [Sucesu-SP] exige certa maturidade e vontade política, principalmente da alta direção.

É importante fazer o estudo das desvantagens e restrições da Extreme Programming para saber como contorná-las em um projeto real.

Restrições de Escalabilidade

(...) Quase sempre se assumiu que a XP [Extreme Programming] não poderia ir além do tamanho de uma única equipe de desenvolvimento com talvez seis a 12 pessoas. A verdade é que a XP [Extreme Programming] pode ser escalável e pode ser usada com grupos maiores. Assim como qualquer projeto grande de desenvolvimento de software, a organização e a comunicação se tornam importantes para a escalação bem-sucedida. [Astels 02]

Esta visão de [Astels 02]. Ele ainda expõe algumas destas técnicas para solução como a comunicação aberta e honesta e a integração.

Equipes, Planejemento e Versões

A colocação de Edson S. Gomi em [Sucesu-SP] cabe para identificar uma possível desvantagem de Extreme Programming no que diz respeito à equipe, planejamento e versões do software: a desvantagem da Extreme Programming é que ela “exige uma certa maturidade e vontade política de melhorar os processos de desenvolvimento, principalmente apoio da alta direção”.

Apoio e maturidade são fundamentais em Extreme Programming. A equipe de clientes tem que saber quais são seus direitos e limites. Um projeto não pode começar para resolver um problema e equipe de clientes querer que ele resolva uma dezena de outros. Os objetivos do projeto tem que ser bem definidos na visão geral do sistema. As equipes, bem como seus participantes, têm que saber seus direitos e deveres.

Extreme Programming depende muito do comprometimento e maturidade de uma equipe. O sucesso do planejamento e a adequação de cada versão do software disponibilizada é resultado do trabalho em conjunto para a solução de um problema. Se o trabalho não for focado, organizado e maduro o suficiente a Extreme Programming tente a não funcionar.

Programação em Par

Segundo [Williams 00] verificou que existe uma perda, para a programção em par, de aproximadamente 50% no tempo gasto pelo desenvolvedores para escrever algoritmos que solucionem um problema em relação a programação individual.

Esta perda de performance, no entanto é compensada, pelo menor em parte, por uma solução com menos erros mais legível e que facilita a posterior manutenção.

Design Evolucional

Ë importante que as versões liberadas para o cliente sejam muito bem controladas para que a equipe de desenvolvimento esteja sempre trabalhando em cima do código mais atualizado, pois por exemplo o cliente pode querer uma alteração ou correção em uma funcionalidade de uma versão do sistema que já está desatualizada, e na versão corrente em desenvolvimento esta os possíveis problemas já estão resolvidos.

Estilo Consistente

As equipes envolvidas, desenvolvimento e cliente, podem divergir entre si e internamente também pelo fato de não possuírem total conhecimento da metodologia extreme programming.

Outro ponto a ser considerado é a facilidade que os componentes de ambas as equipes tem de trabalhar em grupo, se as equipes não tiverem essa um forte comprometimento com o trabalho em equipe a metodologia pode ser prejudicada e ao invés de ajudar o desenvolvimento, este será retardado.

Protótipo

Por estar tendo uma visão inicial da cara do sistema o cliente pode perder o foco das funcionalidades e querer que a equipe se foque em detalhes irrelevantes da parte do layout de interface.

Ë importante que a equipe de desenvolvimento não deixe que o próprio protótipo não vire o sistema em si, isto é o protótipo desenvolvido é tão detalhado que parte das funcionalidades aparentam estar implementadas. Com isso perde-se tempo de desenvolvimento além de poder passar uma falsa imagem do sistema para o cliente.

Refactoring

Por ser uma atividade que demanda um alto conhecimento da plataforma tecnológica utilizada o refactoring pode acabar levando muito tempo para ser implementado. Ainda por este mesmo motivo, se a equipe envolvida não for devidamente qualificada problemas podem ser introduzidos no sistema.

Outra desvantagem do refactoring é a quantidade de tempo demandada por este período, este tempo tem que ser muito bem utilizado pois tempo precioso que poderia estar sendo utilizado no desenvolvimento está sendo investido nesta fase.

Conclusão

Existe um grande interesse na área de Extreme Programming, inclusive considerando o âmbito nacional. Verifique-se, por exemplo, [USP 02] que vem desenvolvendo projetos e estudos e [SBC 02] que realiza cursos na área de qualidade de software incluindo-se como tópico a Extreme Programming.

Existem, no entanto, alguns obstáculos a superar, podem-se citar, por exemplo, a divergência que pode ocorrer entre as equipes de programadores e clientes e também a resistência do cliente em disponibilizar uma equipe para estar participando de todo o processo de desenvolvimento durante todo o tempo.

Para que esta metodologia realmente obtenha sucesso há necessidade de que todos envolvidos no projeto conheçam suas técnicas e regras. A metodologia tem uma proposta interessante e moderna, que visa o sucesso mais rápido do desenvolvimento de um solução.

Observe-se ainda que os conceitos de Extreme Programming podem ser utilizados para fortalecer outras metodologias. Por exemplo, uma metodologia tradicional pode utilizar sua forma normal de planejamento mas incorporar o conceito de programação em par e versões de software.

Assim, Extreme Programming, serve para o profissional de informática tanto como metodologia completa como para fortalecer outros conceitos. Tendo uma abordagem extrema propõe resolver problemas antigos e novos de desenvolvimento de software que as metodologia mais tradicionais falharam em resolver.

Referências Bibliográficas

[Astels 02] ALVES, David. Extreme Programming; gruia prático / Dave Astels, Granville Miller, Miroslav Novak; tradução de Kátia Roque. Rio de Janeiro. Campus 2002.

[Carvalho 01] CARVALHO, Alexey. O capital intelectual das organizações. Publicado em 06/09/2001. Pode ser acessado na Internet via protocolo http em: http://www.widebiz.com.br/gente/alexey/capitalintelectual.html (Último acesso em 15/10/02).

[Coad 91] COAD, Peter e YOURDON, Edward. Análise Baseada Em Objetos.

[Houaiss 01] Houaiss. Dicionário Eletrônico da Língua Portuguesa. Dezembro de 2001.

[Kerievsky 02] KERIEVSKY, Joshua. Refactoring to Patterns. 2002. Pode ser acessado na Internet via protocolo http em: http://www.industriallogic.com/xp/refactoring/index.html (Último acesso em 15/10/02).

[Reed 00] REED, Paul R. Jr. Desenvolvendo Aplicativos com Visual Basic e UML. Makron Books, 2000.

[Romero 02] ROMERO, Alessandro Gerlinger. Adotando a Mudança. 2002. Pode ser acessado na Internet via protocolo http em: http://www.xpers.hpg.ig.com.br/artigos/AdotandoAMudanca.htm (Último acesso em 15/10/02).

[SBC 02] Sociedade Brasileira de Computação. Curso de Qualidade 2002. 2002. Pode ser acessado na Internet via protocolo http em: http://www.sbc.org.br/sbc2002/cursoqualidade.html (Último acesso em 15/10/02).

[Sucesusp-SP] SUCESU-SP, Eficácia em Gestão de Projetos: Seminário garante eficácia na obtenção de resultados dos projetos de software. Data Desconhecida. Pode ser acessado na Internet via protocolo http em: http://www.sucesusp.org.br/html/menuarti/entrevistas/entrevista_edson_gestao_projetos.html (Último acesso em 19/10/02).

[TV Cultura 02] TV Cultura. A importância das histórias no aprendizado das crianças. 2002. . Pode ser acessado na Internet via protocolo http em: http://www.tvcultura.com.br/aloescola/infantis/caillou/caillou_aprendizado.htm (Último acesso em 15/10/02).

[USP 02] Universidade de São Paulo. Programação Extrema. 2002. Pode ser acessado na Internet via protocolo http em: http://www.ime.usp.br/~xp/ (Último acesso em 16/10/02).

[Wells 99-1] WELLS, Don. User Stories. 1999. Tradução Livre. Pode ser acessado na Internet via protocolo http em: http://www.extremeprogramming.org/rules/userstories.html (Último acesso em 16/10/02).

[Wells 99-2] WELLS, Don. Release Planning. 1999. Tradução Livre. Pode ser acessado na Internet via protocolo http em: http://www.extremeprogramming.org/rules/planninggame.html (Último acesso em 16/10/02).

[Williams 00] WILLIAMS, Laurie. The Costs and Benefits of Pair Programming. 2000. Tradução Livre. Pode ser acessado na Internet via protocolo http em: http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm (Último acesso em 19/10/02).

[Yourdon 92] YOURDON, Edward. Projeto estruturado de sistemas /Edward Yourdon, Larry L. Constantine; tradução de CT Infomrmática. Rio de Janeiro. Campus, 1992.

 

Last Updated on Tuesday, 01 July 2008 15:09