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

LISTA DE SIGLAS.....................................................................................................4
LISTA DE SIGLAS

APM Ágile Project Management

UML Unified 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.