Quais são os cinco princípios dos métodos ágeis?

Metodologias Cl�ssicas (Tradicionais)

Tamb�m conhecidas como Metodologias orientadas a planejamento, as Metodologias Cl�ssicas dominaram a forma de desenvolvimento de softwares at� o in�cio da d�cada de 90, Entretanto, estas metodologias devem ser aplicadas apenas em situa��es em que os requisitos do sistema s�o est�veis e os requisitos futuros s�o previs�veis.

Metodologias ou Processos orientados a documenta��o s�o, de certa forma, barreiras impostas ao desenvolvimento, pois muitas organiza��es n�o possuem recursos para processos pesados de produ��o de software. Por esta raz�o, as organiza��es pequenas acabam por n�o usar nenhum processo. Isto pode trazer efeitos negativos no que diz respeito a qualidade do produto final, al�m de dificultar a entrega do software nos prazos, custos e funcionalidades previamente definidas.

Metodologias �geis e o Manifesto �gil

A express�o �Metodologias �geis� tornou-se conhecida em 2001, quando especialistas em processos de desenvolvimento de software representando entre outros, os m�todos Scrum e Extreme Programming (XP), foram estabelecidos princ�pios e caracter�sticas comuns destes m�todos. Assim foi criada a �Alian�a �gil� e efetuou-se o estabelecimento do �Manifesto �gil�.

Principais conceitos do Manifesto �gil

• Pessoas e intera��es, ao contr�rio de processos e ferramentas.
• Software execut�vel, ao contr�rio de documenta��o extensa e confusa.
• Colabora��o do cliente, ao contr�rio de constantes negocia��es de contratos.
• Respostas r�pidas para as mudan�as, ao contr�rio de seguir planos previamente definidos.

Extreme Programming (XP):

A Extreme Programming (XP) � uma Metodologia �gil para equipes pequenas e m�dias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Entre as principais diferen�as da XP em rela��o �s Metodologias Cl�ssicas est�o o feedback constante, a abordagem incremental e o encorajamento da comunica��o entre as pessoas.

A maioria das regras da XP causa surpresa no primeiro contato e muitas n�o fazem sentido se aplicadas isoladamente. � a for�a de seu conjunto que sustenta o sucesso da XP, trazendo uma verdadeira revolu��o no desenvolvimento de software.

O principal objetivo da XP � dar agilidade ao desenvolvimento do projeto e busca garantir a satisfa��o do cliente. As pr�ticas, regras, e os valores da XP garantem um agrad�vel ambiente de desenvolvimento de software para os seus seguidores, que s�o conduzidos por quatro princ�pios b�sicos:

• Princ�pio da Comunica��o - Busca manter o melhor relacionamento poss�vel entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunica��o.
• Princ�pio da Simplicidade - Entende-se como simplicidade, a busca do objetivo de implementar o software com o menor n�mero poss�vel de classes e m�todos. Outra ideia importante deste princ�pio � procurar implementar apenas requisitos atuais, evitando assim adicionar funcionalidades que podem ser importantes apenas no futuro. A aposta da XP � que � melhor fazer algo simples hoje do que implementar algo complicado hoje que talvez n�o venha a ser usado.
• Princ�pio do Feedback - A pr�tica do feedback constante significa que o desenvolvedor ter� informa��es constantes do c�digo e do cliente. A informa��o do c�digo � dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado.
• Princ�pio da Coragem - Sabe-se que n�o s�o todas as pessoas que possuem facilidade de comunica��o e t�m bom relacionamento interpessoal, este princ�pio tamb�m d� suporte � simplicidade, pois assim que a oportunidade de simplificar o software � percebida, a equipe pode experimentar e buscar novas solu��es, al�m disso, � preciso coragem para obter e cobrar constantemente um feedback do cliente.

Principais pr�ticas da Extreme Programming (XP):

• Planejamento - Define o que � ou n�o necess�rio ser feito no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, n�o em requisitos futuros.
• Entregas Frequentes - Baseiam-se no desenvolvimento de um software simples, e conforme os requisitos aparecem, h� a atualiza��o da vers�o do software. Cada vers�o entregue deve ter o menor tamanho poss�vel, contendo os requisitos de maior valor para o neg�cio. � recomendado que as vers�es devem ser entregues a cada m�s, ou no m�ximo a cada dois meses, aumentando a possibilidade de feedback r�pido do cliente.
• Met�fora - S�o as descri��es de um software sem a utiliza��o de termos t�cnicos com o objetivo de guiar o desenvolvimento do software com a maior transpar�ncia poss�vel para o cliente.
• Projeto simples - O software desenvolvido de acordo com a metodologia XP deve ser o mais simples poss�vel e satisfazer os requisitos atuais, sem a preocupa��o de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem.
• Testes - A Extreme Programming (XP) prioriza a valida��o do projeto durante todo o processo de desenvolvimento. Os desenvolvedores implementam o software criando primeiramente os testes.
• Programa��o em pares - A implementa��o do c�digo � feita em dupla, ou seja, dois desenvolvedores trabalham em um �nico computador. Procurando identificar erros sint�ticos e sem�nticos, pensando estrategicamente em como melhorar o c�digo que est� sendo implementado. Esses pap�is podem e devem ser alterados sempre que poss�vel.
• Refatora��o - Focaliza a lapida��o do projeto do software e est� presente em todas as etapas do desenvolvimento. A refatora��o deve ser feita sempre que poss�vel, buscando principalmente simplificar o c�digo atual sem perder nenhuma funcionalidade.
• Propriedade coletiva - O c�digo do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um c�digo, mesmo que ele pr�prio n�o o tenha desenvolvido, pode faz�-lo, desde que fa�a os testes necess�rios e n�o prejudique as funcionalidades atuais. Isto � poss�vel porque na XP todos s�o respons�veis pelo software. Uma grande vantagem desta pr�tica � que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto sem grandes dificuldades, pois todos conhecem todas as partes do software, mesmo que n�o seja de forma detalhada.
• Integra��o cont�nua - � a pr�tica de interagir e construir o sistema de software v�rias vezes por dia, mantendo os programadores em sintonia, al�m de possibilitar processos r�pidos. Integrar apenas um conjunto de modifica��es de cada vez � uma pr�tica que funciona bem porque fica �bvio quem deve fazer as corre��es quando os testes falham. Esta pr�tica � facilitada com o uso de apenas uma m�quina de integra��o, que deve ter livre acesso a todos os membros da equipe.
• 40 horas de trabalho semanal - A XP assume que n�o se deve fazer horas extras constantemente. Caso seja necess�rio trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema s�rio no projeto que deve ser resolvido n�o com aumento de horas trabalhadas, mas com melhor planejamento.
• Cliente presente - � fundamental a participa��o do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre dispon�vel para sanar todas as d�vidas de requisitos, evitando atrasos e at� mesmo constru��es erradas. Uma ideia interessante � manter o cliente como parte integrante da equipe de desenvolvimento (Tester).
• C�digo padr�o - Baseia-se na padroniza��o da arquitetura do c�digo, para que este possa ser compartilhado entre todos os programadores e at� mesmo entre outros softwares.

Saiba mais: Curso de eXtreme Programming

Confira outros conte�dos: