Metodologias Ágeis

Metodologias Ágeis

Diversas metodologias foram criadas para sistematizar o desenvolvimento de software. Essas metodologias podem ser divididas em tradicionais, que enfatizam a documentação de cada passo do desenvolvimento do software, ou ágeis, que consideram um paradigma novo de desenvolvimento de software.

Comparativo entre Metodologias:

Tradicional:

Também chamada de pesada ou orientada a documentação. Estas metodologias surgiram em um contexto mais antigo. Considerando que antigamente, quando mainframes reinavam e não existiam ferramentas de apoio ao desenvolvimento, o custo de realizar algum tipo de alteração era altíssimo, a documentação tinha de ser muito mais forte.

Modelo Clássico:

Segundo Pressman, foi a primeira metodologia publicada sobre desenvolvimento de software. O modelo estabelece uma seqüência de etapas. Cada etapa tem um início e um fim definidos com documentação rígida a ser seguida entre uma etapa e outra, de forma que sem a documentação o processo não avança. O exemplo clássico deste modelo é chamado Cascata.

O modelo em espiral também é um modelo clássico, porém, de forma diferente do modelo em cascata permite retorno a fases anteriores.

A mudança:

O modelo clássico foi praticamente o único até o início da década de 1990, nesta década passaram a surgir vários trabalhos colocando em xeque a validade deste modelo. Percebeu-se nesta época que o modelo clássico ocultava uma série de problemas sérios como:

–        Problema para entrega de no prazo considerando o escopo de todas as funcionalidades solicitadas. [Standish Group, 1995].

–        Grande número de erros dado que a metodologia clássica dificulta a execução de alterações durante o processo de desenvolvimento.

–        Um artigo famoso da época. “No Silver Bullet”, de Brooks [1987], demonstrou que a idéia de especificar totalmente o software antes de seu início é totalmente impossível.

Metodologia Ágil

A metodologia ágil é muito adequada para situações em que a mudança de requisitos é freqüente, ou seja, para ser ágil, a metodologia deve aceita a mudança em vez de tentar prever o futuro.

O termo ágil surgiu em 2001, quando 17 especialistas em processos de desenvolvimento de software representando várias tendências da época estabeleceram as premissas de um manifesto para o desenvolvimento ágil. Seguem as definições deste manifesto:

–        Indivíduos e interações em vez de processos e ferramentas;

–        Software executável em vez de documentação;

–        Colaboração do Cliente ao invés de negociação de contratos;

–        Respostas rápidas a mudanças em vez de seguir planos.

Extreme Programming ou XP

É uma metodologia ágil para equipes pequenas, que desenvolvem software baseado em requisitos não muito bem definidos e que são modificados rapidamente.

Pontos chaves com relação a esta prática:

–        Feedback constante;

–        Abordagem incremental;

–        A comunicação entre as pessoas é encorajada.

São ao todo 12 práticas: Planejamento, Entregas freqüentes, Metáfora, Testes, Projeto Simples,  Programação em Pares, Testes, Refatoração, Propriedade Coletiva, Integração Contínua, Trabalho semanal de 40 horas, Cliente Presente e Código Padrão.

1.    Planejamento: consiste em decidir o que é necessário fazer e o que pode ser adiado no projeto. Baseado nos requisitos reais, não em possíveis requisitos futuros os analistas de negócio decidem sobre escopo, composição de versões,  e datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, processo de desenvolvimento e cronograma detalhado para que o software seja entregue na data especificada.

2.    Entregas Freqüentes: esta prática versa sobre a entrega de um software simples, atualizado à medida que novos requisitos surgem.

3.    Metáfora: Descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento do software.

4.    Projeto Simples: O programa deve ser o mais simples possível e satisfazer aos requisitos atuais, sem a preocupação de requisitos futuros.

5.    Testes: Focaliza a validação do projeto durante todo o processo de desenvolvimento. Programadores desenvolvem o software criando primeiro os casos de testes.

6.    Programação em Pares: implementação do código feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador. Um implementa o código, enquanto outro observa continuamente o trabalho que está sendo feito. Este tipo de programação traz a vantagem de que os programadores aprendam, uns com os outros além, obviamente, de diminuir o número de erros no código, dado que duas pessoas estão preocupadas com a sua implementação.

7.   Refatoração: focaliza o aperfeiçoamento do projeto do software e está presente em todo o desenvolvimento, a refatoração deve ser feita sempre que for possível simplificar uma parte do software.

8.    Propriedade Coletiva: o código do projeto pertence a todos os membros da equipe. Isto flexibiliza o desenvolvimento pois todos estão capacitados a contribuir, e diminui a dependência de um programador específico.

9.    Integração Contínua: sempre que testado e validado o código deve ser prontamente integrado ao sistema, e este também deve ser testado. Desta forma é mais fácil isolar erros e suas causas.

10. Trabalho Semanal de 40 Horas: Não se deve trabalhar mais que 40 horas semanais no projeto. Caso isto ocorra por mais de duas semanas consecutivas, é sinal que o projeto tem algum problema e deve ter revisto. Esta prática prioriza pessoas como foco e não o processo.

11. Cliente Presente: Fundamental a participação do cliente durante todo o projeto. O cliente deve estar sempre disponível para sanar dúvidas sobre requisitos, evitando assim, atrasos e construções errôneas.

12. Código-Padrão: Recomenda-se a adoção de regras de escrita, como formato de comentários e uso de identificadores, favorecendo assim o trabalho em equipe e a propriedade coletiva do código.

SCRUM

Outra metodologia ágil muito conhecida. Seu objetivo é fornecer um processo conveniente para um projeto de desenvolvimento orientado à objeto. O foco principal da metodologia é produzir o software de forma flexível e em um ambiente de constante mudança. Parecido com o XP o SCRUM divide o desenvolvimento em ciclos interativos, ou “sprints” de até trinta dias. Estes ciclos são ou sprints são atendidos por equipes de analistas previamente definidos no início de cada ciclo.

Existem três fases principais:

1.    Pré-planejamento: os requisitos são definidos em um documento, posteriormente são ordenados por prioridade, e realiza-se para cada um um estudo de esforço e custo além de equipe de desenvolvimento envolvida. Esta fase é concluída com a proposta de arquitetura de desenvolvimento. Devem ser identificadas eventuais alterações nos requisitos assim como possíveis riscos.

2.    Desenvolvimento: Nesta fase o software é desenvolvido em ciclos(“sprints”) que duram entre uma semana e um mês.

3.    Pós-planejamento: faz-se a integração do software, os testes finais e a documentação do usuário. A equipe reúne-se para analisar o progresso do projeto e demonstrar o software para os clientes.

Concluindo…

Obviamente que muito mais pode ser dito, as metodologias ágeis estão ainda em uma fase de evolução e desenvolvimento, mas já são colhidos grandes resultados.

Um exemplo claro é o da Boeing, onde foi inicialmente adotado o modelo XP e, com o passar dos anos, a empresa adotou o sistema tradicional CMM. Segundo dados da empresa, não foi necessária uma grande mudança para atingir o nível mais alto do CMM (5) dado que o processo formal estava instituído [Abrahamsson et al., 2002].

Referências:

Koscianski, André, Qualidade de Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software, São Paulo, Novatec Editora, 2007.

Standish Group, CHAOS report. Dennis, MA 02638, USA,1995.

Brooks F. No Silver Bullet: Essence and Accidents of Software Engeneeringe. Computer 20(4):10-19,1987.

Pressman RS. Engenharia de Software. McGraw Hill, 2002.

Abrhamsson P, Salo O, Ronkainen J. Agile Software Development Methodes – Review and Analysis. VTT, 2002.

»crosslinked«

Mauricio Antonio Ferste

Graduação em Bacharelado em Informática pela Universidade Federal do Paraná (1997) e mestrado em Engenharia Elétrica e Informática Industrial pela Universidade Tecnológica Federal do Paraná (2006). Tem experiência na área de Ciência da Computação, com ênfase em Sistemas de Informação. Atualmente funcionário do SERPRO (www.serpro.gov.br), atua no desenvolvimento de sistemas. Professor atuante na FAMEC (http://www.famec.com.br), no curso de Bacharelado em Sistemas de Informação (Curriculum Lattes: http://lattes.cnpq.br/9368615800123473).

Você pode gostar...

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *