IESP - INSTITUTO DE EDUCAÇÃO SUPERIOR DA PARAÍBA

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO

GLEISON MAIA COSTA

GESTÃO ÁGIL DE PROJETOS EM TI:

GERENCIAMENTO DE EQUIPES COM SCRUM

João Pessoa - PB

2011

GLEISON MAIA COSTA

GESTÃO ÁGIL DE PROJETOS EM TI:

GERENCIAMENTO DE EQUIPES COM SCRUM

Monografia apresentada à comissão examinadora do IESP - Instituto de Educação Superior da Paraíba, como requisito para o recebimento do título de Bacharel em Sistemas de Informação.

Orientador: Luciano Almeida

João Pessoa - PB

2011

SUMÁRIO

1 INTRODUÇÃO..........................................................................................................7

1.1 Cenário Atual......................................................................................................7

1.2 Identificação do Problema..................................................................................9

1.3. Objetivos..........................................................................................................10

1.3.1. Objetivo Geral...........................................................................................10

1.3.2. Objetivos Específicos................................................................................10

1.4 Justificativa.......................................................................................................11

2 DESENVOLVIMENTO ÁGIL ............................................................................... 12

2.1 Características..................................................................................................12

2.2 Objetivos do Desenvolvimento Ágil..................................................................13

3 SCRUM................................................................................................................ 16

3.1 Definição...........................................................................................................16

3.2 Características..................................................................................................17

3.3 Papéis...............................................................................................................18

3.4 Artefatos...........................................................................................................19

3.5 Cerimônias.......................................................................................................21

3.6 Visão geral do ciclo SCRUM............................................................................23

3.7 Implantação e panorama da utilização ............................................................24

LISTA DE SIGLAS

APMUML

Ágile Project ManagementUnified Modeling Language

Resumo: xxxxxxxxxxxxxxxxx.

PALAVRAS-CHAVES: Desenvolvimento Ágil, Scrum.

“Construa projetos em torno de indivíduos motivados.

Dê a eles o ambiente e o suporte necessário

e confie neles para fazer o trabalho.”

Kent Back et.all

1 INTRODUÇÃO

1.1 Cenário Atual

Diante da constante evolução dos softwares tornou-se indispensável inovar

também no desenvolvimento dos mesmos, a globalização aumentou a

competitividade e cada empresa tem obrigação de buscar, apresentar e aprimorar o

seu diferencial competitivo.

Segundo o relatório “CHAOS” (Standish Group, 2009), 32% dos projetos

obtiveram sucesso (foram entregues no prazo, dentro do orçamento e com escopo

completo), 44% mudaram (atrasaram, estourou o orçamento, e/ou reduziram

escopo) e 24% falharam (cancelados ou nunca usados), isto prova a dificuldade que

existe em compreender os fatores relevantes para as mudanças no curso do

processo. Abaixo gráfico demonstrando que o cenário da conclusão de projetos em

2009 teve resultados piores em relação ao relatório anterior.

Figura 1: Gráfico do relatório Chaos Report

Fonte: Chaos Report. Standish Group (2009)

Foi visando superar esses e outros obstáculos que em 2001 foi assinado o

“Manifesto para o Desenvolvimento Ágil de Software”, nele notáveis

desenvolvedores declararam estar descobrindo melhores modos de

desenvolvimento de software, por meio deste passaram a valorizar os indivíduos e a

iteração entre eles, a colaboração do cliente e a resposta rápida às modificações

existentes, além de não se prenderem a uma documentação abrangente.

Surgem então as metodologias ágeis, com desenvolvimento interativo,

colaborativo, é uma resposta às limitações das metodologias focadas na

documentação. Neste processo ágil a equipe deve estudar antecipadamente os

requisitos de software e prever quais poderão sofrer modificações e quais serão

mantidos no escopo inicial, é uma tarefa difícil, visto que é complicado definir quais

prioridades do cliente poderão sofrer alterações no decorrer do projeto.

O foco de tais metodologias é centrado nas relações humanas inerentes ao

desenvolvimento de sistemas e não somente na documentação e burocratização de

processos promovida pelos modelos tradicionais. Pregar o trabalho em equipe é

prioridade, pois um grande projeto de software com milhares de linhas de código não

pode ser escrito por uma única pessoa.

Contendo princípios consistentes com o Manifesto Ágil, o SCRUM foi

desenvolvido por Jeff Sutherland e sua equipe no início da década de 90, recebendo

métodos adicionais de Scwaber e Beedle. É um modelo incremental e ideal para ser

utilizado em ambientes onde os requisitos não são muito claros ou mudam com

freqüência.

1.2 Identificação do Problema

De acordo com Pressman (2006, p. 55), “projetos reais raramente seguem o

fluxo seqüencial que esses modelos propõem. Por se tratar de um modelo linear,

uma modificação no decorrer do processo pode causar confusão”.

As metodologias tradicionais têm como principal característica serem

divididas por etapas bem definidas: Análise, Modelagem, Desenvolvimento e Testes.

Cada etapa seguinte só é inicializada após o termino da anterior, sendo uma

dependente da outra e são gerados documentos, diagramas UML1 ou protótipos de

software.

Muitas dessas metodologias utilizam o modelo em cascata, que prevê uma

abordagem seqüencial, começando pela coleta de requisitos, passando pelo

planejamento, modelagem, construção e implantação. O foco destas é a

previsibilidade dos requisitos do sistema, dificultam o controle do projeto, pois

quando existem incertezas e quando há, por exemplo, uma alteração de requisitos, é

necessário voltar ao inicio para alterar a documentação gerada após a coleta dos

mesmos.

Para o cliente é difícil estabelecer todos os requisitos explicitamente no início

do projeto, o que praticamente impossibilita a acomodação natural das incertezas

que existem no inicio de muitos projetos.

_______________________________1 Representação gráfica do produto em desenvolvimento, gerada em UML (Unified Modeling

Language), linguagem de modelagem que usa o conceito de orientação a objetos.

1.3 Objetivos

1.3.1. Objetivo Geral

Avaliar as dificuldades existentes no desenvolvimento e gerenciamento de

projetos na área de Tecnologia da Informação, principalmente no ponto de vista do

trabalho em equipe, apresentando a framework ágil SCRUM como ferramenta para

possibilitar a otimização na gestão de pessoas e processos e, consequentemente,

melhoria nos resultados.

1.3.2. Objetivos Específicos

Explanar sobre a origem e aplicação do desenvolvimento ágil, ressaltando os

benefícios para a equipe de desenvolvimento, especificando-se na aplicação

do SCRUM como gerador de resultados no gerenciamento de projetos;

Discriminar o ciclo de vida desse modelo;

Explicar os processos do modelo em questão e usá-los como agentes

integradores, trazendo maior co-participação dos integrantes, nivelamento de

conhecimento e principalmente, resultados positivos.

Apontar boas práticas para melhorar o rendimento da equipe de

desenvolvimento;

1.4 JUSTIFICATIVA

Diante do histórico de problemas na conclusão de projetos, onde os métodos

tradicionais não conseguem em vários casos manter os escopos originais, nem

tampouco cumprir com orçamento e prazo, torna-se necessária a busca por modelos

que possam acompanhar o ritmo das mudanças, possibilitar maior adaptabilidade e

cumprir com os cronogramas de execução e entrega, atendendo ao crescente

dinamismo do mercado.

Trabalhar em equipe significa envolver diferentes emoções e opiniões, dividir

tarefas e compartilhar conhecimento, e neste processo as pessoas darão o melhor

de si se tiverem motivação e expectativas adequadas. Essa forma de trabalho exige

ferramentas específicas, dentre essas o SCRUM foi o escolhido para esta pesquisa

por ser um ótimo exemplo de modelo de integração de indivíduos, que contém fases

bem definidas e reuniões para discussão que podem prevêem o surgimento de

fracassos para poder contorná-los sem grandes prejuízos para o cronograma

realizado.

É indicado para gerenciar qualquer atividade complexa, aperfeiçoa o

entrosamento entre as equipes de desenvolvimento, com isso o rendimento

aumenta, os requisitos e as solicitações de alteração passam a ser entendidos com

maior facilidade.

2 DESENVOLVIMENTO ÁGIL

2.1 Características

Segundo Pressman (2006, p.58), a engenharia de software ágil

combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A

filosofia encoraja a satisfação do cliente e a entrega incremental do

software logo de início; equipes de projeto pequenas, altamente

motivadas, métodos informais, produtos de trabalho de engenharia de

software mínimos e simplicidade global de desenvolvimento. As diretrizes

de desenvolvimento enfatizam a entrega em contraposição à análise e ao

projeto (apesar dessas atividades não serem desencorajadas) e a

comunicação ativa entre desenvolvedores e clientes.

Os princípios do desenvolvimento ágil visam minimizar as falhas

desenvolvendo o projeto de forma incremental, em curtos períodos, chamados de

iteração, sendo esses “mini-projetos” de software que incluirão as tarefas

necessárias para alcançar a funcionalidade do produto: planejamento, análise de

requisitos, projeto, codificação, teste e documentação.

Esse processo prioriza pessoas e iterações à processos e ferramentas, software

executável, ao contrário de documentação extensa e confusa,e principalmente a

colaboração do cliente e resposta rápidas às mudanças no escopo durante o

andamento do projeto.

A motivação é um dos focos de tais modelos, as equipes de negócio e

desenvolvimento trabalham juntas diariamente, deve ser dado o ambiente e o apoio

necessário aos indivíduos para que eles confiem na realização do trabalho.

Ter o software funcionando é a principal medida de progresso, para isso

maximizar a quantidade de trabalho não-realizado é essencial. A equipe deve

receber bem as mudanças de requisitos, mesmo estando em fase avançada de

desenvolvimento, pois o direcionamento dessas mudanças constitui em um

diferencial competitivo para o cliente.

2.2 Objetivos do Desenvolvimento Ágil

De acordo com Martins (2007), são cinco os principais objetivos do Agile

Project Management (APM), sendo eles: Inovação contínua, adaptabilidade do

produto, entregas com cronograma reduzido, adaptabilidade do processo e das

pessoas, resultados confiáveis.

A inovação contínua busca suprir às necessidades atuais do cliente, mesmo

que estas sofram mudanças no decorrer do projeto.

O desenvolvimento deve ter foco na redução do custo de adaptação, visto

que o produto deve ser adaptável a possíveis alterações de escopo.

Há duas razões pelas quais o retorno rápido é importante: cometemos a

maior parte dos nossos erros nos primeiros aspectos do desenvolvimento e o custo

de consertar esses defeitos aumenta exponencialmente conforma a demora de

serem descobertos (AMBLER, 2002).

Para isso, as metodologias ágeis programam entregas com cronograma

reduzido, assim podem identificar mais cedo requisitos mal-compreendidos, falhas

na modelagem, na codificação, entre outros.

Nos gráfico abaixo a curva de probabilidade de surgimento de defeitos, e, em

seguida, a curva representando o custo do conserto dos mesmos.

Figura 2: Probabilidade decrescente do surgimento de defeitos.

Fonte: Ambler (2002)

Figura 3: Custos crescentes para identificar e consertar os defeitos.

Fonte: Ambler (2002)

Em uma indústria onde a mudança é regra, cada oportunidade de aprender

novos métodos deve ser explorada, para isso, a formação de uma equipe integrada

e multidisciplinar é importante. Segundo AMBLER (2002), os modeladores ágeis

reconhecem que nunca sabem tudo sobre algo; há sempre a oportunidade de

aprender mais e estender seus conhecimentos.

Aliando esses objetivos a uma boa gerência, pode-se entregar um resultado

confiável ao cliente, que possa superar as incertezas dos requisitos e o surgimento

de novas tecnologias, que seriam fatores complicadores em um processo tradicional.

2.3 Quando deve ser utilizado o desenvolvimento ágil?

É indicado o uso de métodos ágeis principalmente em situações onde os

requisitos são imprevisíveis ou mudam rapidamente, quando há colaboração do

cliente no sentido de avaliar as versões lançadas e traçar seus objetivos e

prioridades, dessa forma o projeto pode evoluir de acordo com a elevação das

necessidades do mesmo.

Vale salientar que os processos de softwares básicos não devem ser

deixados de lado, o foco do Ágile está na modelagem e documentação eficazes,

para outras necessidades como as rotinas de teste, gerenciamento de projeto e

suporte ao sistema deve-se aliar a outros modelos para obter o resultado ideal.

2.4 Conhecendo uma equipe de desenvolvimento ágil

Borges. et all (2006) define “equipe” como um pequeno número de pessoas

com habilidades complementares, unidas por um objetivo comum, mutuamente

responsáveis, que trabalham de forma interdependente para atingir objetivos

específicos de desempenho.

Como foi relatado anteriormente, sabemos que o foco do Ágile está no

fortalecimento das relações humanas, no trabalho em conjunto, para isso Pressman

(2006) define que devem existir características-chave entre os membros da mesma

e na equipe em si, sendo elas: competência, foco comum, colaboração, capacidade

de tomada de decisão, habilidade de resolver problemas vagos, respeito e confiança

mútua e auto-organização.

Embora os membros da equipe possam realizar diferentes tarefas, algumas

dessas características devem ser comuns à boa parte deles.

As equipes ágeis estão no controle do trabalho a ser realizado, os

compromissos são planejados entre eles, essa forma de trabalho aperfeiçoa a

colaboração e aumenta a moral, enquanto que o cumprimento dos objetivos

definidos por eles mesmos são importantes agentes motivadores.

3 SCRUM

3.1 Definição

O nome “SCRUM” é derivado de uma jogada do rugby, em uma alusão à

formação de equipe, com divisão de papéis em busca de um objetivo comum.

É um modelo iterativo e incremental que pode ser utilizado para o

gerenciamento de qualquer atividade complexa, proporcionando bom entrosamento

entre os membros do time de desenvolvedores, participação ativa do cliente e

aumento no rendimento das atividades.

SCRUM não é um processo ou uma técnica para o desenvolvimento de

produtos. Ao invés disso, é um framework dentro do qual você pode empregar

diversos processos e técnicas. O papel do Scrum é fazer transparecer a eficácia

relativa das suas práticas de desenvolvimento para que você possa melhorá-las,

enquanto provê um framework dentro do qual, produtos complexos podem ser

desenvolvidos (SCHWABER. SUTHERLAND, 2010)

3.2 Características

Divisão do projeto em pedaços menores e curtos, variando de uma

semana a um mês;

Interação entre indivíduos, reuniões regulares para refletir como se

tornar mais eficiente;

Indivíduos motivados e ambiente adequado para execução das

atividades, equipe auto-gerenciável e multifuncional;

Comunicação entre a equipe e o cliente em tempo real, cliente e

desenvolvedor devem trabalhar juntos;

Gerenciamento e controle, atenção constante a excelência técnica e

design;

Alta capacidade de resposta a mudanças.

Entrega por partes e contínua, software em funcionamento,

satisfazendo o cliente;

Nesse modelo o cliente é uma parte importante no processo e sua

participação ativa, mesmo que não presente fisicamente, é essencial para a garantia

de sucesso. Seu feedback constante alimenta o planejamento do projeto e definição

de atividades pela equipe.

O framework consiste em um conjunto formado por Times de Scrum e seus

papéis associados, Time-Boxes (eventos com duração fixa), Artefatos e Regras.

3.3 Papéis

3.3.1 Product Owner

Responsável por conhecer as necessidades do(s) cliente(s) e garantir o ROI

(retorno de investimento), pode ser um financiador ou um importante interessado no

projeto.

É a pessoa responsável por representar o cliente, definir os itens de

prioridade no desenvolvimento e garantir que todos saibam em que se irá trabalhar.

Este fará ainda a avaliação a fim de aceitar ou rejeitar o resultado dos trabalhos

realizados.

3.3.2 Scrum Master

Garante que o processo seja compreendido, remove impedimentos e protege

a equipe de interferências externas, desempenhando um papel de liderança e

gerenciando os interesses do Product Owner mediante o time.

Ajuda no desenvolvimento do Product Backlog e garante que o projeto e a

cultura organizacional estão otimizados para atender os objetos do ROI.

3.3.3 Time

O Time é o grupo de pessoas diretamente ligadas ao trabalho a ser feito que

garantirá que o projeto seja entregue com todas as funcionalidades necessárias,

fazem a seleção e desenvolvimento das funcionalidades de maior prioridade,

dividem cada item de desenvolvimento em pequenas tarefas e depois gerenciam

seu próprio trabalho.

Deve ter de 6 a 9 pessoas, reduzir o tamanho do time pode garantir e

aumentar produtividade.

3.4 Artefatos

3.4.1 Product Backlog

Lista contendo todas as funcionalidades do produto, seu conteúdo é definido

pelo Product Owner. Trata-se de uma estimativa inicial das necessidades, que evolui

conforme o produto e o ambiente que ele está sendo usado evoluem.

Cada item da lista deve ter seu peso, de acordo com a necessidade do cliente

ou dos usuários, o mesmo é reavaliado ao início de cada sprint.

É interessante que a manutenção do Product Backlog seja feita em uma

linguagem compreensível a todos os integrantes do projeto, de forma que a

interpretação não exija conhecimentos técnicos, visto que os requisitos existentes

serão discutidos entre a equipe e também pelo cliente, desta forma irá possibilitar a

tomada das decisões cabíveis em cada reunião para planejamento dos sprints.

3.4.2 Sprint Backlog

Divisão do Product Backlog em partes menores, especificando os passos

necessários para implementar uma funcionalidade do sistema. É uma imagem

altamente visível, em tempo real do trabalho que a equipe pretende realizar durante

o Sprint.

Cada indivíduo escolhe o trabalho a ser feito, de acordo com sua afinidade

com o processo em questão. Os indivíduos da equipe podem ainda adicionar,

apagar ou mudar tarefas a serem realizadas.

Esta divisão é realizada de forma distinta por equipe, já que é possível ter

mais de um SCRUM Team trabalhando no mesmo Product Backlog.

3.4.3 Burndown Chart

Gráfico que mostra a quantidade de trabalho cumulativo restante de um

Sprint, dia por dia. É uma ferramenta eficaz para determinar rapidamente se um

sprint ou liberação está na programação para que todos os trabalhos previstos

concluída até a data desejada.

Figura 4: Burndown chart

Fonte: http://www.mountaingoatsoftware.com/scrum/sprint-backlog

3.5 CERIMÔNIAS

3.5.1 Reunião de planejamento de release

Schwaber,Sutherland (2010) definem que o propósito do planejamento da

release2 é o de estabelecer um plano de metas que o Time de Scrum e o resto da

organização possam entender e se comunicar.

Neste momento serão definidas as prioridades do Product Backlog, os

principais riscos de implementação e as funcionalidades contidas. Esse

planejamento requer um tempo bem menor do que levaria para ser feito em um

plano de release tradicional

3.5.2 Sprint Planning (Reunião de planejamento da Sprint)

Negociação entre o Product Owner e a equipe para definir o que será feito no

próximo Sprint. Ambas as partes devem concordar sobre os itens que serão ou não

confirmados para a próxima etapa.

A meta da sprint será definida a partir deste acordo, será o objetivo a atingido

após a conclusão das funcionalidades dos itens realizados.

3.5.3 Sprint

Iteração de trabalho na qual um incremento de funcionalidade produto é

aplicada, é a aplicação da Sprint Planning. A garantia de que a equipe não sofre

interferências durante a execução das tarefas é um dos fatores que permitem ao

time assumir compromissos que terão possibilidades reais de serem cumpridos.

Por ter duração fixa (de uma semana a 30 dias), o controle da previsibilidade

do projeto é feito a cada iteração, isso faz com que o risco de que o projeto saia do

controle ou se torne imprevisível seja contido antes que tome uma proporção maior.

_______________________________2 Incremento de produto com potencial de entrega.

3.5.4 Sprint Review Meeting (Revisão da Sprint)

Reunião realizada ao final de cada Sprint, que em geral dura até quatro horas,

exceto para Sprints de durações mais curtas, onde o tempo da reunião poderia ser

diminuído.

Participam da review o time e as partes interessadas, a equipe deve estar

preparada para mostrar um incremento de projeto para que os stakeholders3 possam

levantar novas funcionalidades ou identificar funcionalidades que não foram

entregues.

3.5.5 Sprint Retrospective Meeting (Retrospectiva da Sprint)

Após a Revisão da Sprint e antes da reunião para Planejamento da próxima

Sprint, é realizada uma reunião entre o ScrumMaster e a equipe afim de discutir o

que correu bem e o que precisa melhorar na próxima iteração. Isso inclui não só o

resultado dos processos realizados, mas também a forma como foram realizados.

Nesta reunião poderá ser identificada a necessidade de mudanças nos preparativos

de reuniões, nas ferramentas e nos métodos de comunicação utilizados, assim como

ajustes na própria composição do time.

Trata-se de mais um conceito integrante das metodologias ágeis, a melhoria

incremental contínua.

3.5.6 Daily Scrum

Reunião diária de 15 minutos onde o time se encontra para garantir a

visibilidade do que está ocorrendo no andamento do projeto, onde cada membro vai

responder a três questões:

- O que fez desde a última reunião;

- O que vai fazer até a próxima reunião;

- Quais obstáculos estão impedindo a realização do trabalho.

_______________________________3 Termo usado para denominar as partes interessadas no projeto. Stake: interesse,

participação, risco. Holder: aquele que possui.

3.6 VISÃO GERAL DO CICLO SCRUM

As fases de desenvolvimento do Scrum são sobrepostas, qualquer

impedimento identificado em uma das fases do ciclo poderá ser contornado com

maior rapidez, as reuniões proporcionam múltiplo aprendizado, já que um integrante

pode opinar a respeito de funcionalidades que estão sendo desenvolvidas por outro

integrante do time. Esse modelo proporciona um amplo conhecimento e habilidade

da equipe em diversas áreas.

Figura 5: Detalhamento do ciclo de vida do Scrum.

Fonte: http://scrumemacao.com.br/web/

3.7 IMPLANTAÇÃO E PANORAMA DA UTILIZAÇÃO

3.7.1 DIFICULDADES EXISTENTES NA IMPLANTAÇÃO DO SCRUM

Métodos ágeis em geral exigem mudança cultural, entre diversos fatores é

necessário o apoio de instâncias superiores, da equipe de desenvolvimento, iteração

com outros departamentos e ainda convencer clientes que não conhecem ou não

estão adaptados ao uso da metodologia.

De acordo com Cukier (2010), é preciso lembrar que para introduzir uma idéia

iremos lidar com pessoas. Em seu estudo, ele apresenta os tipos de pessoas que

serão encontradas pelo caminho e ressalta que todos deverão ser convencidos de

que a nova idéia trará mais benefícios que problemas, são elas:

- Inovadores: Representam 2,5% da população. São as pessoas que se

empolgam com as novidades só pelo simples fato de serem “coisas novas”, são

ideais para o apoio no início do processo.

- Os que adotam cedo: Representam 13,5% da população. É um grupo que

se mostra aberto a novas idéias, mas fazem uma análise mais detalhada e gostam

de aproveitar oportunidades estratégicas.

- Primeira maioria: É uma parte significativa da população e se caracteriza por

só implantar uma mudança após ter garantias de que outros já obtiveram sucesso

com a mesma e que trará benefícios consideráveis para a organização.

- Última maioria: É um grupo de proporções semelhantes à Primeira Maioria,

este é mais cauteloso, conservador, só aceita uma mudança após eliminar todas as

incertezas sobre sua eficiência.

- Retardatários: São aqueles que só adotam idéias que já estão em

funcionamento, geralmente sob necessidade ou pressão, após ter certeza de que a

idéia não irá falhar.

Dentro desse panorama é difícil a aceitação da idéia de mudar a mentalidade,

cultura, comportamento e atitudes dos membros de uma organização.

O SCRUM deixa de lado o caráter individualista do desenvolvimento

tradicional e ainda prega a inexistência de relação de poder entre os personagens

envolvidos, é o conceito do auto-gerenciamento de equipe.

3.7.2 PANORAMA DA UTILIZAÇÃO DE SCRUM EM COMPARAÇÃO COM

OUTROS MÉTODOS AGÉIS

Atualmente, muitas das organizações que trabalham com metodologias

tradicionais também têm equipes de desenvolvimento ágil, os métodos podem ser

complementares, de forma que os métodos ágeis fornecem aspectos ao

desenvolvimento de software que faltam nas práticas tradicionais, assim como os

métodos tradicionais oferecem suporte e de gestão de processos que possibilitam a

abordagem ágil em grandes projetos.

Em seu relatório anual “The State of Agile Survey”, State of Agile Survey

(2010), a VersionOne destaca a realidade da utilização dos métodos ágeis com

dados de participantes em 91 países, na pesquisa realizada 68% dos entrevistados

declararam conhecer bastante ou moderadamente as práticas ágeis, ainda segundo

a pesquisa 40% dos entrevistados trabalham com Ágile em suas empresas há pelo

menos 2 anos.

Abaixo, gráfico comparativo da utilização das metodologias ágeis e/ou

metodologias híbridas, é possível observar que o Scrum e suas variáveis são os

métodos mais empregados.

Figura 6: Gráfico comparativo da utilização de metodologias ágeis

Fonte: Adaptado de State of Agile Survey (2010)

REFERÊNCIAS BIBLIOGRÁFICAS

AMBLER, SCOTT W. Modelagem Ágil – Práticas eficazes para a programação

extrema e o processo unificado. Artmed Editora S/A, 2002.

BECK, K.et all. Manifesto Ágil. Disponível em: <http://www.agilemanifesto.org>. Acesso em 18 Mai 2011.

BORGES, ELIZABETH.et all. Gerência de Projetos – Guia do profissional:

Aspectos humanos e interpessoais volume 2. BRASPORT LIVROS E

MULTIMIDIA LTDA, 2006.

CUKIER, DANIEL. Padrões para Introduzir Novas Idéias na Indústria de

Software. USP, 2010.

FIGUEIREDO, ALEXANDRE MAGNO; MEDEIROS, MANUEL PIMENTEL. Revista

Visão Ágil. Edição 01,2005. Disponível em: http://www.visaoagil.com/edicoes

HELDMAN, KIM. Gerência de Projetos: Guia para o exame oficial do PMI. 2ª

reimpressão. Editora Elsevier, 2005.

MARTINS, JOSÉ CARLOS CORDEIRO. Técnicas para gerenciamento de

projetos de software. BRASPORT LIVROS E MULTIMIDIA LTDA, 2007.

MOUNTAIN GOAT SOFTWARE. Scrum Training on Sprint Backlog. Disponível

em: http://www.mountaingoatsoftware.com/scrum/sprint-backlog. Acesso em 16 Mai

2011.

ORTH, AFONSO INACIO; PRIKLADINICKI, RAFAEL. Planejamento e gerência de

projetos. EDIPUCRS, 2009.

ROGER, S. PRESSMAN. Engenharia de Software. 6 ed. McGraw-Hill, 2006.

SCHWABER, KEN. Agile Project Management with Scrum. Microsoft Press, 2004.

SCHWABER, KEN; SUTHERLAN, JEFF. The Scrum Guide. Scrum.org, 2010.

SABBAGH, RAFAEL. Scrum em Ação. Disponível em:

<http://scrumemacao.com.br/web/>. Acesso em 17 Mai 2011.

SCRUM ALLIANCE. Glossary of Scrum Terms. Disponível em:

<http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms>. Acesso em 17

Mai 2011.

STANDISH GROUP. Chaos Report 2009. Disponível em:

<http://www1.standishgroup.com/newsroom/chaos_2009.php>. Acesso em 25 Mar

2011.

VERSIONONE. State of Agile Survey 2010. VersionOne.com,2010.