Você está na página 1de 6

Metodologias geis 1. Introduo Existem diversas metodologias criadas para estruturar o desenvolvimento de software.

Elas podem ser divididas em tradicionais ou geis dependendo da nfase que do documentao de cada passo ou novas abordagens, respectivamente. Uma metodologia de desenvolvimento , naturalmente, um conjunto de atividades cujo objetivo auxiliar na produo de software. O produto reflete o mtodo utilizado. Embora exista vasta literatura e experincias amargas pelo universo de TI sobre os malefcios da ausncia de mtodos, o que ocorre, de fato, que s vezes os processos no so adequados s empresas, principalmente s mdias e pequenas, que no so capazes de gerir metodologias pesadas de documentao. As denominadas metodologias tradicionais remontam a um perodo e um contexto muito diferente de desenvolvimento, onde os recursos eram mnimos e os cdigos necessitavam de planejamento e documentao extremamente concisos lembremos dos mainframes do passado, sem as ferramentas que nos so disponveis hoje, como, depuradores e analisadores de cdigo. As metodologias geis, por sua vez, propem novas abordagens, conforme veremos a seguir. 2. Definies Metodologias geis so adequadas situaes onde h modificao freqente dos requisitos. Uma metodologia tipicamente gil quando, ao invs de tentar prever o futuro, aceita as mudanas dispostas. As metodologias geis tendem a ter um menor custo de mudanas progressivas que as metodologias clssicas, conforme podemos verificar no grfico abaixo, comparativo de uma tcnica tradicional (o bem conhecido modelo em cascata) e XP (Extreme Programming).

O termo Metodologias geis tem origem no ano de 2001, quando alguns especialistas de diferentes tcnicas estabeleceram princpios comuns. Embora as metodologias sejam divergentes quanto prtica e nfase, os princpios compartilhados definem seu esqueleto. Vejamo-los: Desenvolvimento interativo e incremental Comunicao Reduo de produtos intermedirios (como documentao extensiva)

Os conceitos-chave do Manifesto gil (fruto da supracitada reunio de especialistas) so: Indivduos e interaes, em vez de processos e ferramentas. Software executvel, em vez de documentao. Colaborao dos clientes, ao invs de negociao de contratos. Respostas rpidas a mudanas, em vez de seguir planos.

O Manifesto gil no rejeita processos, ferramentas, planejamento, documentao, etc. Apenas, define que tais caractersticas tm um lugar secundrio, se comparadas aos conceitos-chave. Conceitos esses que se aproximam melhor do modus operandi de pequenas e mdias empresas. As metodologias geis mais conhecidas so Extreme Programming e Scrum. 3. Metodologias mais comuns 3.1 Extreme Programming Focada em equipes pequenas ou mdias, cujo desenvolvimento se baseia em requisitos vagos e rapidamente modificveis. Algumas das principais diferenas entre a XP e as demais linhas so: Feedback constante. Abordagem incremental. A comunicao entre as pessoas encorajada.

As prticas da XP, em sua maioria, no fazem sentido se tomadas isoladamente. o conjunto que se torna poderoso.

Quatro valores definem a XP, do ponto de vista da equipe de desenvolvimento: comunicao, simplicidade, feedback e coragem. Ela enfatiza o desenvolvimento rpido do projeto e visa garantir a satisfao do cliente, alm de favorecer, ou tender a, o cumprimento das estimativas. Por comunicao, entenda-se o estmulo ao contato com o cliente, mantendo um relacionamento tanto melhor quanto possvel, focando conversas pessoais, preferencialmente. A comunicao entre desenvolvedores e gerente de projeto tambm estimulada. Por simplicidade, a metodologia XP compreende a criao de um cdigo enxuto, sem funcionalidades desnecessrias, isto , cuja utilizao no definida como importante seno para o futuro. Um cdigo simples consistiria ento naquele com menor nmero possvel de componentes, como classes e mtodos. O feedback constante consiste no fato de que o programador ter informaes constantes sobre o cdigo e o cliente. Em relao ao primeiro, o feedback surge dos testes constantemente aplicados, indicando erros individuais e integrados. Quanto ao ltimo, implica no fato de que o cliente ter sempre em mos partes do software funcionais, para avaliao. Esse tipo de abordagem permite que o cliente indique eventuais erros e inconformidades, bem como sugira acrscimos que sinta necessrios. Existem , naturalmente, aspectos desafiadores na implementao dessas caractersticas, por exemplo: 1. Nem todas as pessoas tm facilidade de comunicao e relacionamento. 2. Pedir a um cliente que avalie um software, pode consistir numa enxurrada de novas solicitaes e adendos. Contudo, estando esses aspectos dentro de controle, a simplicidade do mtodo costuma ser bastante atrativa equipe. 3.1.2 Prticas da XP A XP baseia-se em doze prticas, recomendadas a serem aplicadas gradativamente: Planejamento: decidir o que necessrio e o que adivel. A XP, conforme explicado anteriormente, no enfoca requisitos importantes apenas para o futuro. Tambm aborda a cooperao entre as reas de negcio e desenvolvimento, definindo suas atividades. Entregas freqentes: desenvolvimento de software simples, constantemente atualizados e levados ao cliente para avaliao. A simplicidade e ausncia de grandes modificaes (cada verso deve ter o menor tamanho possvel) visa a proteo contra a necessidade de ter que fazer grandes modificaes. Metfora: descries de um software sem utilizao de termos tcnicos. Visa guiar o desenvolvimento.

Projeto simples: preocupao com que ser utilizado hoje. Deixar o futuro para o prprio futuro, em palavras simples. Testes: validao do projeto durante todo o processo de desenvolvimento. Primeiramente, so criados os casos de testes. Programao em pares: dois desenvolvedores trabalhando num nico computador.Um implementa o software enquanto o outro observa o trabalho, buscando erros e pensando como o cdigo pode ser melhorado. Esses papis devem ser invertidos. As revises so feitas durante a implementao e existe ainda a possibilidade de um desenvolvedor aprender com o outro. Refatorao: deve ser feita sempre que for possvel simplificar uma parte do software, sem a perda de funcionalidades. Est presente em todo o projeto. Propriedade coletiva: o cdigo do projeto pertence a todos os membros da equipe e todos podem alter-lo, desde que fazendo as baterias de testes necessrias. Diminui a dependncia de um programador que possivelmente desfalque a equipe. Integrao contnua: aps um cdigo ser testado e validado, deve ser integrado e testado novamente. Assim, fica mais fcil isolar erros e o processo de verificao sempre gradativo. Trabalho semanal de 40 horas: caso um projeto necessite de horas extras por duas semanas, provavelmente ele tem um problema. O objetivo focar nas pessoas e assumir que no se deve fazer horas extras constantemente. Os planos devem ser alterados, em vez de sobrecarregar as pessoas. Cliente presente: o cliente deve estar presente durante o processo e disponvel para sanar dvidas de requisitos. Isto evita principalmente construes errneas. Cdigo-padro: recomenda-se o uso de regras de escrita. A padronizao favorece o trabalho em equipe a propriedade comum do cdigo.

3.1.3 Planejamento na XP Os clientes, ativos no processo de desenvolvimento, descrevem as histrias de usurio. Divide-se, normalmente, essa histria em tarefas. As menores devem ser agrupadas e as maiores, divididas. Essa histria de usurio deve durar trs semanas em mdia, para que seja entregue um software composto por ms. A ltima semana pode servir para refactoring, testes ou mesmo prosseguir com o desenvolvimento. A descrio das histrias deve ser feita em alto nvel, caso seja feita por algum da equipe tcnica, evitando termos de tecnologia, algoritmos, etc. O acompanhamento deve ser constante, dirio at, observando-se definies de status constantemente atualizadas para cada tarefa.

3.1 Scrum Seu objetivo fornecer um processo interessante para projeto e desenvolvimento orientado a objeto. Aplica algumas idias de controle de processos industriais. Introduz idias de flexibilidade, adaptabilidade e produtividade. Busca encontrar uma forma de trabalho dos membros da equipe para produzir de forma flexvel num ambiente de constante mudana. Visa tratar mudanas freqentes, tais como: trocas de equipes, adaptaes de cronogramas e oramento, trocas de ferramentas e mesmo de linguagens de programao. Os princpios so semelhantes aos da XP. A Scrum, contudo, divide o desenvolvimento em ciclos iterativos (Sprints) de at trinta dias. Equipes de at dez pessoas trabalham em funcionalidades definidas no incio de cada sprint, entre projetistas, programadores, engenheiros e gerentes de qualidade. Reunies de acompanhamento dirio, de mais ou menos quinze minutos, so realizadas a fim de que problemas sejam tratados de imediato, sem adiamentos. Todos se pem a par do que foi feito e do que se necessita fazer at dado prazo. O ciclo de vida da Scrum baseado em trs fases principais, divididas em subfases: Pr-planejamento (pr-game phase): os requisitos so descritos num documento denominado backlog e so ento ordenados por prioridade. So feitas estimativas de esforo para o desenvolvimento de cada um deles e definidas as ferramentas, os riscos, as necessidades de treinamento at a arquitetura, por fim. As eventuais alteraes so escritas no backlog. Desenvolvimento (game phase): o software desenvolvido em ciclos (sprints), onde novas funcionalidades so adicionadas. Cada um desses ciclos segue a forma tradicional: anlise, projeto e implementao. Variam entre uma e trs semanas. Ps-planejamento (post-game phase): fazem-se a integrao, testes finais e documentao de usurio. A equipe reunida analisa o progresso projeto e o demonstra para os clientes.

4. Resultados do Uso de Metodologias geis Embora as metodologias geis sejam ainda recentes, resultados positivos j foram demonstrados. Projetos utilizando esse tipo de metodologia mostraram-se melhores em termos de cumprimento de prazos, custos e padres de qualidade. A utilizao da XP, por exemplo, traz vantagens em projetos onde os clientes no sabem definitivamente o que querem e podem mudar de opinio durante o tempo. Outro ponto

positivo so as entregas freqentes de software. O cliente no aguarda longos perodos para conhecer o produto. Observando-se o lado dos problemas, muitos vem na XP um retorno ao processo desordenado de desenvolvimento e a informalidade no levantamento de requisitos pode, por um lado ser mal vista pelo cliente e por outro inibir velhas e boas prticas de desenvolvimento, como, por exemplo, o uso de diagramas. O desafio dessas metodologias , eliminar seus pontos fracos sem se tornarem pesadas e desenvolverem um mtodo para serem utilizadas em grandes empresas, com grandes equipes (separao geogrfica). Ainda faltam tambm, casos de sucesso em projetos grandes e crticos, para avaliar suas vantagens. Contudo, os resultados iniciais quanto qualidade, confiana, datas de entrega e custo so promissores.