Gerenciamento de implantao de sistemas ERP com SCRUM

Fbio Aguiar, Evandro Sobreiro Curso de Sistemas de Informao - Instituto de Estudos Superiores da Amaznia (IESAM) 66055-260 Belm PA Brasil
fabioaguiar@gmail.com, esobreiro@gmail.com

Abstract. The proposal of this article is to apply the methodology Scrum to manage projects for the implantation of ERP systems, since the suppliers of ERP systems together with its customers, has had several problems in the stage of deployment, and one of the points that have been conflicting, is the managing project through traditional methods, or the time in the deployment phase. However, seek to apply a management so agile using the methodology Scrum, because through their practices has achieved great results in projects of software. With this, do a case study results to terms with real application of the practices of Scrum in the management of projects for the implantation of ERP. Resumo. A proposta desse artigo aplicar a metodologia Scrum para gerenciar projetos de implantao de sistemas ERP, visto que as fornecedoras de sistemas ERP junto com seus clientes, tem tido vrios problemas na etapa de implantao, e um dos pontos que tem sido conflitante, o gerenciamento de projeto atravs da metodologia tradicional, ou seja, o tempo gasto na fase de implantao. Contudo, buscamos aplicar um gerenciamento de forma gil usando a metodologia Scrum, pois atravs de suas prticas vem alcanado grande resultado em projetos de software. Com isso, realizamos um estudo de caso para termos resultados real com aplicao das prticas do Scrum no gerenciamento de projetos de implantao de sistemas ERP.

1. Introduo
As empresas em geral esto cada vez mais buscando agregar valores para seu negcio e aumentar sua competitividade, e muitas esto buscando solues como ERP, por vrios motivos, como: ter as informaes centralizadas, eliminar tarefas repetitivas, reduzir o tempo de respostas, terem informaes em tempo real, auxiliar a empresa a tomada de deciso, melhorar os fluxos das informaes dentro da empresa. ERP (Enterprise Resource Planning) no Brasil mais conhecido como Sistemas Integrados de Gesto Empresarial, como o nome nos diz, integram e gerenciam todos os processos operacionais, produtivos, administrativos, comerciais e verticais da empresa. Com isso, muitas empresas tm implantado sistemas ERP, mas tem passado por grandes problemas no decorrer da implantao. Implantaes que so estimadas em implantar em seis meses, e quando se d conta j se passaram dez meses e ainda no tem previso de termino. Isso tem feito com que haja um desgaste muito grande na relao entre fornecedora de ERP e cliente e um enfraquecimento na aliana adquirida. Em muitos dos casos, tm sido abortadas implantaes onde j foram gastos grandes valores monetrios. O gerenciamento de projeto tradicional tem acarretado vrias questes conflitantes nessa fase, como: trabalhos muito complexos, recursos financeiros no adequados, metodologia carregada na documentao, sempre ver o projeto como o todo, seguir especificao predefinida. Tm-se observando um grande crescimento de mtodos de gerenciamento e desenvolvimento gil, onde podemos notar uma nova forma de desenvolver e gerenciar software, devido ao ritmo acelerado de mudanas e inovaes no mercado, organizaes e tecnologia. Os mtodos geis se destacam, pois aceleram os prazos de entrega do software atravs ciclos de interaes, funcionalidades e simplicidade, integrao continua do cliente assim aumentando sua satisfao e dos evolvidos, e ainda valorizam a flexibilidade para lidar com mudanas de requisitos durante o processo. importante destacar no desenvolvimento de software sobre os potenciais benefcios dos Mtodos geis, fornecendo ao engenheiro de software novas percepes e idias quanto a solues de problemas comuns como garantia de qualidade, satisfao do cliente, e comprometimento no prazo de entrega do software. Baseado nessas informaes emergiu o interesse de nossa parte em adaptar uma metodologia de gerenciamento de projetos gil em implantao de sistemas ERP, para tentarmos implantar um sistema de ERP de forma gil. Esse artigo apresenta uma adaptao das prticas de Scrum no gerenciamento de implantao de sistemas ERP e relata as experincias alcanadas nessa adaptao.

2. O Gerenciamento Tradicional de Projetos segundo o PMBOK

O PMBOK [2004] foi criando para servir de um guia completo voltado para o gerenciamento de projeto tradicional, estabelecendo uma base cultural para gerenciamento de projeto para as empresa no mundo tem sido utilizado com bastante sucesso. O PMBOK Abrange um conjunto de conhecimento e prticas voltado para o gerenciamento de projeto, que auxiliam no que deve ser feito, e no como fazer. O PMBOK abrange nove reas de conhecimento, tais como: Integrao, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicaes, Riscos e Aquisies.

Essas reas esto divididas em cinco grandes grupos: Iniciao, Planejamento, Execuo, Controle e Encerramento. A tabela 1 faz um comparativo entre gerente de projeto segundo o PMBOK e segundo o mtodo gil.
rea do processo
ESCOPO

Gerenciamento Tradicional
Bem definido nas fases iniciais do projeto e formalizado atravs de WBS (Work Breaksown Structure). Cronograma detalhado para a realizao de todo o projeto. Monitorao das alteraes para que no afete o custo planejado. Processos de verificao e validao e plano de testes. Anlise de riscos durante todo o ciclo de vida do projeto. Documentado e formal. Papis claros e bem definidos. Controle por contrato e escopo bem definido e documentado. Plano do projeto detalhado e controle total do projeto do gerente.

Gerenciamento gil
Escopo definido em alto nvel e os requisitos so priorizados e definido de forma interativa. Necessita de maior controle gold plating. Cronograma orientado por produto entregas incrementais de 1-4 semanas. com

TEMPO CUSTO QUALIDADE RISCOS COMUNICAO RECURSOS HUMANOS AQUISIO

Maior controle em funo da rapidez na incorporao de alteraes. Programao em pares, testes incrementais e refatorao. Aplica-se o mesmo conceito do gerenciamento tradicional. Implcita, interpessoal e colaborativa. Confiana nos membros da equipe e ambiente colaborativo. Presena do cliente, volatilidade de requisitos e pouca documentao tornam o processo um desafio. Plano do projeto evolutivo e gerente do projeto atuam como facilitador.

INTEGRACAO

Tabela 1: Comparativo entre o Gerenciamento de Projetos Tradicional e gil [referncia no final]

4. A Escolha pelo mtodo Scrum

Scrum um framework com conjunto de prticas objetivas, papis bem definidos e totalmente adaptveis, seu ciclo de vida se resume em iteraes e funcionalidades incrementais, um mtodo gil voltado para gerenciamento de projetos. Com isso, permite um melhor acompanhamento do que est acontecendo durante o projeto, facilitando o ajuste durante o projeto e fazendo com que alcancemos de forma gil os objetivos. Ou seja, Scrum no diz exatamente o que fazer, no ir resolver todos os problemas, mas com certeza os problemas sero mais facilmente identificados.

4.1. Ciclo do processo Scrum

O Scrum baseado em interaes bem definidas, com durao de uma a quatro semanas, tambm chamados de Sprint. Antes de cada Sprint realizado todo planejamento inicial do objetivo que o cliente almeja alcanar. A partir desse momento criado o Product Backlog, baseado na viso de negcio do cliente, com todos os requisitos a serem implementados no projeto. Aps preparado todo Product Backlog, realizado a primeira reunio de planejamento do Sprint, onde so selecionados os itens pelo Product Owner e o Scrum Master a serem desenvolvidos que agregaro mais valor ao negcio do cliente naquele momento e depois colocado na ordem de maior prioridade, em seguida realizamos a segunda reunio de planejamento do Sprint, onde a prpria equipe estima o esforo das tarefas, faz a diviso das tarefas entre os diferentes membros e compromete-se a concluir as tarefas no final da interao e define de quanto

tempo vai ser a Sprint (interao de uma a quatro semanas). A partir desse momento criado o Sprint Backlog que so as tarefas selecionadas pela equipe para ser executada na Sprint. A prxima etapa a execuo do Sprint com base nos itens do Sprint Backlog, durante a execuo as tarefas so acompanhadas por reunies dirias que no podem passar 15 minutos e a equipe deve responder trs perguntas diante dos envolvidos: O que voc desenvolveu at o momento? O que voc ir desenvolver? Quais impedimentos voc est tendo? Com base nessas perguntas o Scrum Master consegue ter uma viso de como est o andamento do projeto, conhecendo os impedimentos que esto acontecendo. No final da Sprint realizada uma reunio de Reviso da Sprint, com o objetivo, de mostrar ao Product Owner e todas as partes interessadas as funcionalidades que foram concludas. A equipe apresenta os resultados obtidos durante o Sprint e possveis modificaes nos itens do Product Backlog. Logo aps realizado outra reunio de Retrospectiva do Sprint, onde feito uma lavagem de roupa suja, onde os membros da equipe devem responder duas perguntas: O que aconteceu de positivo durante esse Sprint? O que pode ser melhorado para o prximo Sprint? A figura 1 mostra como funciona o ciclo do processo do Scrum.

Figura 1: Ciclo do processo Scrum [referncia no final]

Referencia para um entendimento mais detalhado do Scrum: http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf

5. Estudo de Caso
Aplicamos o Scrum em um projeto de implantao ERP, especificamente em um mdulo de Recursos Humanos. Tivemos vrios resultados satisfatrios em relao utilizao das prticas de Scrum voltada para o gerenciamento. A participao do cliente como um papel em relao metodologia, nos trouxe um melhor relacionamento. Durante o projeto o Scrum facilita o que seria o maior desafio durante o levantamento dos processos, que conseguir extrair informaes concretas sobre o que se deve implantar. Um dos pontos fortes do Scrum so as interaes. Portanto, dividimos o projeto em partes, conforme as tarefas iam sendo implantadas, entregando partes do projeto ao cliente e em seguida recebendo o feedback, isso nos deu uma viso melhor para continuarmos, e permitiu identificar e aprender de forma gil, as necessidades do cliente e entregando aquilo que tinha mais valor ao seu negcio. Um dos pontos que nos despertou interesse em aplicar scrum foi o interesse em diminuir o risco de implantar requisitos erradas ou que no agregaria valor ao negcio do cliente, com isso a participao direta do cliente e a entrega das funcionalidades por interaes diminuem bastante o desperdcio de recursos e uma futura demanda maior de ocorrncias no departamento de suporte, muitas das vezes tentando re-implantar atravs do suporte. O Scrum traz uma facilidade muito grande na remoo de impedimentos. O que est ou ir impedir o andamento do projeto, atravs das reunies dirias, pode ser acompanhado dia a dia com os membros que estavam envolvidos, o andamento, os impedimentos, e em que tarefa continuar. Notamos uma motivao maior da equipe e dos envolvidos, pois o Scrum d a oportunidade as pessoas no controle de suas atividades, percebemos que rpido a equipe comeou a se auto-gerenciar. Tomamos como base o cronograma como nosso Product Backlog, na reunio de planejamento do Sprint. A prpria equipe selecionou as tarefas e se comprometerem em entregar no final daquele Sprint, isso fez com que o projeto andasse, pois a equipe se mostrava sempre motivada em concluir a meta que eles prprio tinham dado, e assim se tornando equipe auto-organizadas e auto-gerenciveis. Realizamos uma comparao entre duas empresas na implantao de sistema ERP do mdulo de folha de pagamento, uma utilizando a metodologia tradicional e outra a metodologia Scrum. As empresas envolvidas pertencem a um mesmo grupo, sendo as duas de ramo de atividades diferentes e esforos diferentes, pois na empresa onde foi utilizada a metodologia Scrum a implantao se deu em duas bases de dados distintas. A utilizao da metodologia Scrum foi utilizada na implantao para podermos avaliar se podia trabalhar com a metodologia sem que estourasse o prazo, sem que o custo com a implantao fosse alto ao cliente e se no final da implantao haveria uma implantao de boa qualidade e o cliente satisfeito, sem a necessidade de gerar uma documentao abrangente.

Vamos identificar as empresas de A e B, sendo a metodologia tradicional aplicada na empresa A e a metodologia Scrum aplicada na empresa B. Para poder implantar o sistema ERP nas empresas, uma linha de raciocnio mostrada na tabela:
No Sistema Horas Estimadas 120 hrs 1 hr 1 hr 19 hrs 2 hrs 2 hrs 6 hrs 3 hrs 1 hr 1 hr 1 hr 6 hrs 2 hrs 1 hr 1 hr 1 hr 1 hr 5 hrs 2 hrs 1 hr 1 hr 1 hr 14 hrs 2 hrs 1 hr 1 hr 2 hrs 1 hr 1 hr 2 hrs 1 hr 1 hr 4 hrs 1 hr 2 hrs 1 hr 4 hrs 3 hrs 1 hr 19 hrs 5 hrs Horas Executadas Empresa A 150 hrs 2 hr 2 hr 30 hrs 2 hrs 2 hrs 10 hrs 5 hrs 2 hr 2 hr 1 hr 8 hrs 2 hrs 2 hr 2 hr 1 hr 1 hr 10 hrs 5 hrs 2 hr 2 hr 1 hr 27 hrs 3 hrs 1 hr 2 hr 2 hrs 1 hr 1 hr 7 hrs 5 hr 2 hr 9 hrs 2 hr 5 hrs 2 hr 6 hrs 4 hrs 2 hr 19 hrs 10 hrs Horas Executadas Empresa B 133 hrs 1 hr 1 hr 19 hrs 1 hrs 1 hrs 6 hrs 3 hrs 1 hr 1 hr 1 hr 5 hrs 1 hrs 1 hr 1 hr 1 hr 1 hr 7 hrs 3 hrs 2 hr 1 hr 1 hr 19 hrs 4 hrs 2 hr 2 hr 2 hrs 1 hr 1 hr 4 hrs 3 hr 1 hr 4 hrs 1 hr 3 hrs 1 hr 5 hrs 4 hrs 1 hr 19 hrs 6 hrs 6.03.04.3 6.03.05.1 6.03.03.2 6.03.04.1 6.03.04.2 6.03.02.2 6.03.03.1 6.03.01.2 6.03.02.1 6.02.04.4 6.03.01.1 6.02.03.5 6.02.04.1 6.02.04.2 6.02.04.3 6.02.02.4 6.02.03.1 6.02.03.2 6.02.03.3 6.02.03.4 6.02.01.1 6.02.02.1 6.02.02.2 6.02.02.3 6.01.01 Seq

6 6.01 6.01.01 6.02 6.02.01 6.02.01.1 6.02.02 6.02.02.1 6.02.02.2 6.02.02.3 6.02.02.4 6.02.03 6.02.03.1 6.02.03.2 6.02.03.3 6.02.03.4 6.02.03.5 6.02.04 6.02.04.1 6.02.04.2 6.02.04.3 6.02.04.4 6.03 6.03.01 6.03.01.1 6.03.01.2 6.03.02 6.03.02.1 6.03.02.2 6.03.03 6.03.03.1 6.03.03.2 6.03.04 6.03.04.1 6.03.04.2 6.03.04.3 6.03.05 6.03.05.1 6.03.05.2 6.04 6.04.01

RM Labore PARMETROS GERAIS Parametrizao RM Labore e Globais TABELAS DE CLCULO PARAMETROS Valores Fixos e Tabelas de Clculo EVENTOS Incluso e Parametrizao dos Eventos Tabela Dinmica Simulao Validao SINDICATOS Incluso e Parametrizao dos Sindicatos Definio Grupo de Mdias Incluso e Parametrizao dos Eventos de Mdias Simulao Validao FRMULAS Incluso de Frmulas do Sistema Incluso de Frmulas de Setenas SQL Simulao Validao FOLHA DE PAGAMENTO PARMETROS Definio do Regime e Perodo de Pagamento Incluso do Grupo de Eventos ADIANTAMENTO Simulao Validao RESCISO Simulao Validao FRIAS Parametrizao dos Eventos de Frias Simulao Validao FOLHA MENSAL Simulao Validao ENCARGOS SOCIAIS CADASTROS

6.04.01.1

Cadastros Gerais - Sees e Funcionrios

5 hrs

10 hrs

6 hrs

6.03.05.2

Tabela 2: Parte do Cronograma das Atividades [Documento da empresa fornecedora do ERP]

A tabela acima o cronograma da implantao do mdulo de RH e foi utilizada tanto na empresa A como na empresa B. Para a metodologia tradicional ela o Cronograma do Projeto, para a metodologia Scrum assumimos como o nosso Product Backlog. Na reunio de abertura, na empresa A foi estimado o que seria feito naquela semana e verificado o levantamento executado anteriormente, ou Reunio de Planejamento na empresa B, onde foram estimadas quais tarefas seriam feitas na Sprint e retiradas s tarefas de maior prioridade e definimos tambm que cada Sprint teria interaes de uma semana, formando assim o nosso Sprint Backlog (os itens a serem implantados na Sprint). Com as reunies iniciais realizadas e tarefas definidas foi iniciada a implantao nas empresas, lembrando que a implantao ocorreu em dias diferentes, realizando parametrizaes, cadastros, simulaes e validaes de acordo com o Cronograma do Projeto ou Product Backlog, como mostra a Tabela 3.

5. Analise dos resultados e comparaes

Horas executadas na im plantao do sistem a ERP Estim adas 120 Horas

30 Empresa A 13 Empresa B

Figura 2: Resultados quantitativos

Uma das prticas do Scrum que mais se destacou em relao ao tradicional foi a reunio diria, como a implantao se fazia em semanas diferentes nas empresas se deixava lista de tarefas para os usurios (time) at a volta do consultor de implantao. Na metodologia tradicional a lista de tarefas s verificada se os usurios a executaram, ou melhor, finalizou a lista. Caso tenha concludo, ter ser terminada pelo usurio e a implantao fica comprometida em relao ao tempo devido que aquela tarefa terminada era um passo para outra e iniciao dos processos de RH. Ainda na metodologia tradicional h uma reunio intermediria, mas esta somente entre o consultor e o gerente de projeto que tem como objetivo avaliar o desempenho das atividades desenvolvidas pelos Consultores, onde os mesmos informam ao Gerente do Projeto, atrasos ou adiantamentos, dificuldades encontradas e os pontos de ateno do projeto, de forma que o Gerente de Projeto possa tomar as providncias necessrias ao bom andamento do projeto, com a metodologia gil a coisa bem diferente, mesmo com a lista de tarefas em mos a primeira pergunta da daily meetings (O que fizeram desde a ltima reunio?) era respondidas pelo time (usurios) s vezes acrescentando coisas que no estava na lista, logo aps o consultor

de implantao fazia a segunda pergunta (O que iremos fazer hoje?) ao time, sendo respondida pelos mesmos usurios. Nessa segunda pergunta travamos objetivos para aquele dia seguindo sempre o cronograma inicial (ver tabela 3), a terceira pergunta (Quais impedimentos?) era respondida, nesse ponto a um problema para o scrum master (consultor de implantao), como se trata de um departamento de Recursos Humanos (pode ser considerado outros departamentos), h muita interferncia de pessoas externas, gente que s vezes no esto nem envolvidas com a implantao, s que os assuntos eram pertinentes ao setor, mas mesmo com essas situaes o objetivo daquele dia era conseguido. A reunio diria era feita sempre no inicio do dia fazendo-se as trs perguntas e no ultrapassando o tempo mximo estipulado na metodologia Scrum, 15 minutos. Desta forma tentvamos resolver os problemas para que a implantao ocorresse sem estourar o prazo e tempo, e os usurios (time) estavam sempre informados de como estava o andamento da implantao. Outras prticas de grande importncia ao projeto foram as reunies de reviso e restropectiva do scrum. Na metodologia tradicional, existe uma reunio chamada de reunio de avaliao, tendo ela com o objetivo de registrar e acompanhar a evoluo do projeto, os resultados parciais obtidos, a avaliao do cronograma e a qualidade obtida. Garantindo o cumprimento do Projeto de Implantao e registrar o encerramento das Fases do Projeto gerando documentaes sobre o sistema, esta reunio no tem dia definido podendo ser na primeira semana da implantao, ou somente em seu trmino. Com a reunio de reviso, realizada no final de cada sprint, foi realizada a apresentao de como estava a implantao, se o que estava previsto naquela semana resultou em algo que torne valor ao Cliente e j funcionando mesmo que seja parcial. Nesta reunio foi definido tambm o que seria feito na prxima sprint, sempre analisando o Cronograma do projeto apresentado acima. No final da implantao realizada a reunio de encerramento, este para metodologia tradicional, que visa formalizar o encerramento do projeto, bem como apresentar os resultados obtidos, discutir as falhas e os problemas ocorridos, de modo a fornecer dados e experincias sobre o gerenciamento de projetos. Para a metodologia agil, h a reunio de restropectiva que foi realizada aps o trmino da implantao no Cliente naquela semana, foram levantadas juntamente com os usurios as duas perguntas dessa reunio: - O que aconteceu de bom durante o ltimo Sprint? - O que pode ser melhorado para o prximo Sprint? Avaliando estas perguntas os usurios responderam e tudo foi registrado para melhorar o processo/time e/ou produto. Na reunio de reviso do Sprint, todos estavam motivados e ansiosos para verem o resultado final do Sprint, que eles prprios tinham se comprometido em concluir. Na reunio de retrospectiva do Sprint, tambm alcanamos o objetivo, pois vimos juntos os erros que cometemos e os acertos, e com isso deixamos todos motivados para o prximo Sprint. Vale ressaltar que na reunio de encerramento somente realizado no final da implantao, no caso da reunio de retrospectiva realizado a cada interao (Sprint). As duas implantaes, somente do mdulo de folha de pagamento onde foram estimadas em 120 horas foram finalizadas, sendo que a empresa A o projeto ultrapassou 30 horas do prazo previsto, ou seja, o tempo para implantar todo o sistema

acabou sendo maior do que o fechado com o Cliente, gerando assim um custo maior ao mesmo, e como o usurio no foi to participativo como na metodologia scrum, o sistema perdeu muito a sua qualidade visto que muitas coisas o usurio no explanava e os erros foram sendo verificados aps o trmino da implantao. Na empresa B, houve uma quantidade horas maior, 13 horas, menos da metade da empresa A, mesmo com essa quantidade de horas a adequao do processo scrum ajudou em muito aos usurios, quanto ao consultor de implantao, pois com as reunies dirias foi possvel identificar o erro mais rpido, caso houvesse, e logo corrigido, j que com a metodologia tradicional isso no ocorria, os usurios que tambm fizeram parte do time, tiveram grande valor na implantao e a satisfao foi bem maior que na outra empresa. As duas empresas tiveram o sistema entregue conforme o planejado e o desejado, mas como na empresa B o envolvimento do usurio foi maior, este no ficou com qualquer tipo de dvida na operao e manuteno do mesmo, mas na empresa A o usurio ficou com muitas dvidas e o sistema, apesar de ter sido entregue no estava como ele visualizava. A utilizao das prticas do Scrum foi um desafio na implantao de Sistemas ERP, como essa foi a primeira experincia no se sabe ao certo se as prticas do Scrum vai ser bem aceitos em outras empresas. Os resultados aqui obtidos podem variar de empresa para empresa, dependendo muito de como o processo utilizado pelo Cliente.

10. Concluses
Hoje as empresas que fornecem sistemas ERP no querem somente vender, mais sim entreg-los. A implantao tem sido o grande problema que impacta na entrega dos sistemas ERP, com base nisso surgiu o interesse na busca de uma metodologia voltada para gerenciar projetos de implantao de sistemas ERP de forma gil. Tentamos trazer esse estudo para um projeto real de implantao de ERP, permanecemos com a metodologia tradicional, pois j havia comeado e ao longo do projeto de comeamos a aplicar as prticas de Scrum, onde nos trouxe um resultado satisfatrio. Ficamos muitos satisfeitos com a experincia e isso nos traz mais motivao para o prximo projeto, tivemos falhas tambm, onde ter implantado as prticas do Scrum em um projeto que j estava em andamento, mas mesmo assim, foi uma grande experincia que tivemos em tentar adaptar as prticas de Scrum em projeto de implantao de ERP. Comeamos o projeto apenas focado em implantar em um curto espao de tempo, conseguimos alcanar o nosso foco, mas o que chamou nossa ateno foi com as prticas do Scrum aplicadas, nos dando um domnio melhor do projeto e uma interao e participao melhor do cliente. O prximo passo ter como base esse vivencia que tivemos e tentar aplicar em outros projetos o Scrum como um todo desde o planejamento at o a fase incremental final, e a prxima proposta fazer a juno das prticas do Scrum com o PMBOK.

Referncias
1. Agile Manifesto, Manifesto for Agile Software Development, 2001. Disponvel em http://agilemanifesto.org/ [Maio, 2007]. 2. MOUNTAIN Goat Software, The Scrum Development Process, Disponvel em http://www.mountaingoatsoftware.com/Scrum [Junho, 2007]. 3. SCHWABER K., Agile Project Management With Scrum, Microsoft, 2004. 4. VERSIONONE, Pesquisa do Estado do Desenvolvimento gil, The State of Agile Development, Disponvel em ttp://www.versionone.net/pdf/StateofAgileDevelopmentSurvey.pdf [Fevereiro, 2007] 5. KNIBERG, Henrik., Scrum and XP from the Trenches, How we do Scrum, Nov., 2006, 90 p. 6. SCHWABER, K., and Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002. 7. BEEDLE, Mike et al. SCRUM: An extension pattern language for hyperprodutive software development. Disponvel em: htp://www.controlchaos.com [Agosto, 2007] 8. Riding. Gerenciamento e Equipes: Reunies geis. Disponvel em: http://members.cox.net/risingll/articles/AgilePortuguese.pdf [Agosto, 2007] 9. [SCHWABER 1996] Schwaber, Ken. Controlled chaos: living on the edge. Disponvel em: http://www.controlchaos.com/old-site/ap.htm. [Agosto, 2007] 10. [RISING 2007] Rising, L. The Scrum Software Development Process. Disponvel em: http://members.cox.net/risingl1/articles/IEEEScrum.pdf. [Maio, 2007] 11. [PMI 2004] Project Management Institute, A Guide to the Project Management Body of Knowledge, 3 Edio, 2004. 12. [SCRUM 2007] Eclipse process framework team, Scrum: A lightweight process framework, Disponvel em <http://scrum.epfwiki.net/>. [OUTUBRO, 2007] 13. [COCHANGO 2006] Cochango, Scrum for team systems, http://www.scrumforteamsystem.com. [JULHO, 2007]