Desenvolvimento de Software Utilizando Metodologias geis

Andrea M. Freire1, Alexandre C. Malaquias2, Diego Trindade3, Rogrio Pacheco4

1

Curso de Bacharelado em Informtica - Universidade Catlica do Salvador (UCSAL) dekafreire@gmail.com Curso de Bacharelado em Informtica - Universidade Catlica do Salvador (UCSAL) alexandre.malaquias@bol.com.br Curso de Bacharelado em Informtica - Universidade Catlica do Salvador (UCSAL) diego.trindade95@gmail.com Curso de Bacharelado em Informtica - Universidade Catlica do Salvador (UCSAL) rogeriopacheco@gmail.com

Abstract. This article aims to present the use of the Agile software development, explaining their practices, defining papers and addressing two of the most commonly used methodologies: Extreme Programming and Scrum. Keywords: Agile methodologies, practices, papers, Extreme Programming, Scrum. Resumo. Este artigo tem como finalidade apresentar o uso das Metodologias geis no desenvolvimento de softwares, explicando as suas prticas, definindo papeis e abordando duas das suas metodologias mais usadas: o Extreme Programming e o Scrum. Palavras Chaves: Metodologias Programming, Scrum. geis, Prticas, Papeis, Extreme

1. Introduo
No desenvolvimento de software, as metodologias tradicionais, mais conhecidas como Modelo em Cascata, Modelo em Espiral e Modelo Iterativo, tm em comum o fato de dificultarem quaisquer alteraes nos requisitos de um projeto j em andamento. Isto porque as suas etapas no podem ser realizadas em paralelo, ou seja, uma etapa s pode ser iniciada aps o trmino da outra. No Modelo em Cascata, as etapas de desenvolvimento, formadas por requerimento, projeto, implementao, verificao e manuteno, so seqenciais e inflexveis, onde o cliente s poder realizar validaes depois do software pronto. No Modelo em Espiral, o software dividido em verses chamadas de incremento. Cada incremento ir passar por quatro atividades principais: definio dos objetivos, anlise de riscos, desenvolvimento e validao/teste/planejamento do prximo

incremento. Este modelo permite uma validao de maneira mais fcil j que o cliente acompanha o processo de desenvolvimento. No Modelo Iterativo, o software passa por vrios ciclos de desenvolvimento. Cada ciclo realiza um incremento em sua construo. O trabalho torna-se mais eficiente, pois a equipe permanece focada nos objetivos de cada um dos incrementos. Ao final do projeto de software, um dos problemas que podem vir a ocorrer no uso destas metodologias tradicionais o produto final no atender mais s necessidades do cliente por causa de possveis mudanas no ambiente externo. Diferente dos mtodos tradicionais, os Mtodos geis surgem para propor um projeto de software baseado na colaborao do trabalho em equipe com capacidade de adaptarse totalmente a mudanas.

2. Surgimento da Metodologia gil

Em 2001 ocorreu a popularizao do termo Mtodos geis quando um grupo formado por dezessete especialistas em desenvolvimento de software se reuniu para compartilhar suas experincias. Este grupo era composto por Ward Cunningham, Steve Mellor, Ron Jeffries, Robert C. Martin, Mike Beedle, Martin Fowler, Kent Beck, Ken Schwaber, Jon Kern, Jim Highsmith, Jeff Sutherland, James Grenni, Dave Thomas, Brian Marick, Arie Van Bennekum, Andrew Hunt e Alistair Cockburn. Eles tinham em comum o fato de terem vivenciado vrios casos de projetos de software sem xito. Isto ocorria devido criao de softwares cada vez mais complexos, a falta de habilidade do cliente em apresentar claramente as suas necessidades, os requisitos que nunca se repetiam a cada novo projeto e o emprego de tcnicas que dificultavam alteraes no projeto sem que para isso fosse necessrio aumentar o seu custo. Todos concordavam em estabelecer um novo paradigma de desenvolvimento de software que pudesse realizar tantas alteraes quanto fossem necessrias. E que isso ocorresse de forma rpida e que mantivesse a qualidade do software. De acordo com estes princpios, o grupo desenvolveu o chamado Manifesto gil. Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo (www.agilemanifesto.org) O Manifesto gil consiste em um documento que prope o desenvolvimento de software baseado nos seguintes fundamentos: Indivduos e iteraes so mais importantes do que processos e ferramentas. Software funcionando mais importante do que negociao de contratos. Adaptao a mudanas mais importante do que seguir o plano inicial. Garantir a satisfao do cliente atravs da entrega rpida e contnua de softwares funcionais. Aceitar mudanas nos requisitos, mesmo no fim do desenvolvimento, permitindo ao cliente conquistar vantagens competitivas.

Entregar softwares funcionais com frequncia, de preferncia em semanas e no meses. Deve haver cooperao constante entre as pessoas que conhecem o negcio e os desenvolvedores durante todo o projeto. Software funcional a medida primria de progresso. Construo de projetos por indivduos motivados, que tenham uma relao de confiana. Transmitir informaes com conversas presenciais, cara a cara, mais eficiente do que as documentaes. Uma contnua ateno a excelncia tcnica e ao bom designer do software, aumenta a agilidade. Simplicidade.

3. Ambiente de Desenvolvimento gil

Na Metodologia gil teremos o software subdividido em pequenas verses que devem ser construdas com durao de uma a quatro semanas. Cada verso ir passar por cada uma das etapas de desenvolvimento, indo da especificao at chegar fase final de testes. Esta diviso do software em pequenas verses ocorre no intuito de entregar ao cliente pequenos mdulos do sistema para validao, e com isso reduzir possveis erros. recomendado que toda a equipe seja alocada fisicamente em um mesmo ambiente, facilitando a comunicao cara a cara. Inclusive faz-se necessrio que um representante do cliente tambm esteja neste ambiente visando esclarecer dvidas quem venham a surgir durante o processo. A equipe deve ser formada por poucos profissionais, experientes, com especialidades diferentes, capazes de se auto-organizar estabelecendo cronogramas e de se adequarem ao processo, onde todos precisam se focar no mesmo objetivo. Seu uso mais indicado nos casos em que os requisitos sofram constantes mudanas, como por exemplo, as aplicaes desenvolvidas para a web.

4. Comparao entre Metodologias geis e Tradicionais

De acordo com o que foi exposto, podemos distinguir caractersticas distintas entre as Metodologias geis e Tradicionais. Uma breve comparao entre elas pode ser visualizada conforme a Tabela 1:
Tabela 1: Comparao entre Metodologias geis e Tradicionais.

Metodologia gil Durao de uma a quatro semanas. Adaptvel a mudanas externas. Documentao do que for necessrio ao cliente.

Metodologia Tradicional Durao de vrios meses. Inflexvel e previsvel. Documentao em excesso.

Formado por ciclos ou iteraes. Foco nas pessoas. Prioriza a entrega de softwares funcionais em curtos prazos. Ao final de cada etapa gerada uma verso do produto que j pode ser entregue ao cliente.

Formado por etapas seqenciais e bem definidas. Foco nos processos. Prioriza toda a seqncia do desenvolvimento que vai do Planejamento at a etapa final de Testes. Ao final de cada etapa gerada uma documentao.

5. Exemplos de Metodologias geis

Alguns exemplos de Metodologias geis so: Scrum. XP (Extreme Programming). OpenUP (Open Unified Process). AUP (Agile Unified Process). FDD (Feature Driven Development). TDD (Test Driven Development). DSSM (Dynamic Systems Development Method).

Dentre as metodologias citadas, sero explanadas a seguir as duas mais importantes: Scrum e XP.

6. Mtodo Scrum
O Scrum uma metodologia cujas prticas so aplicadas em um processo iterativo e incremental. Assume-se que os projetos no qual o Scrum se insere so complexos e imprevisveis, onde no possvel prever tudo que ir acontecer. Por esta razo, ele oferece um conjunto de prticas que torna tudo isso visvel (Schwaber, 2004). um mtodo indicado para ambientes cujos requisitos no so bem definidos e sofrem freqentes mudanas. O Scrum possui membros com trs papeis pr-definidos: o Scrum Master, o Product Owner e o Scrum Team. Tambm possui trs artefatos que do apoio no controle de suas prticas: Product Backlog, Sprint Backlog e Burndown Chart. 6.1 Scrum Master Sua funo manter os processos e atuar como gerente de projeto dando suporte equipe para manter sua produtividade. E ele o responsvel pela implantao das prticas e valores do Scrum entre os membros da equipe.

6.2 Product Owner Pode ser o prprio cliente ou algum que o represente, contanto que tenha conhecimento suficiente sobre o negcio. E ele quem determina que funcionalidades deve ter o produto, modifica se preciso os requisitos e aprova ou no os resultados obtidos. 6.3 Scrum Team Equipe formada por profissionais multifuncionais, com cerca de sete pessoas, que realizam o desenvolvimento do software. Nesta equipe no h divises de papeis e todos trabalham em conjunto para garantir a entrega de cada incremento do produto (Sprint). 6.4 Product Backlog Definida pelo Product Owner, trata-se de uma lista formada pelo conjunto de todos os requisitos/funcionalidades almejados para o produto. Cada funcionalidade chamada de estria. Como cada estria pode ser modificada, adicionada ou excluda, esta lista poder ser alterada no decorrer de cada Sprint. 6.5 Sprint Backlog Lista formada pelo conjunto de atividades que a equipe (Scrum Team) dever desenvolver dentro da Sprint. Uma vez auto-organizvel e autnoma, a equipe define as tarefas de cada membro, o perodo necessrio para realiz-las e se uma tarefa deve ser modificada, adicionada ou excluda. 6.6 Burndown Chart a representao grfica das atividades do projeto. Permite a visualizao do andamento de todo o projeto, demonstrando tarefas concludas e pendentes. Neste grfico o eixo X simboliza a quantidade de dias do Sprint e o eixo Y simboliza a carga horria estipulada para cada Sprint.

Figura 1: Representao do Burndown Chart. Referncia: http://blog.brightgreenprojects.com/2009/07/07/what-is-a-burndownchart

6.7 Prticas do Scrum As prticas aplicadas pelo Scrum so: Sprint Iterao com durao de no mximo quatro semanas, seguindo um ciclo chamado de PDCA (Planejamento, Execuo, Verificao e Ao). No final de cada Sprint gerado um novo mdulo do software incrementado. Sprint Planning Reunio que deve ocorrer no comeo de cada Sprint, para determinar a finalidade da Sprint, as tarefas para a Sprint Backlog e as prioridades do Product Backlog. Dashboard Quadro com informaes da Sprint atual que indica tudo o que j foi realizado e o que ainda est por fazer. Estas informaes so apresentadas no quadro na forma de post-its.

Figura 2: Representao do Dashboard. Referncia: http://augustopierzynski.wordpress.com/category/scrum

Daily Scrum Reunies dirias, de no mximo quinze minutos, entre o Scrum Master e a sua equipe com o objetivo de expor as atividades concludas, analisar as prximas atividades e identificar possveis problemas. Sprint Review Apresentao dos resultados obtidos ao final de cada Sprint, onde o incremento gerado analisado pelos Scrum Master e Product Owner para verificar se o Sprint foi satisfeito. Sprint Retrospective Reunio que ocorre no final de um Sprint, depois do Sprint Review e antes do planejamento do prximo Sprint, visando que os membros exponham pontos positivos e negativos da equipe gerando melhorias para o prximo Sprint. 6.8 Ciclos do Scrum

Um ciclo no Scrum comea a partir da apresentao da idia do produto feita pelo Product Owner equipe de desenvolvimento. Neste momento gerado o Product Backlog e suas prioridades. O Scrum Master e a equipe realizam uma reunio de Sprint Planning 1 para definir as atividades da Sprint que se segue. Aps isso, dar-se incio a uma reunio de Sprint Planning 2 onde ser abordada a melhor forma de implementao, gerando a lista de Sprint Backlog. Agora possvel dar incio ao Sprint, onde podem ocorrer dois ciclos. O ciclo menor refere-se a uma iterao de no mximo quatro semanas e o ciclo maior refere-se a as Daily Scrum. Ao final do Sprint temos o Sprint Review com a apresentao de um incremento de produto a ser validado pelo Product Owner.

No final do ciclo temos o Sprint Retrospective onde so apontadas melhorias para o produto.

Figura 3: Representao do ciclo de desenvolvimento Scrum. Referncia: http://tasafo.wordpress.com/tag/scrum

7. Mtodo Extreme Programming

O Extreme Programming (XP) uma metodologia de desenvolvimento gil voltada para pequenas e mdias equipes que iro trabalhar com softwares que se modificam de forma constante. Este mtodo se diferencia dos demais por possuir uma abordagem incremental focada em feedbacks dirios entre os membros da equipe do projeto. O XP possui quatro valores que essenciais para se alcanar o sucesso de um projeto: Comunicao Deve ser direta, proporcionando maior agilidade aos assuntos discutidos. Deve esclarecer dvidas de imediato, uma vez que o cliente ficar a disposio da equipe. Simplicidade Deve ser desenvolvido apenas o essencial para atender ao cliente. Feedback Deve permitir que o cliente determine prioridades e identifique erros de imediato. Coragem Na implantao dos trs valores anteriores a equipe deve necessitar de coragem por se tratar de uma metodologia contrria ao modelo tradicional.

O XP possui membros com papeis importantes. So eles:

Cliente Inicia o processo apresentando as suas necessidades, atravs da descrio das funcionalidades e prioridades do sistema. Dever acompanhar a equipe durante todo o projeto. Gerente de Equipe Lidera a equipe garantindo a execuo das suas atividades e esclarece o andamento do projeto ao cliente. Desenvolvedor Codifica e testa as funcionalidades apresentadas pelo cliente. Comunica-se com o cliente durante cada incremento para esclarecer dvidas, evitar erros futuros ou propor melhorias. Coach Desenvolvedor com maior conhecimento na equipe, se responsabiliza por verificar se todos esto seguindo as prticas do XP. Tambm identifica habilidades entre os membros da equipe visando melhor distribuio de atividades durante o incremento. Redator Tcnico Realiza a documentao do projeto quando necessrio, isto , quando isto agregar valor ao cliente, garantindo a integridade das funcionalidades do sistema. Tracker Responsvel por adicionar lembretes informativos (em forma de postits) no ambiente de trabalho, tais como: pendncias em processos ou falhas encontradas. 7.1 Prticas do XP

As prticas aplicadas pelo XP so: Jogo de planejamento Momento em que feita a negociao com o cliente. realizado o planejamento do release onde temos o cliente expondo as suas necessidades e definindo as suas prioridades. Aps isso, temos o planejamento do incremento, sem que o cliente esteja presente, onde as atividades sero divididas e o tempo para conclu-las ser estimado. No final de cada incremento, um release do produto apresentado ao cliente. Neste momento o mesmo tem a oportunidade de realizar o feedback, aprovando ou sugerindo melhorias ao release. No caso de aprovao, o release ser adicionado ao produto final. Caso contrrio, o release ter o seu ciclo refeito.

Figura 4: Ciclo de desenvolvimento XP.

Programao em Pares Onde dois desenvolvedores iro trabalhar juntos utilizando o mesmo computador para que juntos possam identificar melhores solues na codificao dos problemas apresentados por cada funcionalidade. A programao em pares tem como objetivo otimizar a qualidade da codificao, e tem como benefcio uma troca de conhecimentos entre os programadores durante todo o processo de implementao. Juntos eles iro discutir solues e escolher a que melhor atender ao problema, reduzindo a quantidade de linhas de cdigo e de erros. Stand Up Meeting Consiste em reunies de no mximo quinze minutos, feitas com os participantes em p para garantir uma maior ateno dos mesmos e incutir os participantes a irem direto ao assunto. Nesta reunio a equipe poder discutir sobre obstculos encontrados ou transmitir informaes pertinentes ao andamento do projeto. Teste So desenvolvidos e realizados pelos membros da equipe para garantir a qualidade do software produzido. Devem ser desenvolvidos Testes de Unidade para analisar o funcionamento correto de pequenos trechos de cdigo. Tambm so realizados Testes de Aceitao para analisar a integrao entre as partes testadas e se as mesmas esto se comportando de acordo com a necessidade do cliente. Refactoring Alterao realizada na codificao para reduzir linhas de cdigo, tornando-o mais claro e mais rpido, conservando a sua integridade e o seu propsito. Poder ser feita por qualquer membro da equipe que detecte no cdigo quaisquer problemas estruturais ou de desempenho. Design Simples Toda e qualquer funcionalidade que raramente ser utilizada pelo cliente totalmente evitada pelo Mtodo XP. Apenas o que for agregar algum valor ao cliente que dever ser codificado, sempre com o menor custo e

pouca complexidade. A simplicidade no design resultado da objetividade que o XP possui para a resoluo de problemas. Metfora Forma de comunicao que esteja no nvel mais prximo de conhecimento do cliente, visando que o mesmo possa compreender o andamento do projeto e evitando possveis falhas de comunicao que possam vir a prejudicar o desenvolvimento do produto. Releases Curtos Pequenas partes funcionais do produto final geradas ao trmino de cada ciclo. Os releases so entregues regularmente ao cliente para a sua validao. Como o cliente acompanha o andamento de cada funcionalidade, torna-se possvel que o mesmo participe de toda a evoluo do projeto, e se mantenha satisfeito.

8. Benefcios das Metodologias geis

Ao contrrio das Metodologias Tradicionais, as Metodologias geis tm como caracterstica mais marcante o seu curto perodo de desenvolvimento. Isto lhe permite a identificao e a correo de erros de forma mais rpida. A sua criao se deu pela necessidade urgente em se desenvolver softwares que fossem de fcil adaptao a quaisquer alteraes no decorrer do seu projeto, sem que para isso houvesse a violao de prazos e a elevao de custos. A proximidade do cliente junto a equipe de desenvolvimento facilitou a comunicao necessria entre os participantes do projeto, garantindo um software com funcionalidades totalmente validadas e que atende s solicitaes do cliente, sendo este o objetivo de todo projeto de software.

9. Crticas Sobre o Uso das Metodologias geis

Como o emprego das Metodologias geis no adequado para todo o tipo de organizao, comum que algumas crticas negativas venham a surgir. H quem acredite que esta metodologia seja apenas empregada nas empresas de pequeno ou mdio porte somente por que elas no teriam estrutura para suportar o custo gerado no emprego de uma metodologia tradicional. Outros consideram esta metodologia como um estilo de codificao catico, chamandoo de codifica-remenda e acreditam que o levantamento de requisitos de maneira informal cause uma falsa percepo no cliente de que a equipe seja mal qualificada para exercer suas tarefas.

10. Concluso
A Metodologia gil formada por um conjunto de prticas que podem ser agregadas a outras metodologias. Ela um comportamento a ser seguindo e no um processo prdefinido, ou seja, seu funcionamento estritamente prtico e no terico. Talvez o maior desafio para as Metodologias geis seja alcanar formas para minimizar seus pontos fracos como, por exemplo, a ausncia da anlise de riscos. Outra dificuldade a ser vencida o seu emprego em grandes organizaes com grandes equipes, j que estas metodologias so indicadas para pequenas equipes.

Apesar do que foi dito, as Metodologias geis, quando praticadas corretamente, podem somar resultados positivos a qualquer projeto de software, pois caractersticas como o trabalho em equipe, a comunicao direta e a adaptao a mudanas contribuem para o sucesso de um produto.

11. Referncias
Schwaber, K. (2004) Agile Project Management with Scrum, Microsoft Press. Soares, Michel dos Santos. 2004. Comparao entre metodologias geis e tradicionais para o desenvolvimento de software. KUHN, Giovane Roslindo & PAMPLONA, Vitor Fernando. 2009. Apresentando XP, Encante seus clientes com Extreme Programming Java Fee.org. Manifesto for Agile Software Development. 2001. Disponvel em http://www.agilemanifesto.org. ltimo acesso em 16 de Outubro de 2011. Mtodos geis. 2005. Disponvel em http://www.ccw.com.br/post/ler/50/metodologias_ageis. ltimo acesso em 15 de Outubro de 2011. SILVA, Tiago de Farias. Desenvolvimento de Software. 2008. Compondo Mtodos geis de

SCHWABER, Ken & BEEDLE, Mike. 2008. Scrum e XP direto das trincheiras. Disponvel em: http://www.infoq.com/br/minibooks/scrum-xpfrom-the-trenches. ltimo acesso em 22 de Outubro de 2011. SOARES, Michel dos Santos. 2004. Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software Disponvel em: http://revistas.facecla.com.br/index.php/reinfo/article/view/146. ltimo acesso em 22 de Outubro de 2011. SATO, Danilo Toshiaki. 2007. Uso eficaz de mtricas em mtodos geis de desenvolvimento de software Disponvel em: http://grenoble.ime.usp.br/~gold/orientados. ltimo acesso em 23 de Outubro de 2011.