Processos geisAprenda o que so processos geisConhea as metodologias Scrum e Extreme Programming e quais as diferenas entre as metodologias tradicionais e geis Leonardo Simas, Osias Carneiro, Vagner Fonseca e Weslley Leandro

O desenvolvimento de tecnologias e a necessidade crescente de sistemas de informao vem desafiando as empresas responsveis pela criao de aplicaes. difcil acompanhar as mudanas de tecnologias, as solues cada vez mais complexas, as interferncias do mundo externo, mudanas nos requisitos, entre outros. Para tentar amenizar esses problemas, a Engenharia de Software procura definir metodologias de desenvolvimento de software, que possibilitam uma organizao nos processos e etapas desde sua especificao at a implantao, como os processos geis. H diversas maneiras de se desenvolver um software de maneira rpida, por meio dos mtodos geis de desenvolvimento de software. Essa metodologia de desenvolvimento evoluiu a partir da metade dos anos 90, com o fortalecimento da Engenharia de Software e com o surgimento de novas maneiras de se pensar ao construir um software. O objetivo deste artigo consiste em realizar uma abordagem a respeito das metodologias tradicionais e as metodologias de processos geis, apresentando um breve histrico e focando nas duas principais metodologias de desenvolvimento Scrum e Extreme Programing (XP). Metodologias TradicionaisO modelo em Cascata, um dos mais utilizados at pouco tempo atrs (LEACH, 2000), definia etapas que deveriam ser sequenciais, uma s deve ser iniciada aps o termino da sua antecessora, como observado na Figura 1. Um modelo inflexvel onde o cliente s poderia validar o que foi desenvolvido no final do processo depois do software completamente desenvolvido, alteraes na especificao eram difceis ou simplesmente impossveis de serem realizadas durante o desenvolvimento. Muitas vezes gerava o famoso big bang onde no final o software j no atendia as necessidades por mudanas no ambiente externo ou precisava ser alterado e um novo fluxo se iniciaria. O modelo em Espiral (Figura 2) sugere uma sequncia de etapas mas, diferente do cascata, o

software divido em verses chamadas de incremento. Possui quatro atividades:1. Determinao dos objetivos da iterao2. Anlise dos riscos3. Desenvolvimento4. Validao, Testes e planejamento da prxima iterao

Figura 1. Etapas do modelo em cascata

Dessa forma possvel lidar melhor com alteraes durante o projeto e a validao do que se est desenvolvendo melhor para o cliente, que acompanha o desenvolvimento. Mas assim como no modelo em cascata no permite etapas sendo realizadas em paralelo ou que precisem de comunicao com outras etapas.

Figura 2. Modelo em Espiral

O modelo Iterativo e Incremental apresenta um ciclo de vida iterativo baseado no aumento e no refinamento sucessivo de um sistema atravs de mltiplos ciclos de desenvolvimento de anlise, de projeto, de implementao e de teste (LARMAN, 2000).

Atualmente o modelo mais utilizado, ou outros modelos baseados neste, que traz alguns benefcios como (MARTINS, 1999):

A reduo de riscos com os custos e prazos planejados; A equipe fica focada com os objetivos de cada incremento, trabalhando de maneira mais

eficiente;Um modelo emergente que combina um melhor gerenciamento e a preocupao com como as pessoas trabalham (CANTOR, 1999).

Figura 3. Modelo Iterativo e Incremental Processos geisAs metodologias geis promovem o desenvolvimento com o trabalho em equipe, colaborao e adaptabilidade durante o ciclo de vida do projeto. Assim como no modelo iterativo e incremental, o software dividido em verses, ou seja, possuem incrementos que so partes menores do software e so realizados em torno de uma a quatro semanas, passando por todas as etapas desde especificao at a fase de testes.

Com o objetivo de minimizar a quantidade dos possveis erros a cada iterao, ela pode no gerar uma verso com funcionalidade suficiente para o mercado e vrias iteraes podem ser necessrias para lanar uma nova funcionalidade.

H uma priorizao na comunicao cara a cara entre os integrantes da equipe do que a documentao (no quer dizer que no h documentao) e por isso sugere que todos trabalhem na mesma sala.

necessrio um representante do cliente para que se possa tirar dvidas e esclarecer questes que possam surgir durante as iteraes e que esteja disponvel para atender os os demais participantes no projeto do software. Manifesto gilAo passar dos anos as organizaes passaram a estar mais focadas em resultados rpidos e

precisos, contratando empresas de desenvolvedoras de software para agilizar os seus processos institucionais e devido aos projetos de software sofrer diversas transformaes, nos ltimos tempos metodologias de desenvolvimento, como o Scrum e o XP, se fortaleceram. Entre elas, a metodologia de desenvolvimento gil de software se consolidou no mundo de desenvolvimento de software e em 2001 o Manifesto gil termo criado aps a criao da Aliana gil onde foram apresentados alguns mtodos de desenvolvimento de software entre eles se destacam os mtodos Scrum e Extreme Programming (XP), e tambm foram fundamentados alguns princpios e caractersticas entre os mtodos. Esses mtodos aumentam o desempenho e provendo mais qualidade ao produto final. ScrumNo incio do ano de 1986 Hirotaka Takeuchi e Ikujiro Nonaka, escreveram um artigo, foi observado que equipes pequenas e com baixo nvel de especializao, obtm melhores resultados do que equipes grandes, nisso h uma semelhana com uma equipe de rugby, quando uma falta cometida, eles se arranjam em uma formao coesa de nome Scrum.

O Scrum uma metodologia gil iterativa e incremental, pois trata-se de um framework que facilita a visualizao de problemas, mesmo os que possuem de dificuldade elevada.

Scrum tem por objetivo agregar o mximo de valor ao negcio com o menor tempo possvel, focando no Retorno de Investimento (ROI), administrando complexidade, imprevisibilidade e mudana por meio da visibilidade, inspeo e adaptao (SUTHERLAND, 2002).

Quanto aos papis executados o Scrum determina trs (SCHWABER, 2009):

Scrum Master - Tem a funo de lder de equipe, protegendo-a de obstculos e problemas que a impeam de realizar seu trabalho.

Product Owner - Maximiza o trabalho do time Scrum, definir recursos, escolher datas de lanamento, fornecer feedback dos processos e garantir que as regras Scrum sejam seguidas, ou seja, o cliente ou algum que o represente.

Time Scrum - Responsvel pelo desenvolvimento do projeto, tem de 5 9 integrantes, define tarefas e o esforo para realizar as tarefas com a qualidade desejada pelo Product Owner.

Para SUTHERLAND(2008) as princpais ferramentas do Scrum so o backlog do produto, backlog do sprint, burndown para entrega e burndown do sprint.

SCHWABER(2009) define que o backlog do produto um documento com requisitos separados por prioridades que so indispensveis ao produto. Backlog do sprint a lista de tarefas que a equipe executar para transformar o backlog do produto em um incremento entregavel ao cliente. Um burndown de verso para entrega mede o backlog de produto restante ao longo do tempo de um plano de entrega. O burndown de sprint mede os tens do burndown de sprint restantes ao longo do tempo de uma sprint.

O scrum utiliza-se de eventos de durao fixa, planejamento de verso para entrega, sprint, reunio diria, reviso e retrospectiva da sprint

Planejamento da verso: onde os documentos que definem os requisitos do produto so concebidos (backlog de produto), suas prioridades e a estimativa de esforo para cada requisito.

Reunio da sprint: aqui os requisitos so apresentados equipe e so definidos, de acordo com a habilidade de cada um, a tarefa que executaro (backlog da sprint) essa reunio tem em mdia 3 a 12 horas dependendo da sprint.

Sprint: para SCHWABER (2009) essa fase a coroao do Scrum, com durao por volta de 30 dias, nesse momento os requisitos so desenvolvidos e implementados, ao final entregue um incremento funcional ao cliente.

Reviso da sprint: Reunio entre a equipe com no mximo duas horas de durao onde os resultados so apresentados, deve-se ter cuidado ao dizer realizado j que os resultados sero apresentados ao cliente.

Retrospectiva do sprint: Nessa reunio verifica-se o que foi feito de positivo e tambm os pontos negativos, afim de revisar o que foi feito de errado para ser corrigido em verses posteriores, atualizando-se o backlog do produto.

Figura 4. As etapas da metodologia Scrum e sua durao mdia Extreme Programming (XP)O Extreme Programming (XP), metodologia criada por Kent Beck, est voltado principalmente para pequenas e mdias equipes, visando o desenvolvimento de software que se baseiam em requisitos vagos e que se modificam rapidamente (Beck, 1999). O mtodo XP se diferencia dos demais devido a uma abordagem incremental, fortalecendo a comunicao (feedback) entre as pessoas envolvidas no processo de desenvolvimento. O XP possui quatro valores fundamentais: comunicao, simplicidade, feedback e coragem (Beck, 1999). Para alcanar sucesso na utilizao do XP, preciso seguir todos esses valores.

Comunicao: deve ocorrer da maneira mais direta (face-a-face) e eficaz possvel, a fim de oferecer agilidade aos assuntos tratados, esclarecendo dvidas de imediato e evitando especulaes ou mal entendidos entre as partes. O cliente deve estar a disposio da equipe e membros introvertidos devem ser evitados.

Simplicidade: preciso simplicidade no desenvolvimento das funcionalidades solicitadas. O desenvolvedor deve implementar apenas o necessrio para atender ao usurio, sem se preocupar com funcionalidades que podem ser importantes no futuro, pois elas podem nunca ser utilizadas.

Feedback: com partes funcionais em mos, o cliente estar apto a conduzir a equipe de desenvolvimento, estabelecendo prioridades e identificando erros imediatamente. Em contrapartida, o desenvolvedor poder apontar riscos e estimativas.

Coragem: por se tratar de uma metodologia nova, que contraria o modelo tradicional, a equipe precisa de coragem para implantar os trs valores anteriores. Nem todos possuem facilidade de comunicao ou pacincia para obter feedback constante do cliente.

Alm dos quatro valores bsicos, o XP baseia-se em diversas prticas (Figura 5). Para Beck (1999) existem doze principais prticas de desenvolvimento, elencadas e descritas abaixo:

Planejamento: consiste em definir o que ser feito e o que ser adiado. O foco deve estar nos requisitos atuais e no nos futuros. A escolha deve gerar o mximo de valor para o cliente.

Entregas frequentes: trata-se de construir um software simples e em seguida adicionar funcionalidades conforme elas forem surgindo. Com isso, o feedback do cliente ser mais rpido e surpresas sero evitadas.

Metfora: so comparaes e analogias utilizadas para explicar situaes mais facilmente, sem o uso de termos tcnicos. Essa tcnica facilita a comunicao e a fixao dos assuntos entre as partes.

Projeto simples: o software desenvolvido deve ser o mais simples possvel para resolver o problema atual do cliente, sem se preocupar com requisitos futuros. Esses devem ser adicionados assim que forem realmente necessrios.

Testes: garantem resultados corretos das funcionalidades. Os testes devem ser feitos de preferncia antes do desenvolvimento (TDD - Test Driven Development).

Programao em pares: dois desenvolvedores trabalharo em um nico computador. Enquanto um codifica o outro observa, buscando estratgias para otimizar o cdigo do colega. A troca de experincias e idias um dos grandes benefcios.

Refatorao: consiste em reescrever um cdigo ilegvel, duplicado, despadronizado etc. sem alterar o seu comportamento.

Propriedade coletiva: o cdigo pertence a toda a equipe. Dessa forma, qualquer desenvolvedor que julgar necessrio modific-lo, poder faz-lo.

Integrao contnua: a integrao entre as partes do software deve ser efetuada, preferencialmente, vrias vezes ao dia.

40 horas de trabalho semanal: mais de 40 horas semanais de trabalho significa problema no projeto e deve ser resolvido com melhor planejamento, no com aumento de horas trabalhadas.

Cliente presente: o cliente deve estar sempre disponvel para tirar dvidas, evitando atrasos na comunicao e implementaes erradas. interessante torn-lo parte da equipe de desenvolvimento.

Cdigo padro: seguir padres previamente acordados de codificao refora a comunicao entre os programadores, facilitando o entendimento e a manuteno.

Figura 5. Valores, princpios e prticas do Extreme Programming Relato - Implantao de Processos geisSegundo o estudo de caso realizado no Banco Central do Brasil (MELO e FERREIRA, 2010), a implantao de processos geis pode solucionar questes que no so abordadas pelas metodologias tradicionais. A empresa utilizava um processo derivado do Rational Unified Process (RUP), um processo iterativo, mas robusto. A empresa planejou dois projetos pilotos com duas equipes contendo 7 e 6 pessoas respectivamente, sendo que a maioria dos desenvolvedores possuam experincia de 2 ou mais anos na rea de desenvolvimento, mas poucos conheciam as metodologias a serem utilizadas ou sobre os conceitos de processos geis. No incio do primeiro projeto foram apresentados os conceitos sobre mtodos geis e as metodologias Scrum e XP, para familiarizao da equipe. Segundo o relato (MELO e FERREIRA, 2010), as equipes compreenderam e aplicaram facilmente as prticas de pares e de equipes do XP, sendo que a programao em pares foi de fcil compreenso e absoro pela equipe e a prtica

da metfora a mais complexa de ser interpretada. A prtica de execuo de testes pelo cliente bem como as entregas curtas, apesar de bem compreendidas, no foram de fcil aplicao devido cultura do cliente. Mesmo que as entregas agregassem funcionalidades de certo valor, a organizao no tinha o costume de receber solues inacabadas. A equipe relata que houve um ganho quanto a rapidez no aprendizado de tecnologias, conceitos e padres. A produtividade foi medida nos dois projetos pilotos utilizando, a medio por pontos de funo e pelas horas gastas nos mesmos. No primeiro houve um ganho de mais de 8% e no segundo mais de 30% em relao a mdia da organizao. O primeiro era mais complexo que o segundo e a curva de aprendizado foi maior, pois foi a primeira vez que utilizaram processos geis e o segundo aprendeu com os erros do primeiro. Os clientes compararam os resultados obtidos com suas experincias passadas usando metodologias tradicionais, com isso foi gerado uma ntida satisfao do cliente, pois foi possvel observar benefcios como:

Reduo no prazo de entrega Facilidade/possibilidade de alteraes Entendimento aprimorado sobre os custos Maior segurana quanto aos testes realizados

A implantao de qualquer metodologia em uma organizao um processo lento, complexo e exige mudanas na cultura organizacional da empresa, logo dois pilotos no foram suficientes para a mudana. Mas os ganhos com produtividade e satisfao do cliente compensam tais custos e obstculos e favorece a implementao. ConclusoNeste artigo abordamos a respeito do Scrum e XP que so metodologias de desenvolvimento de software utilizadas nos projetos piloto do Banco Central do Brasil. Aplicar um processo gil em uma organizao requer uma mudana na cultura da mesma exigindo tempo e gerenciamento dessa implantao. A organizao deve precisa ter um ambiente favorvel a comunicao, o tamanho do projeto pode inviabilizar essa comunicao, so indicadas a formao de equipes de no mximo 20 ou 40 pessoas sendo ela composta por pessoas experientes. Os processos geis atendem muito bem projetos e organizaes que preenchem esses requisitos mas apesar de j proporcionarem resultados de sucesso h aqueles que afirmam que ainda preciso de mais resultados para comprovar o sucesso desses mtodos.

Referncias

OLIVEIRA, Alexsandro; MATEUS, Andrade; VINICIUS, Corra; Uma Introduo s Metodologias geis de Desenvolvimento de Software. Salvador, Bahia. SILVA, Maysa Alves da Conceio; FILHO, Heitor Roriz; SILVA, Helena de Ftima Nunes; Anlise do BA durante o processo Scrum. Artigo apresentado no XVII Simpsio de engenharia de produo, Bauru, So Paulo, Brasil, 2010. BONA, Cristina. Avaliao de Processos de Software: Um Estudo de Case em XP e ICONIX. 2002. 122 f. Dissertao (Mestrado em Engenharia de Produo) - Universidade Federal de Santa Catarina. Florianpolis, 2002. Agile Alliance. Acesso em: 25 de julho de 2011. Disponvel em: Manifesto para Desenvolvimento gil de Software. Acesso em 26 de julho de 2011. Disponivel em

Agile Software Development. Acesso em 29 de julho de 2011. Disponvel em: Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Acesso em 28 de julho de 2011. Disponvel em:

MELO, Claudia de O, FERREIRA, and Gisele R. M. Adoo de mtodos geis em uma Instituio Pblica de grande porte - um estudo de caso., In Proceedings of the Brazilian Workshop for Agile Methods (WBMA 2010) in the Brazilian Conference on Agile Methods (Agile Brazil 2010), pp. 112-125. June, 2010. Disponvel em:

Leonardo Simas (leosimasgoncalves@gmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia (UNEB) e estagirio no Instituto Recncavo de Tecnologia.

Osias Carneiro (osiascarneiro@hotmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia (UNEB) e estagirio no Instituto Recncavo de Tecnologia.

Vagner Fonseca (vagner.fonseca@gmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia (UNEB), foi coordenador do grupo de desenvolvimento da XI Escola Regional de Computao Bahia Alagoas Sergipe (XI ERBASE), participou do projeto de desenvolvimento de agente para sistema de Segurana de Notebooks Leadership e estagirio da Gerncia de Informtica da UNEB.

Weslley Leandro (weslleyleandro@gmail.com) graduando em Sistemas de Informao pela Universidade do Estado da Bahia (UNEB) e estagirio na Wcs Design.