eXtreming Programming

eXtreming Programming

eXtreming Programming

Os métodos ágeis estão cada vez mais a ser discutidos pelas empresas, sendo que muitas têm receio de adoptar esta metodologia, devido às dificuldades na reestruturação organizacional. Serão aqui discutidas características, alguns pontos fortes e fracos desta abordagem, quando deve ser escolhida, bem como os meios informáticos que ajudam à implementação da mesma. Ficará reforçado que este método tem aplicação prática e que ganhará vários adeptos nos próximos tempos. Este é, por excelência, o método para projetos de pequena e média dimensão para a Web, com cada vez mais empresas a apostar em criar ferramentas para a aplicação destes conceitos. Estas ferramentas têm de assentar no controlo do estado das tarefas e funcionalidades para determinada ‘release’ e na distribuição delas pelas equipas de trabalho. É também fundamental permitir que o cliente ajude de modo integrado com a aplicação a capturar requisitos para serem resolvidos pelas equipas de trabalho.

 

Os elementos relegados para segundo plano, não têm de deixar de existir, assumem sim, papéis menos importantes. As mudanças (por exemplo, ao nível da estrutura organizacional, da forma de pensar e trabalhar dos colaboradores) a que esta nova prática obriga, assustam os que veem nela uma alternativa para a evolução, e esta foi uma das principais razões pela qual a sua entrada no mercado foi lenta. Apesar de tudo, novos casos de estudo foram realizados e daí foram retiradas diversas recomendações para a sua introdução. É um engano pensar que, segundo esta metodologia que se abandona por completo os métodos tradicionais e as práticas de engenharia de software, até hoje adquiridas, no entanto o processo é transformado e certas fases são encurtadas e outras ganham mais relevo. Na próxima secção caracteriza-se a ‘Metodologia Ágil’, as suas características e definem-se os processos mais conhecidos que a suportam. Serão vistas também as vantagens e desvantagens, da metodologia ágil e explica-se resumidamente um método para a escolha entre ‘Metodologias Ágeis’ ou ‘Clássicas’ para um projeto.

 

De acordo com as linhas orientadoras da ‘Metodologia Ágil’, as pessoas têm um papel fundamental no desenvolvimento dos projetos, sendo para isso essencial que em todas as equipas exista uma boa comunicação entre os intervenientes, haja motivação e que cada indivíduo se preocupe com a qualidade. E valorizada a entrega de um produto funcional e adequado ao que o cliente realmente deseja; a preocupação centra-se na produção do software pedido, sendo a maioria da documentação gerada a partir das ferramentas usadas na produção. O cliente é frequentemente chamado a intervir, iteração a iteração, tendo um papel decisivo na definição dos novos requisitos, contrariando a prática de quase tudo ser planificado e acordado no início do projeto. É geralmente aceite, e muitas vezes é comprovado na prática, que numa ‘Metodologia Plan-driven/Waterfall’ o plano definido grande parte das vezes não chega ao fim igual ao que foi proposto no início do projeto. Nenhum projeto é totalmente previsível, portanto ser ‘ágil’ é ter conhecimento desta realidade e aceitar que os requisitos habitualmente mudam, em suma, estar pronto para acomodar a mudança de forma simples e rápida. Pretende-se então a redução dos ciclos de entrega, maior adaptabilidade e flexibilidade a alterações ou ao aparecimento de novos requisitos dos stakeholders, assim como o cumprimento dos prazos de entrega.

 

Os stakeholders e gestores de projetos tendem a ser mais exigentes e a querer reagir mais rapidamente ao mercado. Pretende-se então com este método um incremento da produtividade, uma conclusão mais rápida, uma entrada antecipada do projeto no mercado (pode não ser a sua versão final), retorno mais rápido do investimento, maior qualidade, menores custos e aumento da satisfação do consumidor. Os clientes são considerados parte da equipa de desenvolvimento, uma vez que a todo o momento são questionados sobre prioridades e testes de versões. A equipe de desenvolvimento inspeciona relatórios, define novas metas e atribui tarefas em iterações curtas, oferecendo ao cliente versões do software incrementalmente mais funcionais e melhoradas. Quer-se, portanto, que as aplicações vão ao encontro das necessidades reais de negócio. Não se entrega um grande projeto ao cliente que não foi por ele testado, e que só quando o vê se apercebe que não era bem aquilo que necessitava, apesar de este corresponder às especificações acordadas.

 

O XP usa uma abordagem orientada a objetos como seu paradigma de desenho. O processo é composto por quatro atividades: Planeamento, Projectos, Codificação e Teste, que são repetidas iteração a iteração. Planeamento: É criado pelo cliente, um conjunto de histórias que descrevem características e funcionalidades necessárias para o software a ser construído. Cada história dá entrada no sistema de controlo da metodologia e é indexada e o cliente atribui-lhe um valor de prioridade. Os membros da equipa analisam esta lista e atribui-lhe custos, se a história precisar de mais de três semanas, pede-se ao cliente que a dívida. Novas histórias podem ser adicionadas a qualquer momento. O próximo passo é a equipa em colaboração com o cliente decidir que histórias vão ficar prontas na próxima iteração e em que data. Projectos: A filosofia inerente é KIS (keep it simple), é desencorajado o desenvolvimento de uma funcionalidade extra, porque o programador developer acha que mais tarde deve ser precisa. Frequentemente geram-se protótipos, operacional de partes do projeto ou da totalidade. O XP encoraja a refrabricação, uma técnica de construção/projeto. (É o processo de alterar e aperfeiçoar o sistema de software interno, sem que se altere o comportamento externo.) Codificação: Antes do código, recomenda o processo, que se crie uma bateria de testes unitários para que a história fique satisfeita. Então o foco dos programadores é a satisfação destes testes unitários. Para a codificação o XP, recomenda que esta seja feita em pares. (Duas cabeças trabalham melhor do que uma), isto garante outros aspectos como qualidade, e rapidez (existe algum trabalho cientifico que comprava que o trabalhar em pares, não prejudica o rendimento, pelo contrário habitualmente consegue-se mais produtividade). Teste: Os testes unitários, são mantidos ao longo das várias iterações e passam a fazer parte de uma bateria de testes de regressão, que não é mais do que todos os testes unitários agrupados para serem testados periodicamente de uma vez em períodos curtos (pode ser de horas, ao final do dia, final da semana). A ideia é confirmar que nada deixou de funcionar.

Compartilhe esse artigo: