15

ndicePrefcio por Miguel, Paulo e Francisco21.INTRODUO32.HISTRICO43.METODOLOGIAS GEIS43.1 SCRUM54.CASO DE SUCESSO65.RUP e XP - Uma viso geral95.1 APLICAO DE RUP NO PTROJECTO BASEADO EM SCRUM95.2 COMPARATIVO ENTRE RUP E XP E SUAS APLICAES105.3 VANTAGENS E DESVANTAGENS PARA O CASO EM ESTUDO125.4NECESSIDADE OU NO DE ADAPTAO DA METODOLOGIA126.CONSIDERAES FINAIS14BIBIOGRAFIA15

Prefcio por Miguel, Paulo e Francisco

As equipas de desenvolvimento de software precisam conhecer o bsico do Scrum. Como criar e estimar um product backlog[footnoteRef:1]? Como transform-lo num sprint backlog[footnoteRef:2]? Como gerir um grfico burndown e calcular a velocidade da sua equipa? [1: OProduct Backlog uma lista contendo todas as funcionalidades desejadas para um produto.] [2: O Sprint Backlog uma lista de tarefas que oScrum Teamse compromete a fazer em um Sprint.]

Uma boa execuo do Scrum est se tornando mais importante para as equipas que buscam investimento de fundos externos. Um mentor gil para um grupo de capital de risco, ajuda a investirem em empresas que executam as prticas geis com eficincia. As oportunidades futuras de investimento iro exigir que as equipas de desenvolvimento saibam a sua velocidade de produo.

Por que isso to importante?

Se as equipas no conhecem a sua prpria velocidade, o product owner[footnoteRef:3] no pode criar um guia do produto com as datas de entregas com credibilidade. E sem as datas de entrega interdependentes, a empresa poder falhar e os investidores podero perder o seu dinheiro! [3: O Product Owner a pessoa que define os itens que compem o Product Backlog e os prioriza nas Sprint Planning Meetings.]

Esse problema enfrentado por companhias grandes e pequenas, novas ou antigas, com investimento prprio ou externo.

O desenvolvimento iterativo fundamental no manifesto gil entrega-se o software funcionando cedo e com frequncia. Depois de anos de retrospetivas com centenas de equipas de Scrum, por exemplo, a Nokia desenvolveu alguns requisitos bsicos para o desenvolvimento iterativo:

As iteraes devem ter um tempo fixo com menos de seis semanas de durao. Ao final da iterao, o cdigo deve ser testado pela equipa de qualidade e funcionar corretamente. Uma equipa de Scrum deve ter um product owner e saber quem ele . O product owner deve ter um product backlog com estimativas criadas pela equipa. A equipa deve ter um grfico burndown e saber a sua velocidade. No deve haver nenhuma interferncia externa sobre a equipa durante um sprint.

Se se seguir as boas prticas, teremos um product backlog, estimativas para o product backlog, um grfico burndown, e saberemos a velocidade da nossa equipa, alm de outras prticas fundamentais para um Scrum altamente funcional. Com isso tudo, podemos ser o futuro do desenvolvimento de software e os criadores da prxima gerao de produtos lderes de mercado.

INTRODUO

O que se busca na Engenharia de Software o incessante melhoramento do processo de desenvolvimento de software. Os prazos e custos estipulados podem no chegar a serem alcanados, mesmo com a crescente evoluo da tecnologia, metodologias e recursos. Um dos principais motivos a excessiva formalidade nos modelos de processos colocados nos ltimos anos. Existe ento a necessidade de desenvolver software de forma mais rpida, sem que se perca a qualidade. O novo paradigma em desenvolvimento de software que se pode obter esse resultado por meio da utilizao de metodologias geis.

Embora as metodologias geis tenham sido apontadas como alternativa s metodologias clssicas para o desenvolvimento de software, as metodologias clssicas, conhecidas tambm como rigorosas, pesadas ou orientadas a planeamentos, possuem utilizao garantida no que diz respeito a situaes em que os requisitos do sistema so complexos e estveis e requisitos futuros so previsveis.

Este artigo aborda vantagens e desvantagens de metodologias geis e de metodologias clssicas, particularmente, da metodologia gil SCRUM alm de citar um caso de sucesso da metodologia gil SCRUM na AG2 uma empresa sediada no Brasil. Na Seo 2, apresentado o histrico do processo de desenvolvimento de software, desde o uso restrito das metodologias tradicionais at a criao do Manifesto gil. Na Seo 3, so apresentados conceitos bsicos sobre as metodologias geis, alm das suas aplicaes, focando-se mais na metodologia SCRUM fazendo um descritivo da sua aplicabilidade na concepo de um projeto de desenvolvimento de software. Na Seo 4, apresentado um caso de sucesso relacionados a metodologia SCRUM. Na Seco 5, abordamos um comparativo entre o mtodo RUP e o XP e, por fim, na seco 6 as consideraes finais.

HISTRICO

Baseadas em mainframes e terminais burros, as metodologias tradicionais fizeram parte, inicialmente, de um contexto de desenvolvimento de software muito diferente do atual. O custo para que modificaes fossem feitas era alto, devido s limitaes dos computadores e falta de ferramentas modernas para apoiar a criao do software, tais como depuradores e analisadores de cdigo. Sendo assim, o software era antes planejado e documentado para ento ser implementado. O modelo clssico caracterizado como metodologia tradicional utilizado at hoje.

Nos ltimos anos, novas metodologias foram aplicadas, sempre visando a rapidez no fornecimento aliada qualidade do processo e do produto. Surgem, ento, as metodologias geis, popularizados quando Becket et al criaram o Manifesto gil indicando alguns princpios compartilhados por tais metodologias:

a)Indivduos e interaes so mais importantes que os processos e ferramentas;b)Software funcionando mais importante do que a documentao detalhada;c)Colaborao dos clientes mais importante do que a negociao de contratos;d) Adaptao s mudanas mais importante do que seguir um plano.

Nesta nova abordagem a reutilizao de software uma prtica comum durante o desenvolvimento. Os padres de projeto contribuem para o reuso em situaes em que preciso um nvel alto de abstrao, sobretudo na fase de anlise, na definio da arquitetura do sistema, em questes organizacionais e de otimizao dos processos, sendo que esses dois ltimos tm por objetivo apoiar a construo do software e melhorar o seu desenvolvimento. O uso de componentes outro especto possvel. Deste modo, a integrao dos padres organizacionais e de processo proporciona rapidez e qualidade no desenvolvimento.METODOLOGIAS GEIS

Como foi apresentado no segundo captulo, o termo Metodologias geis se tornou popular quando dezassete especialistas em processos de desenvolvimento de software, estabeleceram conceitos comuns a serem compartilhados por todos essas metodologias. Foi ento criada por BECK et al. a Aliana gil e instaurado o Manifesto gil.

O objetivo do Manifesto gil no desconsiderar processos, ferramentas, documentao, negociao de contratos ou planeamento, mas mostrar o valor secundrio que estes possuem diante dos indivduos e interaes, do bom funcionamento do software, da colaborao do cliente e das respostas velozes s modificaes. Esses conceitos esto mais relacionados forma que as pequenas e mdias empresas trabalham, devido a estarem habituadas a mudanas. A mais conhecida dentre as metodologias geis a Extreme Programming.3.1 SCRUM

O SCRUM uma metodologia gil de trabalho onde usada para estabelecer conjuntos de regras e prticas de gesto para conseguir o sucesso de um projeto. Com o foco no trabalho em equipa, ocorre uma melhora na comunicao e maximiza o apoio de todos, fazendo com que todos do time se esforcem e se sintam bem com que esto fazendo e isso acaba gerando mais para frente um aumento de produtividade.

Jeff Sutherland colocou em prtica a primeira concepo do SCRUM na Easel Corporation em 1993 e em 1995, Ken Schwaber pegou essa metodologia e refinou baseando-se com sua experincia em desenvolvimento de sistemas e processos.

As principais caractersticas do SCRUM so:

um processo gil para gerenciar e controlar o desenvolvimento de projetos; um invlucro para outras prticas de engenharia de software; um processo que controla o caos resultante de necessidades e interesses conflituantes; uma forma de aumentar a comunicao e maximizar a cooperao; uma forma de detetar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto; escalvel desde projetos pequenos at grandes projetos em toda empresa.

O modo de organizao no SCRUM feito da seguinte forma (Figura 1):

Cria-se o backlog onde tem a lista de todas as funcionalidades que precisam ser desenvolvidas durante todo o projeto, junto com o stakeholder, onde precisa ser bem definido e detalhado no comeo, listado e ordenado por prioridade do que mais importante;Com o backlog pronto, cria-se o sprint backlog, onde se decide o tempo necessrio (dentro dos 30 dias) para criar a funcionalidade requisitada;

Depois de todo o planeamento, os itens do backlog so divididos nas equipas e entra no sprint que pode durar de 2 a 4 semanas.

A cada 24 horas tem uma reunio com os membros de equipas e questes devem ser respondias como:- O que fizeste desde a ltima reunio?- O que te impede de continuar?- O que vais fazer at a prxima reunio?Ao trmino do sprint as funcionalidades requisitadas so demonstradas.

Figura 1 - Descrio do processo scrum.

O SCRUM, como um mtodo gil, e as metodologias geis acabam tendo varias semelhanas, contatos ou pontos em comum, ele tem um forte relacionamento com o XP como por exemplo, eles tem a raiz fundamentada em um manifesto gil.

CASO DE SUCESSO

A AG2 uma agncia digital com mais de 70 pessoas envolvidas em desenvolvimento. Recentemente ele resolveram adotar o Scrum. As suas linhas de servios proporcionam um ciclo de atendimento completo, tendo capacidade de resposta s necessidades de toda a cadeia de valor do negcio. A AG2 suporta os seus clientes na definio de opes estratgicas e tecnolgicas, desenvolve sistemas web sob medida para as mais diversas aplicaes, bem como aes de comunicao interativa, provendo ainda toda a gesto operacional da presena digital. Com mais de 150 colaboradores nas suas bases de So Paulo, Porto Alegre e Pelotas, a AG2 atende empresas como Embraer, Bradesco, General Motors, Grupo Silvio Santos, Bunge, C&A e Vulcabras.

A AG2 conta com aproximadamente 30 colaboradores envolvidos diretamente no desenvolvimento de sistemas, como codificadores HTML, analistas de sistemas, DBAs, desenvolvedores. Net e analistas de testes e 40 nas disciplinas relacionadas a arquitetura de informao e interface, como analistas e projetistas de interface, diretores de arte, web designers, programadores Flash, alm de profissionais de anlise de negcios, criao e gesto de projetos.

Comearam a estudar Scrum pelo facto de ser mais uma metodologia de desenvolvimento de projetos, inicialmente mais em tom investigativo e para conhecer os conceitos do que efetivamente objetivando alterar as suas metodologias. Durante o estudo notou-se que vrios aspetos dela poderiam se encaixar muito bem no que fazem, agregando muito com relao a agilidade e velocidade de desenvolvimento que ela proporciona. Devido principalmente aos prazos sempre apertados que tm para desenvolver e o teor de alguns projetos comearam a fazer alguns testes em alguns projetos.

Visando a necessidade da melhoria na gesto dos projetos resolveu-se aplicar Scrum num projeto e analisar o desempenho de produtividade do projeto com o emprego desta metodologia.

O projeto na qual foi desenvolvido era para a plataforma de hadrware Windows XP profissional, a ferramenta de desenvolvimento era o Microsoft Visual Studio 2008, a ferramenta de banco de dados SQL Server 2005, a ferramenta de anlise e projeto o Enterprise Architect, ferramenta de acompanhamento de bugs JIRA, sedo o mesmo produzido para a plataforma desktop. O projeto possua 221 pontos de caso de uso tcnicos e era enquadrado na modalidade de Fbrica de Soluo, na qual so projetos em que a equipa do projeto trabalha com a equipa do cliente desde a etapa inicial de avaliao de necessidades e concepo de requisitos, ajudando o cliente a gerar uma soluo de alto valor agregado para seu negcio.

Aplicar Scrum traz vrias mudanas, principalmente culturais na empresa. Para o incio da utilizao do Scrum, como primeiro passo aplicou-se um treinamento para todos os colaboradores para que todos pudessem conhecer as atividades a serem desempenhadas na nova metodologia de gerncia de projeto e assim nivelar o conhecimento adquirido.

No treinamento foram repassados os conhecimentos a cerca do ciclo do Scrum e mostrado em detalhes cada evento a ser executado com o emprego da metodologia gil, assim como as vantagens e facilidades proporcionadas pelo Scrum.

O segundo passo foi realizar o planeamento inicial do projeto. Cada Sprint teve sua durao definida em trs semanas, assim a cada rodada tinha que ser entregue uma parte incremental do produto testado e funcionando. No total, foram definidas cinco Sprints para a concluso do projeto.

A princpio, foram definidas as seguintes atividades a serem realizados no projeto e estas foram enquadradas no Backlog:

Levantamento dos requisitos. Especificao dos requisitos. Anlise e Projeto. Especificao de testes. Reviso tcnica. Implementao. Testes. Correo. Entrega.

Em seguida, o plano do projecto foi montado e apresentado ao cliente. O cliente foi envolvido inicialmente com participao ativa de forma remota para a definio das prioridades das atividades. Para cada Sprint realizou-se um Sprint Planning Meeting, ou seja, uma reunio para planeamento da Sprint, de modo que pudesse definir dentre as atividades do Backlog aqueles que seriam executadas na Sprint. Alm disso, a cada incio do dia o gerente do projeto realizava a Daily Meeting, ou seja, a reunio diria para acompanhamento das atividades do projeto (atividades a fazer, atividades finalizadas, atividades em andamento), assim como para a identificao dos impedimentos ocorridos no dia anterior para que fossem resolvidos o mais rpido possvel. Estas reunies tinham durao de no mximo 15 minutos.

O prximo passo foi executar cada Sprint. A cada entrega, ou seja, decorridos trs semanas, o time realizou a reunio de reviso (Sprint Review) para apresentao do produto realizado na Sprint. Aps esta reunio fazia-se uma reunio de retrospetiva (Sprint Retrospective) para demonstrar as lies aprendidas. Nestas reunies, foi possvel identificar os principais desafios enfrentados pela equipa. Alm disso, ao final de cada Sprint, o gerente realizou as medies dos indicadores de desempenho de produtividade do projeto.

As equipas que montaram tinham em mdia 9 integrantes. Para cada equipa optou-se por colocar diferentes disciplinas de desenvolvimento, de forma que uma equipa tenha capacidade de desenvolver qualquer tipo de demanda e seja auto-gerencivel. Ou seja, tinham desenvolvedores. Net junto com Diretores de Arte, sentados lado a lado em locais fsicos especficos para a equipa. Com relao a sintonia fina das equipas, outra coisa que fizeram na montagem das equipas foi agrup-las por cliente. Isso faz com que a cultura de cada um dos clientes seja absorvida de forma mais visceral pela equipa, resultando em projetos bem mais aderentes aos objetivos das suas contratantes.

Os resultados forma satisfatrios obteve-se uma satisfao por todos os integrantes do projeto na aplicabilidade do Scrum. O projeto foi entregue dentro do prazo e do oramento melhor do que os previstos.

Constatou-se uma maior participao do cliente no processo de desenvolvimento do software proporcionando um acompanhamento em alto nvel do andamento das atividades realizadas. Alm disso, observou-se a satisfao do cliente na solicitao das modificaes dentro de prazo hbil para realiz-las, alm do recebimento de funcionalidades totalmente implementadas no final das Sprints. Um fator caracterstico do Scrum que apresentou-se satisfatrio para o cliente trata-se do tempo fixo estimado para as Sprints.

A equipa evoluiu profissionalmente se tornando mais segura com relao capacidade de estimativa e auto gerenciamento, descartando a necessidade de atribuio de tarefas pelo gerente. Esse crescimento foi gradativo no decorrer das Sprints.

Aumentou tambm a segurana no que estava desenvolvendo e no conhecimento dos requisitos. Isto proporcionou um menor retrabalho por no desperdiar tempo no desenvolvimento de requisito confuso. O aumento da segurana aumentou o comprometimento e o foco com o projeto. Alm do mais, a equipa, depois de experimentar o Scrum, quer sempre que possvel, seguir esta prtica nos novos projetos.

O gerente apontou a facilidade em solucionar os impedimentos do projeto, haja vista que os mesmos eram identificados precocemente e no apresentava impactos nas demais atividades. Todos os integrantes tinham conhecimento do impedimento e atravs de uma ao em conjunto o impedimento era solucionado o mais rpido possvel. Alm disso, o gerente relatou a facilidade de extrair informaes gerenciais do projeto atravs dos quadros adotados pela metodologia gil. Isto permite aos participantes do Scrum saber exatamente o que est acontecendo e fazer no local os ajustes para manter o projeto na direo dos objetivos desejados.

RUP e XP - Uma viso geral

Atualmente nas empresas necessrio que se tenha algum nvel de processo, visando como objetivo a qualidade no desenvolvimento de software. Os processos Rational Unified Process (RUP) e eXtreme Programming (XP) so ferramentas muito conhecidas e utilizadas na comunidade de desenvolvimento de software atual.

O Rational Unified Process um framework j difundido e utilizado no mercado nacional e internacional de desenvolvimento, que pode ser adaptado a vrios tipos de projetos. Podem ser derivados do RUP processos para todos os tamanhos de projetos, pois este framework define uma vasta lista de papis, mecanismos, atividades e fluxos. Contudo, o Rational Unified Process muito complexo por conter uma srie de atividades, papis e mecanismos e costuma ser visto como um processo pesado e burocrtico, e identificar que elementos devem ser usados em cada projeto uma tarefa difcil.

Em contrapartida, o eXtreme Programming aparece como uma alternativa mais leve para equipas de tamanho pequeno e mdio porte, que desenvolvem software em um contexto de requisitos vagos e rapidamente modificados. O eXtreme Programming enfatiza a codificao e os testes de cdigos, e tambm considera uma presena constante dos clientes no desenvolvimento. Pela caracterstica de simplicidade que esta tcnica apresenta, poucos mecanismos, papis e atividades so definidos. O eXtreme Programming tem obtido reconhecimento atravs de sucessos alcanados por pequenos projetos em contextos de grandes mudanas de requisitos. Entretanto, a leveza deste mtodo e o foco em cdigo tornam outros aspetos importantes de um projeto, como a gesto de requisitos e a construo da arquitetura, que so pouco enfatizados.

5.1 APLICAO DE RUP NO PTROJECTO BASEADO EM SCRUM

Como soluo alternativa poderamos adotar o Rational Unified Process, personalizando para as necessidades especficas. Tambm pode-se implantar um programa para prover treinamento e servir como guia para equipas do projeto. Durante o processo, os instrutores ensinaro equipa de desenvolvimento os primeiros passos para usar a nova metodologia. Depois que os membros das equipas adquirirem experincia com um ou dois projetos com a ajuda dos instrutores, eles j se tornam preparados para desenvolver sem acompanhamento.

Sendo assim o RUP dever ser personalizado de acordo com as necessidades especficas, usamos a metodologia RUP com gestores de projetos, times de servio e experts para personaliz-la e adequ-la s necessidades da empresa.

Para lidar com os riscos de projeto deve ser criada uma ferramenta para o mapeamento de caso de uso para os riscos. Dirigindo-se a riscos precocemente no ciclo de vida do desenvolvimento, e dando prioridade aos casos do uso baseados no retorno no investimento, as equipas do desenvolvimento devero estabelecer uma arquitetura estvel, dando mais prioridade entrega das funcionalidades crticas. Com isso, a empresa passa a identificar e enderear os riscos de projeto com mais rapidez no processo de desenvolvimento e as equipas passaram a entregar as solues a tempo e atingir os padres de qualidade.

Mostramos um diagrama de fluxo para o planeamento e gesto com RUP do projeto implementado com SCRUM pela AG2.

5.2 COMPARATIVO ENTRE RUP E XP E SUAS APLICAES

As metodologias RUP e XP tm o seu funcionamento baseado em iteraes, so orientadas ao cliente e baseadas em papel. Uma anlise superficial nos diria que tratam a dinmica de desenvolvimento de software da mesma forma. Porm atravs da anlise dos tpicos descritos pelo presente captulo as diferenas sero verificadas por aspetos como a forma e frequncia que os mecanismos so gerados, quantidade de papis, etc.

O ciclo de vida de um projeto eXtreme Programming uma das abordagens ainda muito discutidas por grupos que adotam esta metodologia. O ciclo de vida eXtreme Programming bastante curto e, primeira vista, difere dos padres dos modelos de processos convencionais. No entanto, esta abordagem pode fazer sentido em um ambiente onde as mudanas de requisitos do sistema so fatores dominantes.

O ciclo de vida da XP est basicamente dividido em quatro fases, planeamento, testes, codificao e projeto. Na fase de planeamento, os requisitos do cliente so cuidadosamente coletados medida que so fornecidos. A seguir, os testes so elaborados a partir das especificaes do cliente, e a fase de codificao realizada visando atender esses testes. E, por fim, o sistema novamente projetado (ou reconstrudo) medida que novas funcionalidades so incorporadas.

O ciclo de vida do RUP apresenta-se dividido em duas dimenses, as quais refletem as duas vises em que um sistema pode ser descrito: componentes dinmicos, que representam o tempo e mostram os aspetos dinmicos, como ciclos, fases, iteraes e marcos, e componentes estticos, que representam os aspetos estticos, como: trabalhadores, atividades, mecanismos e fluxos.

O RUP iterativo e incremental, cada fase dividida em iteraes

InceptionElaborationConstructionTransitionTransitioniterationPreliminaryiterationArchitect.iterationArchitect.iterationDevel..iterationDevel..iterationDevel..iterationTransitioniteration

Concepo (define o escopo do projeto) Elaborao (detalha os requisitos e a arquitetura) Construo (desenvolve o sistema) Transio (implanta o sistema)

5.3 VANTAGENS E DESVANTAGENS PARA O CASO EM ESTUDO

VANTAGENS:

1. Motivao Os programadores se sentem muito mais motivados devido ao seu interesse de entregar o Sprint no prazo.

2. O projeto pode ser visualizado Dentro da organizao o projeto pode ser observado por todos. Em outras metodologias esta possibilidade no existia.

3. Ausncia significante de bugs Como a qualidade mais importante do que o prazo de entrega, o produto apresenta uma diminuio significativa de erros.

4. Alterar as prioridades Os programadores podem manejar as prioridades sem problemas, garantindo assim que sprints que ainda no foram finalizados possam ser alterados sem problemas.

DESVANTAGENS:

1. Prazo Como a qualidade mais importante do que o resultado, pode ser que os prazos no sejam estipulados de forma coerente, levando a um atraso do resultado final, o que pode deixar os clientes com uma certa raiva, mas isso pode ser ajustado em equipa.

2. Desordem nas funes a presena de papis indefinidos nas funes presentes no projeto podem dar alguns problemas relacionados a comunicao interna e deixar os programadores confusos quanto as suas tarefas.

3. Ausncia de documentao A falta de documentaes sobre o andamento do projeto pode ser um grande problema. Por isso importante documentar os aspetos que sejam verdadeiramente importantes, mas no deixar de lado a documentao de tudo o que est acontecendo. Porque depois pode ficar difcil voltar num determinado instante do projeto e lidar com a situao de no ter aquele momento documentado.

5.4 NECESSIDADE OU NO DE ADAPTAO DA METODOLOGIA

Muito se fala sobre a adaptao de metodologias geis em ambientes corporativos com o objetivo de agilizar e simplificar processos existentes no ambiente organizacional de trabalho. Porm, antes de adaptar necessrio refletir sobre alguns problemas que certamente sero enfrentados durante esse processo. As metodologias clssicas esto focadas em seguir o plano inicial, construir uma documentao detalhada, dar mais valor a ferramentas e processos, bem como negociao de contratos. Por outro lado, os mtodos geis buscam a adaptao rpida a mudanas, colaborao com o cliente, alm de dar mais valor a indivduos e interaes, bem como ao progresso do produto ou servio sendo desenvolvido.

Diante desse cenrio conflituoso, os mtodos geis enfrentam diversas barreiras para penetrar em ambientes culturalmente clssicas. Talvez seja esse o maior desafio, a mudana cultural. Em outras palavras, preciso conhecer bem o ambiente que dever sofrer as mudanas e saber claramente quais so os objetivos dessa transformao. A mudana exige desaprender valores, premissas e comportamentos antigos antes que se possa aprender os novos. Os elementos mais importantes dessa mudana cultural so: apoio executivo e treinamento. Eis aqui outro grande problema enfrentado pelos mtodos geis durante sua implantao. difcil obter o apoio das altas instncias da organizao, porm fundamental. Os executivos devem liderar a transformao pela mudana de seus prprios comportamentos e assim inspirar os demais colaboradores.

A gesto das equipas, tema de grande estudo nos dias de hoje, tambm visto como outra imensa barreira. o trabalho mais rduo e complexo de se realizar nesse processo. de conhecimento geral que as pessoas representam uma grande fonte de problemas. Diante desse cenrio, deve figurar o papel do lder agregador e conciliador que motiva e inspira seus liderados a formar equipes homogneas e com um objetivo comum bem definido.

Interagir com outros departamentos da organizao outra tarefa complicada. Por isso, a mudana cultural da organizao apoiada pela alta cpula fundamental. Criar uma linguagem e atitudes comuns que sejam compreendidas por todos facilita as interaes entre indivduos de naturezas diferentes. Isso ajuda a criar um clima de harmonia e cooperao em prol de um objetivo comum traado no planeamento estratgico da empresa.

Outro ponto fundamental a interao com clientes, pois so eles quem mantm a empresa viva! No a empresa que define o mercado. o cliente. (Peter Drucker). Os clientes devem participar ativamente do processo de construo de produtos, servios ou resultados, fornecendo feedback constante. Assim como no relacionamento com os funcionrios internos, a relao deve ser de cooperao no sentido de produzir os resultados desejados. Evitar conflitos e buscar solues conjuntas so pontos relevantes dessa relao.

vlido ressaltar que esses so os principais, no nicos, problemas enfrentados pelos mtodos geis durante sua implantao. Sendo assim, cabe queles que pretendem aplicar esses mtodos no seu ambiente de trabalho estarem preparados para as diversas situaes conflituosas que iro surgir durante esse processo transitrio e ser persistente e determinado.

CONSIDERAES FINAIS

O objetivo deste trabalho no apontar um mtodo nem mostrar que um anula o outro, visto que suas caractersticas devem ser adotadas em situaes de desenvolvimento diversas. importante para o desenvolvedor conhecer o que h de melhor nos dois mundos e suas limitaes a fim de que a adoo de um mtodo possa atender suas expectativas de gerenciamento, custo e prazo.

Para que surja interesse nas grandes organizaes pela abordagem dos mtodos geis muitas respostas ainda devem ser obtidas como por exemplo: como gerir o risco, como viabilizar a comunicao em locais dispersos, como garantir a certificao, dentre outras. Todo novo paradigma exige um tempo de maturao, em que os pioneiros acreditam na ideia e quebram barreiras no intuito de adquirir a confiana do mercado.

BIBIOGRAFIA

BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponvel em: http://www.agilemanifesto.org/ Acesso em: 7/06/15.

KRUCHTEN, Philippe. The Rational Unified Process An Introdution. Massachusetts, Addison Wesley, 2000.

MAGALHES, A.P.F. RUXP: Integrando o RUP e o XP em uma metodologia para o desenvolvimento de software. Monografia de Especializao. 2003.

SOARES, M. S. Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software. Revista Eletrnica de Sistemas de Informao, 2004.

SOARES, Michel dos Santos. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Revista Eletrnica de Sistemas de Informao,2009.

SOMMERVILLE, I. Engenharia de Software. Editora Addison-Wesley. 2003. XP. Extreme Programming.Disponvel em: http://www.extremeprogramming.org/ Acesso em: 07/06/15.