Chapter

1Scrum: Uma Metodologia Ágil para Gestão e Plane-jamento de Projetos de Software

Fabio Abrantes Diniz, Diego Grosmann, Thiago Reis da Silva e Íthalo BrunoGrigório de Moura

Abstract

Everyone knows that most software projects can be frustrating. Deadlines are rarelymet, software quality is not always ideal. Scrum is an agile development methodologythat focuses on teamwork, with self-managed teams and active participation of the client.Another important figure is the scrum master, whose function is to remove obstacles andprovide the necessary elements so that the team has the best performance possible. Theroutine begins with the Scrum product backlog, list of project requirements, ordered bypriority. From this list comprises the sprint backlog - requirements to be implementedin the next sprint (iteration), each sprint lasts about 30 days and after its end, featuresdeveloped are validated by the product owner (client, usually) and released, starting anew cycle.

Resumo

Todos sabem que, a maioria dos projetos de software pode ser frustrante. Prazos deentrega são raramente cumpridos, a qualidade do software nem sempre é ideal. Scrumé uma metodologia de desenvolvimento ágil, focada no trabalho em equipe, com equi-pes auto-gerenciadas e participação ativa do cliente. Outra figura importante é o scrummaster, que tem a função de eliminar obstáculos e proporcionar os elementos necessáriospara que a equipe tenha o melhor desempenho possível. A rotina de Scrum começa como product backlog, lista dos requisitos do projeto, ordenados por prioridade. A partirdesta lista é formado o sprint backlog – requisitos que serão implementados no próximosprint (iteração); cada sprint dura cerca de 30 dias e, após seu final, as funcionalida-des desenvolvidas são validadas pelo product owner (cliente, normalmente) e liberadas,iniciando-se um novo ciclo.

1.1. METODOLOGIAS ÁGEISEsta seção abordará uma visão geral sobre a metodologia ágil que começa com as declaraçõesdo manifesto ágil citadas abaixo.

Esta seção abordará uma visão geral sobre a metodologia ágil que começa com asdeclarações do manifesto ágil citadas abaixo.

As metodologias ágeis, criadas em 2001 [1], foram apresentadas formalmenteao público com o lançamento do Manifesto para o desenvolvimento ágil de software,freqüentemente chamado apenas de Manifesto Ágil. Esse modelo descreve um conjuntode abordagens para desenvolvimento de software:

• Indivíduos e interação entre eles são mais importantes que processos e ferramentas;

• Software em funcionamento é mais importante que documentação abrangente;

• Colaboração com o cliente é mais importante que negociação de contratos;

• Responder a mudanças é mais importante que seguir um plano.

De acordo com análise das abordagens do manifesto ágil as contribuições e suastendências [2] [3] [4] avaliadas abaixo são importante para o objetivo desse trabalho.

Indivíduos e interação entre eles são mais importantes que processos e ferramentas:Apesar da qualidade dos profissionais envolvidos no desenvolvimento do projeto afetardiretamente a qualidade do produto e o bom desempenho da equipe no projeto, ter ótimosprofissionais não é certeza de sucesso, pois estes dependem diretamente do processo. Umprocesso mal seguido pode fazer com que os desenvolvedores não sejam capazes de usarde todo o seu talento. Além da mistura certa do processo adequado com bons profis-sionais, é preciso que todo o grupo possa interagir perfeitamente entre si. Comunicaçãoé mais importante do que simples talento para programação. Logo, um desenvolvedormédio com bom relacionamento é bem melhor, trabalhando em equipe, é mais produtivoque um excelente programador trabalhando sozinho.

É importante levar em consideração que as ferramentas utilizadas são importantespara o sucesso final do projeto, mas elas não podem ter mais importância que seus uti-lizadores. Logo, mais importante que as ferramentas são a qualidade e o grau de interaçãoda equipe.

Software em funcionamento é mais importante que documentação abrangente: Adocumentação de um projeto é muito necessária para o sucesso do projeto, servindo comocomunicação entre o racional e a estrutura do sistema. Uma documentação legível paradescrever o sistema ainda se faz necessária na tomada de decisões do projeto. Porém,é preciso tomar muito cuidado com o excesso na documentação. De nada adianta umagrande quantidade de documentos que demoram muito tempo para serem gerados, se elesnão estão em sincronia com o que está sendo desenvolvido e o que foi especificado.

Documentos sem essa sincronia prejudicam a realidade do projeto, fazendo comque decisões erradas possam ser tomadas. O Manifesto sugere é que somente a documen-tação necessária seja gerada e esteja sempre sincronizada com o sistema, pois a transfer-ência de conhecimento sobre o projeto é feita trabalhando lado a lado, utilizando-se docódigo, sendo que este não permite duplas interpretações da funcionalidade e do que osistema faz.

Colaboração com o cliente é mais importante que negociação de contratos: Umbom software não é feito somente escrevendo suas necessidades (contratos, prazos, cus-tos) num papel e entregando à empresa que vai desenvolver. Projetos feitos desta maneirasão falhos, gerando um produto final com pouca eficiência e qualidade. Nas metodolo-gias ágeis, para que o projeto tenha sucesso e aceitação, é preciso que exista sempre umfeedback do cliente para garantir que o software esteja sendo desenvolvido de maneiraque atenda as necessidades.

Outra motivação está no fato de alguns requisitos mudarem e começarem a setornar dispensáveis. Além disso, pode haver a necessidade de se adicionar outros requisi-tos não previstos em contrato ou especificação. Portanto, o melhor contrato é aquele quepropõe como será a comunicação e o relacionamento do cliente com a equipe desenvolve-dora.

Responder a mudanças é mais importante que seguir um plano: Algumas mudançasde especificação sempre vão ocorrer em projetos, e quanto maior é o grau de adaptação aessas mudanças melhor será o projeto. Planos devem, sim, serem traçados. Porém, comonão é possível prever o futuro, as visões desses planos não podem ir muito longe. Muitodeve ser projetado para poucas semanas, pouco se projeta para o próximo mês e quasenada se planeja para próximos anos, pois com as alterações que invariavelmente podemaparecer, dificilmente se devem fazer planos mais longos.

Logo, as metodologias ágeis são uma atitude, não um processo prescritivo; é umsuplemento aos métodos existentes, não é uma metodologia completa; é uma forma efe-tiva de se trabalhar em conjunto para atender as necessidades das partes interessadas noprojeto; funciona na prática, não é uma teoria acadêmica; não é um ataque à documen-tação, pelo contrário, aconselha a criação de documento que tem valor; o cliente faz parteda equipe de desenvolvimento e utiliza um modelo iterativo e incremental.

Atualmente há muitos processos ágeis disponíveis para desenvolvimento de soft-wares. Os processos mais abordados são: Scrum, Dynamic Systems Development Method(DSDM), Crystal Methods, Feature-Driven Development (FDD), Lean Development (LD)e Extreme Programming [2]. Este trabalho descreverá a metodologia ágil Scrum.

1.2. ScrumO Scrum é um processo ágil, simples e leve que pode ser utilizado para gerenciar e con-trolar o desenvolvimento de software. Tem sido utilizado em diversas áreas de Tecnologiada informação, tais como sistema da informação, vídeo games, websites, sistemas embar-cados e celulares.

Figure 1.1. Análise comparativa das metodologias ágeis. Fonte: VersionOneAgile Global Survey 2008

1.2.1. Visão Geral

O Scrum uma metodologia ágil que surgiu a partir de um jogo conhecido como Rugby.Esse jogo envolve oito jogadores de cada time para se formar uma muralha. Se um mem-bro da equipe falhar, o outro time se sobressai [5]. O ponto fundamental desse jogo é otrabalho em equipe. O trabalho em conjunto do time. É a essência dessa metodologia.

A história do Scrum foi iniciada a partir de um gerenciamento de projetos emempresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonakano artigo “The New Product Development Game” (Harvard Business Review, Janeiro-Fevereiro 1986) [6]. Eles concluíram que equipes pequenas e multidisciplinares pro-duziam melhores resultados. Depois, Jeff Sutherland, John Scumniotales e Jeff McKennadocumentaram e implementaram o Scrum na empresa Easel Corporations em 1993, in-corporando o estilo de gerenciamento observado por Takeuchi e Nonaka [6]. E em 1995,Ken Shwaber formalizou a definição de Scrum como método ágil que prevê as mudançasfreqüentes no desenvolvimento do software [7].

O Scrum se destaca dos outros processos ágeis por ser um método iterativo, in-cremental e ágil para o gerenciamento de Projetos. O Scrum é o processo mais praticadopelas empresas.

Abaixo se encontra uma figura do terceiro anual Survey do ano 2008: “The Stateof Agile Development” mostrando um grau comparativo de adoção das metodologiaságeis em projetos de softwares, mostrando em especial a adoção do Scrum, um indício doseu sucesso e relevância em projetos de desenvolvimento de software.

Podemos verificar na figura 1.1 que o Scrum se encontra em destaque na maioriadas empresas de software. O Scrum é colaborativo e ideal em projetos pequenos com req-uisitos que mudam constantemente durante o desenvolvimento de software, pois a práticade Scrum facilita a adaptação a processos empíricos de desenvolvimento de sistemas. Oframework do Scrum é formado basicamente em papéis, cerimônias e artefatos [8] comcada um fazendo parte do fluxo do processo do Scrum. Nas próximas seções serão detal-hadas o framework do Scrum e o fluxo do Scrum.

1.2.1.1. Papéis do Scrum

O Scrum como qualquer outra metodologia é baseada em papéis e responsabilidades. Eleé dividido em três papéis: Product Owner (Cliente), o time, e o Scrum Master [8]. Cadaum com sua responsabilidade.

Product Owner: Pode ser o financiador ou um interessado no projeto. Representa ointeresse de todos os usuários do sistema final. Suas responsabilidades são: definir asfuncionalidades do produto, coleta informações vindas dos usuários, stakeholders ou domercado para obter uma visão única dos requisitos do sistema, além disso, controla o ROIdo projeto, prioriza o Product Backlog [9].

Time: É o grupo de pessoas que está fazendo o trabalho e que garantirá que o pro-jeto seja entregue com todas as funcionalidades necessárias. São multifuncionais e auto-organizáveis. Define o objetivo do sprint e especifica os resultados dos trabalhos. Forma-dos por até sete pessoas, são coletivamente os responsáveis pelo sucesso de cada interaçãoe do projeto como um todo. A idéia de auto-organizável e multifuncional é que o timedeve possuir toda a capacidade e conhecimento técnico do processo de desenvolvimentodo produto.

Scrum Master: É o líder, gerencia o interesse do Product Owner e treina o time. Por-tanto ele melhora a vida e a produtividade do time provendo criatividade e conhecimento.O Scrum Master também estimula a comunicação e a cooperação entre todas as pessoasdo time, remove impedimentos, garante que o processo está sendo respeitado e auxilia oProduct Owner a maximizar o ROI.

Stakeholders (Cliente e fornecedores): Estas são as pessoas que aprovam o projeto epara quem o projeto irá produzir o benefício acordado. Eles só se envolvem no processodurante as sprint reviews.

Abaixo se encontra um possível cenário alocando cada responsável indicando seuspapéis e responsabilidades descritos (Veja a figura 1.2).

1.2.2. Cerimônias

As cerimônias SCRUM são eventos que acontecem dentro de um ciclo de desenvolvi-mento Scrum. Existem três tipos de cerimônias Scrum: a reunião de Planejamento doSprint, as reuniões diárias do Scrum e a reunião de revisão do Sprint. Estes eventos secaracterizam pelo ciclo de vida de cada Sprint: início, meio e fim.

1.2.2.1. Reunião de planejamento do Sprint (Sprint planning)

Uma reunião planejamento da Sprint ocorre no inicio da Sprint. Tem um tempo de du-ração (Time-box) entre 3 a 4 horas é realizado no primeiro dia. Geralmente esta reunião

Figure 1.2. Cenário dos papéis dos envolvidos no processo Scrum. Fonte:http://delicious.com/marcospereira

é dividida em duas partes: Sprint Planning 1 (fase do Product Backlog) e Sprint Planning2 (fase do Sprint Backlog).

Sprint planning 1: Participam o Product Owner (PO), time e o Scrum Master (SM) queatua como mediador. A equipe realizará o planejamento para verificar qual é o ProductBacklog. A equipe deve selecionar quais itens (funcionalidades), ordenados pela priori-dade, serão feitos na Sprint [10].

Sprint planning 2: Participam dessa parte o SM e o time, caso ocorra dúvida o PO podeser consultado para planejar o Sprint baseado no Product Backlog. A equipe selecionaquais itens do Backlog serão implantados até o fim da Sprint (duração de 28 dias). Depoiscada item selecionado será quebrado em tarefas menores (stories) formando o chamadoSprint Backlog. Com isso, o time fica sabendo o que é necessário ser feito para implantaros itens.

1.2.2.2. Reuniões diárias do Scrum (daily sprint)

É uma reunião pública, onde só os membros do time podem fazer comentários e perguntase dura no máximo 15 minutos. Três perguntas são respondidas nessa reunião: O que eu fiz

desde a última reunião? O que eu vou fazer até a próxima reunião? Quais os problemasestão impedindo a realização do meu trabalho?

O Scrum Master tem um papel fundamental aqui em resolver os impedimentos.Os benefícios dessas reuniões são a visibilidade do que está acontecendo para todo ogrupo e ajuda ao SM a identificar os impedimentos.

1.2.2.3. Reunião de revisão do Sprin (Srpint review)

É uma reunião realizada no ultimo dia da Sprint. Todos participam (PO, SM e time) edura 4 horas em geral e serve para revisar os altos e baixos do ciclo. Aqui é apresentadoo resultado do trabalho. Nesta reunião, podem ser levantadas novas funcionalidades eos stakeholders podem identificar funcionalidades que não forem entregues e um novoProduct backlog é gerado [11].

Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar até quetodo o produto seja finalizado e o Product Backlog esteja limpo de pendências.

1.2.2.4. Sprint Retrospective

É uma reunião que acontece no final de uma Sprint. Dura em média 3 horas. Partici-pam o Scrum Master, o time e o PO (opcional). Com o objetivo de detectar melhorias edocumentar as lições aprendidas.

1.2.2.5. Reunião de Planejamento da Versão para Entrega (Release Planning)

O propósito do planejamento da versão para entrega é o de estabelecer um plano e metasque o Time Scrum e o resto da organização possam entender e comunicar. O planejamentoda versão para entrega responde às questões: “Como podemos transformar a visão emum produto vencedor da melhor maneira possível? Como podemos alcançar ou exceder asatisfação do cliente e o Retorno sobre Investimento (ROI) desejados?” O plano da versãopara entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto,os principais riscos e as características gerais e funcionalidades que estarão contidas naversão.

Ele estabelece também uma data de entrega e custo prováveis que devem se manterse nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesseplano da versão para entrega a cada Sprint.

Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo quecada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco.Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é umpedaço potencialmente entregável do produto completo. Quando já tiverem sido criadosincrementos suficientes para que o produto tenha valor e uso para seus investidores, oproduto é entregue. Muitas organizações já possuem um processo de planejamento deversão para entrega, e na maior parte desses processos o planejamento é feito no início dotrabalho da versão e não é modificado com o passar do tempo.

Figure 1.3. Product Backlog. Fonte: http://delicious.com/marcospereira

No planejamento de versão para entrega do Scrum, são definidos uma meta gerale resultados prováveis. Esse planejamento geralmente não requer mais do que 15-20%do tempo que uma organização costumava utilizar para produzir um plano de versão paraentrega tradicional. No entanto, uma versão com Scrum realiza planejamento no momentoda execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesmaforma que realiza um planejamento diário no momento da execução de cada ReuniãoDiária.

De forma geral, os esforços para uma versão para entrega com Scrum provavel-mente consomem ligeiramente mais esforço do que os esforços para um planejamentode versão para entrega tradicional. Planejamento de versão para entrega requer estimar epriorizar o Backlog do Produto para a Versão. Há diversas técnicas para fazê-lo que estãofora do alcance do Scrum, mas que apesar disso são úteis quando usadas com ele.

1.2.3. Artefatos

Product Backlog É uma lista de funcionalidades feita pelo proprietário do produto(Product Owner) em conjunto com o cliente, que é organizada por prioridade de entrega.O time contribui estimando o custo de desenvolvimento das funcionalidades. A Figura1.3 mostra um exemplo de product backlog:

Sprint Backlog São tarefas menores formado pela quebra dos itens do Backlog. É umalista especificando os passos necessários para implantar uma funcionalidade do sistema.A Figura 1.4 mostra um exemplo de Sprint backlog em quadro de cartolina dividido em

Figure 1.4. Sprint Backlog. Fonte: Gerenciamento de projetos com Scrum, abril de 2007

quatro colunas. A Figura mostra o item do product backlog, tarefas que estão pendentesa fazer, tarefas alocadas para cada membro do time, e as tarefas prontas pelo time.

1.2.4. Fluxo do Scrum

Nessa seção será descrito, de forma geral, como ocorre o processo Scrum no gerencia-mento do desenvolvimento de software. De início a Figura 1.5 resume visualmente todasas fases do processo do Scrum. Logo depois são apresentadas as descrições passo-a-passode cada etapa do processo.

De acordo com a figura, um projeto Scrum inicia com a visão global do sistemaque será desenvolvido. O proprietário do produto é responsável por produzir esse doc-umento de forma que seja maximizado seu retorno de investimento (ROI). O ProductOwner elabora a lista de itens priorizados gerando o Product Backlog, que são os requi-sitos funcionais e não funcionais do sistema. O Product Backlog é priorizado pelos itensmais desejados. Logo, os mais importantes serão entregues nas primeiras versões.

Todo o trabalho é feito em Sprints ou iterações. Cada Sprint é uma interação de30 dias consecutivos [8]. Entretanto na prática há uma flexibilidade em relação a essetamanho, pois depende muito das características do time e do esforço para implantar oproduto. Cada Sprint é iniciado com a reunião do planejamento do Sprint (Sprint Plan-ning), em que o Product Owner e o time estão juntos para colaborar sobre o que será feitona próxima Sprint.

A Sprint Planning tem duração de 8 horas. Esse tempo fixo é importante para

Figure 1.5. Fluxo do Scrum. Fonte:blog.marciel.org/?m=200909)

manter ágil o processo. A Sprint Planning é dividida em duas etapas. A primeira etapa éde 4 horas com o Product Owner apresentando o Product Backlog ao time. O time podequestionar sobre as intenções de cada item do Product Backlog. Diferente nas metodolo-gias tradicionais como o RUP só uma pessoa é que faz o levantamento dos requisitos.Na segunda etapa, o Scrum Master e o time selecionam os itens mais ágeis de ser imple-mentados por meios de técnicas de estimativas de esforços como, por exemplo, técnicado Planning Poker que estima os itens pelo tamanho da complexidade [10]. Depois deestimadas, o time divide os itens em tarefas menores gerando o Sprint Backlog para cadaitem do Backlog que serão implantados durante a Sprint.

Todos os dias terão reuniões diárias que duram 15 minutos, em que os membrosdo time fazem comentários e perguntas sobre como esta o andamento do projeto. Essa re-união diária usa alguns conceitos do XP, como a reunião em pé e o valor da comunicaçãoentre a equipe. Isso traz benefícios como troca de conhecimentos entre a equipe resul-tando sincronização entre todos. Destaca-se nessas reuniões o dever do Scrum Master emresolver os impedimentos.

No final da Sprint, o Sprint review é realizado com duração de 4 horas [8]. Aquié mostrado ao product Owner de tudo o que foi desenvolvido na Sprint. Nessa reunião,podem ser levantadas novas funcionalidades e gerar um novo Product Backlog. Depoisque esta reunião é finalizada, um novo ciclo Sprint pode começar até que todo o produtoseja finalizado e o Product Backlog esteja limpo de pendências. Após essa prática, éfeita a Sprint Retrospecive e algumas perguntas são respondidas, como: O que aconteceudurante a Sprint? O que foi bom durante a Sprint? O que poderia funcionar melhor? Essaprática traz benefício para a equipe conhecer melhor e melhorar nas próximas Sprints.Portanto juntos a Sprint Planning, Sprint Review e o Sprint Retrospective constituemuma inspeção formal e uma adaptação ao processo Scrum.

1.2.5. Estimativa de Tempo usando Planning Poker

Antes de começar falar sobre estimativas, gostaria de chamar a atenção para o significadoda palavra “Estimativa”.

O que é uma estimativa?

1. Um cálculo aproximado;

2. Uma declaração por escrito do preço aproximado que será cobrado para um trabalhoespecífico;

3. Um julgamento ou avaliação.

Mais importantes, estimativas são inerentemente erradas. Estimativas não são ex-atas, e não refletem a realidade. A única maneira de saber o tempo exato que uma ativi-dade vai durar, ou quanto esforço será necessário despender para executar algum trabalho,é após a sua realização. Dito isso, vamos prosseguir a respeito do Poker Planning.

Uma das maneiras mais eficientes e recomendadas de estimar o tamanho de requi-sitos em times que adotam métodos ágeis (XP/Scrurn) é o jogo de cartas conhecido comoPlanning Poker [14]. Este método de estimar combina opinião de especialistas, analogiase desagregação em uma aproximação eficiente para estimar de maneira rápida, porémconfiável. É uma variação do método de estimativa Wideband Delphi [15].

As estimativas acontecem normalmente em uma reunião, também chamada detimeboxed (geralmente 4 ou 8 horas, dependendo da quantidade de requisitos a ser es-timada). Os participantes do jogo de poker são todos os membros do time do Scrum.O Product Owner normalmente comparece a esta reunião para prestar esclarecimentosa respeito dos requisitos, porém não pode opinar e estimar junto com o time. O ScrumMaster registra os resultados da reunião, e assim como o Product Owner, não interferenas estimativas do time.

No início de uma reunião de Planning Poker, cada membro do time recebe umdeck de cartas, que contém uma variação da sequência de Fibonacci: 0, 1/2, 1, 2, 3, 5, 8,13, 20, 40, 50, 75, 90, 100 ? e “Pausa”. Ainda no início, todos os itens a serem estimadossão lidos pelo Product Owner ou Scrum Master, e a equipe conversa para decidir qual é omenor item de backlog disponível.

1.2.5.1. Gerenciamento de Projetos com Scrum utilizando Planning Poker

O Gerenciamento de Projetos com SCRUM, após essas estimativas iniciais, esse item émarcado corno “2” pontos, e a equipe prossegue para estimar os demais itens de backlog.Isso serve para definir uma referência de tamanho e complexidade para ser utilizada nasdemais estimativas. Isso só precisa ser definido na primeira reunião de Estimativa, edeve ficar registrado, para uso nas futuras reuniões. Em casos excepcionais, o time podedecidir mudar a estória de referência por uma outra estória. Aqui também é importanteusar o bom-senso.

Seguindo adiante, para cada estória a ser estimada, o Scrum Master ou ProductOwner lê a descrição e os critérios de aceitação da mesma. O Product Owner responde aquaisquer questionamentos que o time possua a respeito da estória, entretanto procurandomanter o nível da discussão em alto nível, e no entrar em detalhes. É comum definirtambém um timebox para esse tempo de Perguntas e Respostas, de modo a não se estenderdemais e perder muito tempo em uma única estória. Depois da apresentação e discussão

inicial, cada pessoa seleciona sua estimativa (uma carta), baseada em sua opinião pessoala respeito do tamanho e complexidade da estória, e a coloca em cima da mesa, com a facevoltada para baixo. Quando todos os participantes selecionarem uma carta, as mesmasserão viradas ao mesmo tempo.

Se houver uma grande variância entre a maior e menor carta, o time vai discutir oque cada membro estava pensando quando selecionou o tamanho. A ideia aqui é que todosentendam as razões, que mais uma ou outra pergunta sejam respondidas pelo ProductOwner, e a equipe volta a pensar sobre a estória, e faz uma nova estimativa. O ciclodeve ser repetido até que todas as estimativas estejam próximas, ou que a equipe cheguea um consenso. É comum definir um limite de rodadas de poker, para evitar que as coisasfiquem muito arrastadas. Repetir até que todas as estórias estejam 100% estimadas!

1.2.6. Considerações Finais

Muitas empresas desenvolvem software sem usar nenhum processo. Geralmente issoocorre porque os processos tradicionais não são adequados às suas realidades. Em par-ticular, as pequenas e médias empresas ou organizações não possuem recursos suficientespara adotar o uso de metodologias pesadas e, por essa razão, normalmente não utilizamnenhum processo. O resultado dessa falta de sistematização na produção de software é abaixa qualidade do produto final.

Devido a esse contexto, as metodologias ágeis vêm se tornando cada vez maisutilizadas pelas empresas nos últimos anos por ter uma abordagem simplificada. Estácomprovado que os métodos, práticas e técnicas para o desenvolvimento de projeto ágilsão adequados para situações em que a mudança de requisitos é freqüente [8]. Isso au-menta a satisfação do cliente [12], produz alta qualidade de software e diminuição dosprazos e custos de desenvolvimento [13]. Os projetos tradicionais de desenvolvimento desoftware não são adequados para projetos em que mudanças são freqüentes. Isso acabaatrapalhando o cumprimento de prazos, aumentando seus custos e prazos, e diminuindo aqualidade do software.

Diante desse contexto, o Scrum é uma das metodologias ágeis que estão maisadaptadas a mudanças e está mais sendo usada pelas empresas de softwares. O Scrum éum processo que constrói software incrementalmente em ambientes complexos, onde osrequisitos não são claros ou mudam com muita frequência.

1.3. Referências

References[1] Disponível em http://www.agilemanifesto.org/ Ultimo acesso em 18/10/2009.

[2] BECK, K., “Extreme Programming Explained: Embrace Change”, 1st Edition,Addison-Wesley, 1999.

[3] WELLS, D, Disponível em http://www.extremeprogramming.org, Visitado em20/09/2004;

[4] SANTOS, R. Disponível em http://www.ime.usp.br/g̃daltonl/ageis/ageis_6pp.pdfVisitado em 08/10/2009.

[5] Disponível em http://www.javamovel.com/2009/09/scrum.html Visitado em08/10/2009.

[6] Disponível em http://pt.wikipedia.org/wiki/Scrum Visitado em 08/10/2009.

[7] Asfora, Diego Maciel. “Uma abordagem para a priorização de requisitos em ambi-entes ágeis” Dissertação Mestrado, UFPE, 2009.

[8] Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004

[9] Disponível em http://www.aspercom.com.br/ead/mod/resource/view.php?id=245Visitado em 08/10/2009.

[10] Disponível em http://www.companyweb.com.br/Rildo/scrum/Tutorial-SCRUM-v9.pdf Visitado em 08/10/2009.

[11] Ken Schwaber. Agile Software Development with Scrum. Prentice Hall (2001).

[12] BOEHM, B. and Turner, R., Balancing Agility and Discipline A Guide for the Per-plexed, Addison Wesley, 2003.

[13] ANDERSON, D. J., Agile Management for Software Engineering, Applying theTheory of Constraints for Business Results, Prentice Hall, 2003.

[14] Henrik Kniberg. Scrum; XP Direto das trincheiras. Ed. Enterprise Software Devel-opment Community, 2007.

[15] Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi; Warsta, Juhani. Agile SoftwareDevelopment Method, Review and Analysis. Espoo 2002. VTT publications 478.107p