Metodologias ágeis De Desenvolvimento

Metodologias Ágeis de Desenvolvimento

Neste capítulo, serão abordados não apenas o cenário atual do mercado de software, como também a introdução dos conceitos referentes a Metodologias Ágeis, procurando mostrar suas principais caracterísiticas e contrastes com as metodologias tradicionais.

Na seção 2.1 encontra-se uma descrição das metodologias tradicionais de software e os desafios que esta vem encontrando. A seção 2.2 descreve como surgiu o manifesto ágil e os valores adotados pelo mesmo. A seção 2.3 define Metodologia Ágil e os princípios adotados por tal metodologia. As seções 2.4, 2.5 e 2.6 descrevem respectivamente as seguintes metodologias ágeis: Scrum, Crystal e DSDM.

2.1 Visão Tradicional da Engenharia de Software

A área de Engenharia de Software vem enfrentando há muito tempo problemas relativos a atraso na entrega de projetos, orçamento extrapolado, insatisfação de clientes e usuários, além de conflitos e desgastes entre analistas e clientes. Com o objetivo de obter melhores resultados, as empresas de TIC estão adotando metodologias de desenvolvimento de software mais flexíveis e propícias às freqüentes mudanças, além de mais interação durante todo o projeto entre os usuários e o próprio sistema. Estas metodologias são chamadas de ágeis em contraposição às metodologias pesadas que, tradicionalmente, predominaram na área, mas que se mostraram ineficientes e improdutivas.

Os métodos tradicionais de engenharia, também conhecidos como métodos pesados, possuem em comum o fato de serem um processo descendente, que parte de uma lista de requisitos de um produto, progressivamente concretizado ao longo do processo de desenvolvimento do produto. Mesmo os reajustes, nos momentos de iteração e de avaliação, são correções de percurso em função de um objetivo pré-determinado, não influenciando de modo significativo o escopo inicial. A distância entre o produto oferecido e as necessidades reais dos clientes e usuários, verificada na prática, coloca em questão a eficácia desse processo seqüencial. Ainda que esta seqüência seja quebrada em vários ciclos iterativos, o procedimento permanece descendente, partindo do modelo conceitual para os detalhes das situações de uso.

As metodologias tradicionais ainda são muito utilizadas nos projetos de desenvolvimento de software, sendo caracterizadas pela separação bem rígida das fases de projeto, que consistem em: Levantamento de Requisitos, Análise, Design, Implementação, Testes e Implantação e Manutenção [1]. Cada fase tem suas especificidades e possuem entre si interdependência, isto é, a próxima fase só começa quando a anterior estiver pronta. Isto significa que o processo é seqüencial e linear, no qual cada fase deve ser concluída antes de passar para a próxima etapa.

Figura 2.1 - Desenvolvimento utilizando metodologia tradicional [1]

O problema do uso dessas metodologias é sua inflexível divisão do projeto em fases distintas, o que dificulta possíveis alterações que são comuns no desenvolvimento de um projeto. Sendo assim, quanto mais imprevistos surgirem, maior será o retrabalho e, conseqüentemente o tempo de realização do projeto, uma vez que uma modificação no escopo do projeto acarreta mudanças estruturais muitas vezes complexas e impactantes para o desenvolvimento do sistema, comprometendo assim os prazos, o preço e qualidade do serviço. O custo das alterações cresce exponencialmente, à medida que o processo de desenvolvimento avança, situação que pode ser visualizada na Figura 2.2.

Figura 2.2 - Custo de mudanças nos projetos que utilizam metodologia tradicional [2]

As metodologias pesadas devem ser aplicadas apenas em situações em que os requisitos do software são estáveis e requisitos futuros são previsíveis. Estas situações são difíceis de serem obtidas, uma vez que os requisitos para o desenvolvimento de um software são mutáveis.

Figura 2.3 - Custo de mudanças no projetos que utilizam metodologias ágeis[2]

Como as alterações em requisitos são comuns, e as metodologias ágeis apoiam que mudanças sejam efetuadas nos requisitos sempre quando necessárias, considerando-as como a única forma de entregar ao cliente o produto que ele precisa, o gráfico da Figura 2.3 (curva ideal) apresenta o custo de mudanças no projeto , o qual não cresce muito, mesmo quando alterações são feitas em fases avançadas do desenvolvimento.

2.2 O Manifesto para o Desenvolvimento Ágil de Software

Como uma reação às metodologias tradicionais, um grupo de profissionais da área de engenharia de software decidiu se reunir para discutir práticas e teorias sobre como fazer o projeto de software ter sucesso[2]. Todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, frequentemente chamado apenas de Manifesto Ágil, o qual é definido por quatro simples declarações de valores, definindo preferências, não alternativas, encorajando o enfoque de certas áreas, mas sem limitar outras. Os valores do manifesto ágil são:

 Indivíduos e interações valem mais que processos e ferramentas

Os fatores mais importantes a considerar são as pessoas e como elas trabalham juntas.

 Um software funcionando vale mais que documentação intensa

A documentação tem seu lugar, escrita de maneira correta é um guia importante para as pessoas entenderem como e porque o sistema é construído e como trabalhar com ele. Entretanto, o objetivo principal do desenvolvimento de softwares é criar softwares, não documentos.

 A colaboração do cliente vale mais que a negociação de contrato

Trabalhar junto com os clientes é difícil, mas é a realidade do trabalho. Apenas o cliente pode dizer o que quer, e eles provavelmente mudarão de idéia.

 Responder a mudanças vale mais que seguir um plano

As pessoas mudam de idéia com frequência. À medida que o trabalho no sistema progride, muda a compreensão dos clientes sobre o domínio do problema e sobre o que você está construindo. A mudança é uma realidade no desenvolvimento