Já abordei aqui no blog vários post sobre “Como fazer uma monografia” e pretendo continuar com esta série de post por mais um bom tempo. No entanto, como estou atarefado e como muito material pronto sobre Extreme Programming, resolvi unir o útil ao agradavél e iniciar hoje no blog o primeiro post de uma série sobre o assunto.
Para os profissionais, acadêmicos e interessados na área de TI, segue o primeiro post da nova série do Neurônio 2.0
Segundo Pressman (2006), essa prática de projetar todo o sistema para só então implementar é obsoleta para o cenário atual. É praticamente impossível prever com antecedência todos os detalhes de um sistema, devido às condições mutáveis de mercado e a freqüente evolução das necessidades do usuário final.
Além disso, um dos problemas no desenvolvimento de software é a enorme quantidade de detalhes que precisam ser considerados. Segundo Beck (2000, apud CASTRO, 2007), o cliente tem o conhecimento de apenas alguns aspectos do software que ele deseja e só o passará a ter o restante depois de utilizar o sistema. Portanto, o cliente não especifica todos os detalhes no início do projeto pelo simples fato de ele mesmo não os conhecer. Além disso, mesmo que ele soubesse de todos os detalhes, especificá-los em documento seria muito difícil, devido à grande quantidade de elementos que precisariam ser descritos.
Para suprir essas e outras necessidades da Engenharia de Software, Kent Beck e outros dezesseis notáveis consultores se reuniram em 2001 e criaram um novo conceito de processo de software: o desenvolvimento ágil.
O desenvolvimento ágil é uma nova metodologia criada por profissionais renomados na engenharia de software, que só conseguiram maximizar os resultados pensando e trabalhando de forma muito diferente das descritas nos livros. Embora cada um tivesse suas próprias teorias sobre desenvolvimento de software, todos concordavam que as teorias tinham algo em comum. Foi dessa forma, que eles definiram um pequeno conjunto de princípios e criaram o Manifesto para o Desenvolvimento Ágil de Software, freqüentemente chamado apenas de Manifesto Ágil. (CASTRO, 2007).
Os princípios do Manifesto Ágil são:
- Indivíduos e interações em vez de processos e ferramentas;
- Software funcionando em vez de documentação abrangente;
- Colaboração do cliente em vez de negociação de contratos;
- Resposta a modificações em vez de seguir um plano.
De acordo com Viana (VIANA & DESCHAMPS, 2007), o Manifesto Ágil não descarta os processos, ferramentas, documentações, negociações e planejamentos, mas procura dar a esses itens um valor secundário diante dos indivíduos e interações, do bom funcionamento do software, da colaboração do cliente e das respostas velozes às modificações.
Pressman (2006) afirma que o desenvolvimento ágil requer a utilização de pequenos e constantes incrementos de software, e para isso, necessita que o feedback do cliente seja o mais rápido possível.
[…] Um catalisador efetivo para o feedback do cliente é um protótipo operacional ou uma porção do sistema operacional. Assim, uma estratégia de desenvolvimento incremental deve ser instituída. […] Essa abordagem iterativa habilita o cliente a avaliar o incremento de software regularmente, fornecer o feedback necessário à equipe de software e influenciar as adaptações do processo feitas para acomodar o feedback […] (PRESSMAN, 2006, p. 61).
Com efeito, é possível notar nas afirmações de Pressman que a metodologia ágil mescla alguns processos das metodologias de Incremento e Prototipagem oriundos dos modelos tradicionais.
Segundo Fowler (2007, apud BORBOREMA, 2007), as duas principais diferenças entre as metodologias ágeis e as tradicionais são:
- Adaptativas, ao invés de previsivas – as metodologias tradicionais são resistentes a mudanças devido à excedente documentação feita com antecedência. Em contrapartida, as metodologias ágeis conseguem ser mais flexíveis, pois ajustam seus requisitos durante o desenvolvimento do software.
- Orientadas às pessoas, não aos processos – as metodologia ágeis não possuem processos rígidos que impõem o que as equipes devem ou não fazer. Muito pelo contrário, a equipe é estimulada a se envolver diretamente com o cliente e toma as decisões necessárias para melhor ajustar a equipe.
Leia também o próximo dessa série “XP – Extreme Programming“