Monografia Meire Scrib

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA “PAULA SOUZA”
FACULDADE DE TECNOLOGIA DE TAQUARITINGA
GRADUAÇÃO EM PROCESSAMENTO DE DADOS
MONOGRAFIA:
METODOLOGIA ÁGIL DE GERENCIAMENTO DE
PROJETOS - SCRUM
AUTORA: MEIRE ELEN ALVES DA SILVA
ORIENTADORA: PROFª. Ms. ANGELITA MOUTIN SEGORIA

GASPAROTTO
TAQUARITINGA
2010
MEIRE ELEN ALVES DA SILVA
METODOLOGIA ÁGIL DE GERENCIAMENTO DE

PROJETOS - SCRUM
Monografia apresentada à Faculdade de Tecnologia de

Taquaritinga, como parte dos requisitos para a obtenção
do título de Tecnólogo em Processamento de Dados.
Orientadora: Profª. Ms. Angelita Moutin Segoria

Gasparotto
TAQUARITINGA
2010
FOLHA DE APROVAÇÃO
Meire Elen Alves da Silva

Metodologia Ágil de Gerenciamento de Projetos - Scrum
Monografia apresentada à Faculdade de Tecnologia

de Taquaritinga, como parte dos requisitos para a
obtenção do título de Tecnólogo em Processamento de
dados.
Data da aprovação: ___/___/______
Banca Examinadora
________________________________________________________________
Nome
___________________________________________________________________________
Instituição
___________________________________________________________________________
Assinatura
___________________________________________________________________________
________________________________________________________________
Nome
___________________________________________________________________________
Instituição
___________________________________________________________________________
Assinatura
___________________________________________________________________________
________________________________________________________________
Nome
___________________________________________________________________________
Instituição
___________________________________________________________________________
Assinatura
___________________________________________________________________________
Dedico,
Aos meus pais, namorado e

amigos que sempre me
apoiaram e acreditaram em meu
potencial.
AGRADECIMENTOS
Agradeço primeiramente a Deus por me guiar em todo o meu caminho, me dando

saúde e forças para nunca desistir dos meus objetivos.
Aos meus pais Lourdes e Francisco, pelos conselhos fundamentais, pelo enorme
carinho e atenção á mim dedicados, pois devo tudo o que sou hoje á eles, que são a minha
base e a essência da minha vida.
Ao meu namorado Fernando Tita pelo carinho, incentivo e paciência á mim dedicados,
e por estar presente em todos os momentos.
A todos os meus amigos e professores de faculdade, por sempre estarem presentes me

apoiando e motivando em todos os meus caminhos.
Aos meus amigos Cleiton Leive, Thiago Galitezi, Fernanda Oliveira, Deysiane Sande
pelo apoio e pelas dicas que contribuíram para a realização deste trabalho.
A todos os meus familiares e pessoas que me incentivaram em todos os momentos da

minha vida.
À Professora Angelita Mountin Segoria Gasparotto, minha orientadora, pelo apoio,

dedicação e pelas sugestões oferecidas durante todo o período de elaboração e
desenvolvimento deste trabalho.
“... Estamos crescendo tão rápido que parece que sempre precisamos de
mais umas regrinhas aqui, mais um pouco de papel ali... precisamos ter
muito cuidado, pois cada novo nível gerencial, cada nova regra ou
formulário atrapalha. Eles acabam com a mágica, cortam a eletricidade
da inspiração. Com restrições em excesso, você pára de pensar no que
pode fazer e começa a pensar no que não da para fazer.”
Cirque Du Soleil – A Reinvenção do Espetáculo; Ed. Campus; Elsevier

Silva, M. E. A. Metodologia Ágil de Gerenciamento de Projetos - Scrum. Trabalho de
Graduação (Monografia). Centro Estadual de Educação Tecnológica “Paula Souza”.
Faculdade de Tecnologia de Taquaritinga. 89 p. 2010.
RESUMO
Este trabalho visa abordar a metodologia de gerenciamento ágil de projetos de software

chamada Scrum, apresentando suas características e buscando elucidar o principal foco de
aplicação, em termos de porte de projeto e de requisitos de negócio, tamanho de equipe,
artefatos e reuniões gerais que a empresa adota. Realizou-se uma revisão bibliográfica onde
foram coletadas informações, permitindo uma comparação com a metodologia tradicional de
desenvolvimento de software apresentando, por exemplo, o custo em inserir mudanças no
final do projeto. Além disso, são apresentados alguns conceitos do guia de orientação
PMBOK, que trata de uma bibliografia de referência para os profissionais auxiliando-os sobre
o conhecimento de gerenciamento, e com base nesta contextualização é abordada a
metodologia ágil de gerenciamento de projetos Scrum. Finalmente, apresenta-se também um
estudo de caso de aplicação da metodologia Scrum com o objetivo de demonstrar, na prática,
impactos e resultados da aplicação desta metodologia. Os resultados obtidos apontaram que é
possível gerenciar projetos de softwares com Scrum, pois esta é uma metodologia leve,
simples de usar e apta a projetos complexos e inovadores. O que pode acontecer às vezes é a
customização de algumas práticas, mas isso depende das necessidades e objetivos de cada
organização.
Palavras-chave: Metodologias Ágeis. Scrum. Gerenciamento de Projetos. Metodologias

Tradicionais. Engenharia de Software.
Silva, M. E. A. Metodologia Ágil de Gerenciamento de Projetos - Scrum. Trabalho de
conclusão de curso (Monografia). Centro Estadual de Educação Tecnológica “Paula Souza”.
Faculdade de Tecnologia de Taquaritinga. 89 p. 2010.
ABSTRACT
This report aims to address the methodology of agile project management software called
Scrum, presenting their characteristics and seeking elucidate the main focus of application, in
terms of size of project and business requirements, team size, artifacts and meetings of the
company adopts. Was achieved a literature review where information were collected to
compare with the traditional methods of software development, for example, the cost to insert
changes in the final project.Moreover, are presented some concepts of the guidance PMBOK,
which is a bibliography for professionals by helping them to knowledge management, and
based on this context is discussed in Agile Scrum project management. Finally, is presented a
case study of implementation of Scrum in order to demonstrate in practice, impacts and
results of applying this methodology. The results obtained indicate that it is possible to
manage software projects with Scrum, as a methodology that is light, simple to use and able
of complex and innovative projects, which can happen sometimes is the customization of
some practices, but depends on the needs and objectives of each organization.
Keywords: Agile Methodologies. Scrum. Project Management. Traditional methodologies.

Software Engineering
LISTA DE ILUSTRAÇÕES
Ilustração 1- Ciclo de vida Clássico. ..................................................................................................................... 16

Ilustração 2 - Custo de Modificações no modelo Clássico. ................................................................................... 18
Ilustração 3 - Comparação do custo de mudanças entre metodologias clássicas e ágeis. ...................................... 19
Ilustração 4 - Ciclo de vida ágil do desenvolvimento de sistema. ......................................................................... 28
Ilustração 5 - Comparativo entre as abordagens clássica e ágil. ............................................................................ 30
Ilustração 6 - Processo Iterativo. ........................................................................................................................... 33
Ilustração 7 - Estrutura de um Sprint. .................................................................................................................... 34
Ilustração 8 - Ciclo de vida de desenvolvimento do Scrum. .................................................................................. 35
Ilustração 9 - Sprint Burndown Chart. .................................................................................................................. 43
Ilustração 10 - Task Board View............................................................................................................................ 44
Ilustração 11 - Framework APM. .......................................................................................................................... 60
Ilustração 12 - Princípios do Gerenciamento Ágil de Projetos. ............................................................................. 62
Ilustração 13 - Grupo de processos de gerenciamento de projetos. ....................................................................... 64
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................................... 11
1.1. CONTEXTUALIZAÇÃO DO TEMA................................................................................................... 12

1.2. JUSTIFICATIVA PARA A ESCOLHA DO TEMA................................................................................ 12
1.3. MÉTODO DE PESQUISA ADOTADO ............................................................................................... 12
1.4. ESTRUTURA DO TRABALHO.......................................................................................................... 13
2. ENGENHARIA DE SOFTWARE ................................................................................................. 14
2.1. METODOLOGIAS TRADICIONAIS .................................................................................................. 15

2.1.1. O CICLO DE VIDA CLÁSSICO ...................................................................................................... 16
2.2. METODOLOGIAS ÁGEIS ................................................................................................................ 18
2.2.1. EXTREME PROGRAMMING (XP) ............................................................................................... 23
2.2.2. FEATURE DRIVE DEVELOPMENT (FDD) .................................................................................. 23
2.2.3. ADAPTIVE SOFTWARE DEVELOPMENT (ASD) ......................................................................... 24
2.2.4. SCRUM......................................................................................................................................... 25
2.2.5. DYNAMIC SYSTEM DEVELOPMENT METHOD (DSDM) ........................................................... 25
2.2.6. CRYSTAL ..................................................................................................................................... 26
2.2.7. CICLO DE VIDA DOS MÉTODOS ÁGEIS...................................................................................... 26
2.2.8. COMPARATIVO ENTRE METODOLOGIAS TRADICIONAIS E METODOLOGIAS ÁGEIS ............. 29
3. METODOLOGIA ÁGIL SCRUM .............................................................................................. 32
3.1. CICLO DE VIDA........................................................................................................................... 34

3.1.1. PRÉ-GAME ............................................................................................................................... 35
3.1.1.1. PLANEJAMENTO ................................................................................................................... 36
3.1.1.2. ARQUITETURA ...................................................................................................................... 38
3.1.2. GAME .......................................................................................................................................... 38
3.1.3. PÓS-GAME .................................................................................................................................. 39
3.2. ARTEFATOS ................................................................................................................................... 40
3.2.1. PRODUCT BACKLOG .................................................................................................................. 40
3.2.2. PLANNING POKER ...................................................................................................................... 41
3.2.3. SPRINT BACKLOG....................................................................................................................... 42
3.2.4. SPRINT BURNDOWN CHART ...................................................................................................... 43
3.2.5. SPRINT TASK BOARD VIEW ....................................................................................................... 44
3.3. PAPÉIS ............................................................................................................................................ 45
3.3.1. DONO DO PRODUTO/ PRODUCT OWNER ................................................................................... 45
3.3.2. MESTRE SCRUM / SCRUM MASTER ........................................................................................... 46
3.3.3. EQUIPE DE PROJETO / TEAM MEMBERS................................................................................... 48
3.4. REUNIÕES SCRUM (CERIMONIES) ................................................................................................ 48
3.4.1. REUNIÕES GERAIS (GENERAL MEETING) ................................................................................ 49
3.4.2. REUNIÃO DE ESTIMATIVA (ESTIMATION MEETING) ............................................................... 49
3.4.3. REUNIÕES DE PLANEJAMENTO DO SPRINT ( SPRINT PLANNING) ........................................... 50
3.4.4. REUNIÕES DIÁRIAS SCRUM (DAILY MEETING) ....................................................................... 51
3.4.5. REUNIÃO DE REVISÃO DO SPRINT (SPRINT REVIEW) .............................................................. 52
3.4.6. REUNIÃO DE RETROSPECTIVA (RETROSPECTIVE) .................................................................. 54
4. GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE COM A
METODOLOGIA SCRUM ................................................................................................................ 56
4.1. DEFINIÇÃO DO GERENCIAMENTO ÁGIL DO PROJETO................................................................. 56

4.1.1. OBJETIVOS, VALORES, PRINCÍPIOS E FASES DO GERENCIAMENTO DE PROJETOS ÁGEIS ... 58
4.2. GERENCIAMENTO DE PROJETOS DE SOFTWARE USANDO O SCRUM .......................................... 63
5. ESTUDO DE CASO ..................................................................................................................... 70
5.1. CARACTERIZAÇÃO DA EMPRESA.................................................................................................. 70

5.2. CONDUÇÃO DO ESTUDO DE CASO ................................................................................................ 71
5.3. TABULAÇÃO DOS DADOS .............................................................................................................. 72
CONCLUSÃO ..................................................................................................................................... 79
REFERÊNCIAS .................................................................................................................................. 81
ANEXO 1 – DECLARAÇÃO PARA REALIZAR ESTUDO DE CASO ........ ERRO! INDICADOR

NÃO DEFINIDO.
ANEXO 2 – ARTEFATOS PERTINENTES AO ESTUDO DE CASO ......................................... 87

1. INTRODUÇÃO
A cada dia o mercado atual procura por novas tecnologias e meios inovadores para que
o mesmo tenha um diferencial competitivo em relação aos seus concorrentes. A grande
necessidade de métodos mais ágeis e aptos a novas mudanças é a grande preocupação para o
mercado, seja ele que atua no ramo de Desenvolvimento de Software ou em qualquer outro
segmento (MARTINS, 2007).
Neste contexto, a busca por inovações de métodos ágeis e de total qualidade para o
gerenciamento de software é o que torna o diferencial para as empresas, colocando-as em
destaque em relação as outras no mercado competitivo.
O desenvolvimento de software não é uma atividade profissional simples, em que seus
métodos e processos são fixos e inalterados do início ao fim do projeto, muito pelo contrário
um software pode sofrer várias alterações no seu processo de desenvolvimento, porém o
mesmo deve estar apto a receber essas novas mudanças.
A Engenharia de Software está sempre evoluindo junto com as novas tecnologias,
pode-se afirmar isso de acordo com alguns processos e métodos que surgiram há duas décadas
atrás e que hoje são considerados métodos tradicionais e pesados, em termo de documentação.
Tais métodos são considerados pesados, pois sua documentação é extensa e gasta-se muito
tempo para elaborá-la, ainda mais quando se trata de um projeto que tenha uma equipe de
desenvolvimento pequena. A documentação é de extrema importância para a qualidade de um
projeto, mas a mesma pode ser mais enxuta, ou seja, não tão detalhada o que economiza
tempo, que é um grande fator em termos de diferencial competitivo e dessa maneira os
projetos são entregues em menor prazo e com qualidade (KOSCIANSKI; SOARES, 2007).
Com o propósito de agilizar o processo de desenvolvimento de software e tornar seu
gerenciamento mais rápido surgiu, em 2001, o Manifesto Ágil, cujo seus objetivos são
justamente atender as inovações contínuas, adaptabilidade de produtos, entregas com
cronograma reduzido, adaptabilidade do processo e das pessoas e por fim resultados
confiáveis (MARTINS, 2007).
Este trabalho tem por objetivo apresentar conceitos fundamentais do que são
metodologias ágeis para gerenciamento de projeto, mostrando como exemplo a metodologia
Scrum e seu funcionamento, ciclo de vida com suas respectivas fases, vantagens que essa
metodologia trás em gerenciar projetos com agilidade dando ampla satisfação aos clientes.
Metodologia Ágil de Gerenciamento de Projetos - Scrum – 12
1.1. Contextualização do Tema
A metodologia Scrum é uma metodologia ágil e leve que propõe justamente o que as
empresas atuais buscam: minimizar custos, tempo e principalmente garantir a qualidade do
sistema entregue.
A metodologia Scrum está apta a atender demandas de mudanças em projetos de
desenvolvimento de software, mesmo que tais projetos já estejam em andamento, diferente
das metodologias tradicionais. Scrum possui um controle de gerenciamento muito propício
para cenários inovadores. Foi em busca da agilidade na adaptação à mudanças, organização,
satisfação do cliente no sistema entregue, entre outros fatores, que então surgiram as
metodologias ágeis (MARTINS, 2007).
1.2. Justificativa para a escolha do Tema
Este trabalho tem como relevância mostrar aos gerentes de projetos, para empresa
como um todo e também para os clientes quais são os benefícios que a Metodologia Ágil de
Gerenciamento de Projetos - Scrum trás, mostrar a facilidade de implantá-la na empresa,
assim como a organização que ela propõe à empresa tanto em termos de controlar como
também em termos de gerenciar um projeto.
1.3. Método de Pesquisa Adotado
Este trabalho adotou duas metodologias: Revisão Bibliográfica e Estudo de Caso.

Inicialmente, foi realizada uma revisão de literatura, que segundo Cervo e Bervian (1996)
procura explicar um problema a partir de referências teóricas publicadas em documentos. Seu
principal objetivo é conhecer e analisar as contribuições culturais ou científicas do passado
existentes sobre um determinado assunto, tema ou problema, como este método também é
capaz de reunir conhecimentos sobre um tema, o mesmo pode servir de auxílio para a
identificação da pesquisa, bem como possibilitar o desenvolvimento das questões pertinentes
ao estudo. Com a adoção deste método foi realizado a pesquisa por meio de artigos, livros,
internet, dissertações, no qual compilaram-se as informações referentes à questão de gerenciar
projetos com metodologias ágeis como Scrum. Por fim, adotou-se o método de Estudo de
Caso, que segundo Yin (2005), consiste em uma investigação empírica que investiga um
fenômeno contemporâneo dentro de seu contexto na vida real. O estudo de caso foi aplicado
em uma Fábrica de Software, no qual seus dados foram coletados por meio de uma entrevista,
aplicada para alguns envolvidos da empresa, a fim de obter resultados concisos e reais da
metodologia Scrum.
1.4. Estrutura do Trabalho
Este trabalho é composto por 5 seções organizadas da seguinte forma:
Primeira seção: Nesta seção foi apresentada a introdução caracterizando-se a

contextualização do tema na qual o trabalho se encontra inserido, a justificativa para a escolha
do tema e o método de pesquisa adotado.
Segunda seção: Esta seção aborda os conceitos de Engenharia de Software, destacando
as metodologias existentes para desenvolver e gerenciar softwares, descrevendo algumas
metodologias ágeis utilizadas hoje pelo mercado.
Terceira seção: Nesta seção é apresentada as principais características e práticas da
Metodologia Ágil Scrum, é representado seu ciclo de vida e as respectivas atividades, papéis e
artefatos que o contém.
Quarta seção: Esta seção aborda os conceitos de Gerenciamento de Projetos,
baseando-se nas práticas do PMBOK, e mostra como a metodolgia Scrum é propícia para
gerenciar projetos inovadores e ágeis, proporcionando ao clientes entregas rápidas, prontidão
em adaptar mudanças, cumprimento de prazos e produto com qualidade.
Quinta seção: Nesta seção é apresentado um Estudo de Caso que foi aplicado a uma
Fábrica de Software, em Araraquara, no qual a fábrica utiliza a metodologia Scrum para
Gerenciar projetos. Por meio de entrevistas, foram levantados e coletados os resultados que a
metodologia agregou para a empresa.
E por fim, tem-se a conclusão do trabalho, obtido pelo seu desenvolvimento.
2. ENGENHARIA DE SOFTWARE
Segundo Pressman (1995), no início da década de 1980 já haviam reportagens e

manchetes anunciando o amadurecimento e o poder do software. Essas manchetes
anunciavam uma nova compreensão da importância do software de computador, assim como
as oportunidades e os perigos que o mesmo apresentava.
O crescimento da Engenharia de Software é acelerado e constante dia após dia, tanto
para o meio acadêmico, onde ela é considerada uma disciplina fundamental, para diversas
cadeiras, estando presente em todos os anos letivos, quanto para o meio profissional de
desenvolvimento de software, que busca sempre a melhor maneira para evitar riscos e
garantir ao cliente a qualidade e satisfação no produto final (REZENDE, 2005).
Para Pressman (1995), a Engenharia de Software abrange um conjunto de três
elementos fundamentais tanto para hardware quanto para software, são eles: Métodos,
Ferramentas e Procedimentos.
 Métodos: Proporcionam os detalhes de “como fazer” para construir um

software, ou seja, são os procedimentos para produzir o resultado.
 Ferramentas: Proporcionam aos métodos um apoio automatizado ou semi-
automatizado para realizar tarefas da melhor forma possível, de maneira
precisa, eficiente e produtiva.
 Procedimentos: Proporcionam o resultado específico através do elo que existe
entre os métodos e as ferramentas. Os procedimentos definem a seqüência em
que os métodos serão aplicados; os produtos que serão entregues assim como
seus documentos, relatórios, formulários; os controles que ajudam a assegurar
a qualidade e coordenar as mudanças necessárias e os marcos de referência
que possibilitam aos gerentes de software avaliar o progresso dos projetos.
Os três elementos descritos acima juntos oferecem ao gerente de software o controle
do processo de desenvolvimento de software e possibilitam ao profissional produzir uma base
para a construção de software de alta qualidade.
De acordo com Martins (2007), a Engenharia de Software possui diversos aspectos
semelhantes à Engenharia Civil, dentre eles a preocupação em definir o contexto para o
projeto e entender a necessidade do negócio. Desta forma, é avaliado o tempo e o custo para a
solução do negócio.
Há uma pequena diferença entre a Engenharia Civil e a Engenharia de Software, sendo
que na primeira o projeto é planejado e executado de forma seqüencial, na segunda nem
sempre essa é a melhor maneira, este aspecto depende muito do projeto, para isto é necessário
analisar a melhor abordagem a ser aplicada. Existem diferentes metodologias para conduzir
projetos de desenvolvimento de software, que tratam desde a construção do software até a sua
implementação.
2.1. Metodologias Tradicionais
De acordo com Martins (2007) as metodologias tradicionais, possuem os processos

definidos (ou prescritivos), onde todo o contexto do projeto, assim como, o escopo das
entregas é definido no início do projeto. Dessa forma, há a necessidade de que toda
documentação seja bem definida e detalhada, um dos motivos esse, que torna essa abordagem
pesada.
Tal metodologia também chamada de abordagem clássica, é mais adequada em
situações onde os requisitos a serem executados são bem conhecidos, ou seja, são raras as
alterações, adaptações, mudanças em geral. Além de tudo, os processos de entrada
dificilmente variam, devido ao conhecimento abrangente e acurado sobre os requisitos e ao
resultado final.
Segundo Caetano (2010), dependendo do projeto as metodologias tradicionais podem
deixar os desenvolvedores amarrados a requisitos desatualizados que muitas vezes não
correspondem às reais necessidades do cliente. No mercado atual, a competitividade é um
fator altamente relevante, sendo assim, a busca por agilidade, prazo de entrega e custo são
aspectos que determinam a permanência das empresas no mercado. Dessa maneira, as
empresas que desenvolvem software buscam por metodologias inovadoras e que estão prontas
para suprir as novas mudanças e as necessidades dos clientes. A soma de todos esses fatores
citados, junto com a qualidade do produto final, é o que resulta na satisfação do cliente.
2.1.1. O ciclo de vida Clássico
Segundo (PRESSMAN,1995) o ciclo de vida clássico, também chamado de Modelo

Cascata, propõe que o software seja desenvolvido de maneira sistemática e seqüencial desde o
início do sistema até seu término, ou seja, desde o levantamento e análise de requisitos até a
codificação, testes e manutenção. A Ilustração1 esboça a seqüência das atividades do ciclo de
vida clássico.
Ilustração 1- Ciclo de vida Clássico.

Fonte: Pressman (1995).
Na primeira atividade, denominada análise e engenharia de sistemas, o principal foco é

analisar todo o sistema, no qual o software a ser desenvolvido fará parte. Nessa etapa o
analista tem conhecimento do sistema no qual o software será implantado. Algumas
características mais importantes são: hardware, banco de dados, sistema operacional e
usuários.
Na segunda atividade é feita a análise de requisitos de software. Nesse momento
ocorre todo o processo de levantamento de requisitos referente ao software específico, ou seja,
o analista de software precisa ter conhecimento acurado sobre todas as funcionalidades, assim
como as interfaces e templates solicitados pelo cliente. Nesta etapa também é elaborada a
documentação que deve ser analisada e avaliada pelo analista e pelo cliente.
Na terceira atividade conhecida como projeto, utilizando do conhecimento obtido nas
atividades anteriores tem início a definição do software. O projeto de software é um processo
constituído de múltiplos passos, sendo os mais importantes a estrutura de dados, os detalhes

procedimentais e caracterização da interface. Da mesma forma, como ocorre com os
requisitos na atividade anterior, o projeto também é documentado.
Na quarta atividade denominada codificação, o projeto da atividade anterior, depois de
revisado e avaliado, é transcrito de forma legível, para uma linguagem de máquina. A
intenção é que o projeto seja o mais detalhado possível para possibilitar uma codificação
rápida e sem contratempos.
Na quinta atividade são realizados os testes. Essa é uma etapa muito importante para o
software, pois através dos testes é permitido confirmar e validar se as funcionalidades do
código escrito estão corretas, desta maneira, é possível verificar se o sistema esta com o
desempenho e usabilidade adequados para que o usuário possa usufruir do mesmo com
sucesso.
Na sexta e última atividade denominada manutenção, é dado todo o suporte necessário
para o software após o mesmo ser entregue para o cliente.Nesta atividade geralmente são
tratadas algumas mudanças exigidas pelo usuário, seja ela proveniente de inconsistência com
os requisitos levantados no início do projeto, ou mudanças novas no software que surgiram
devido a outras necessidades do cliente, como por exemplo, se o sistema operacional foi
atualizado, ou se mudou alguma regra de negócio. A manutenção de software segue todas as
atividades descritas anteriormente, porém a diferença é que desta vez trata de aplicá-las em
um software existente, e não a um novo.
De acordo com Koscianski e Soares (2007) esse modelo provavelmente foi a primeira
metodologia publicada de desenvolvimento de software e apresenta como uma de suas
principais características a seqüência de etapas. No término de cada etapa há uma
documentação que deve ser aprovada para que a etapa posterior possa ter início, essa
abordagem não prevê mudanças das especificações, o que a torna inflexível.
De maneira geral, o modelo clássico deve ser usado somente quando se tem
conhecimento amplo sobre os requisitos, ou seja, quando os mesmos forem estáveis não
havendo constantes mudanças, pois o custo das alterações do software é muito elevado, ainda
mais se essas mudanças ocorrerem após a entrega do software, isso pode trazer um prejuízo
de custo cem vezes mais que as alterações realizadas na fase de levantamento de requisitos,
sem falar na documentação que terá que ser alterada de acordo com os novos requisitos, e por
conseqüência o resultado desse projeto modificado terá o limite do tempo excedido, custo
elevado e retrabalho (KOSCIANSKI; SOARES, 2007).
A Ilustração 2 representa como o custo de uma modificação torna-se mais elevado

com o tempo.
Ilustração 2 - Custo de Modificações no modelo Clássico.

Fonte: Koscianski e Soares (2007).
2.2. Metodologias Ágeis
Segundo Soares (2010), as metodologias ágeis têm sido apontadas como uma
alternativa às abordagens tradicionais para o desenvolvimento de software, e suas principais
características são: estar aptas a aceitação de mudanças de requisitos, onde refazer ou
incrementar partes do código não é uma atividade que apresenta altos custos; as equipes são
pequenas, o que possibilita ter uma boa troca de comunicação entre os membros da mesma; as
datas de entrega do software são curtas, permitindo que o cliente veja o software em etapas e
o desenvolvimento é rápido.
As metodologias ágeis são adequadas para situações em que a mudança de requisitos é
freqüente, de tal maneira que a metodologia deve estar apta a aceitar as mudanças em vez de
tentar prever o futuro (KOSCIANSKI; SOARES, 2007).
A entrega do projeto para esses tipo de metodologia, é definido de forma abrangente e
superficial, tendo início por um contexto que ao decorrer do processo do projeto pode ser
evoluído, ou seja, o escopo que foi estipulado inicialmente pode ser alterado, muitas vezes o
cliente acaba descobrindo novas necessidades e solicita que as mudanças sejam inseridas no
projeto, isso ocorre por ser uma metodologia de escopo aberto.
Esta metodologia tem controle empírico de processo e é indicado para ser utilizado em
projetos em que o processo é complexo para produzir resultados similares, pois o mesmo
varia constantemente.
O processo empírico é definido de forma inexata, o que acaba gerando resultados
imprevisíveis. Assim, este processo requer um acompanhamento dedicado, com inspeções
freqüentes e adaptações durante todo projeto. Este método é o mais adequado para projetos
que passam por alterações e inovações constantes, como o desenvolvimento de software, por
exemplo, que muitas vezes é modificado porque o cliente não se identificou com o software,
ou o sistema, como um todo, onde o software seria implantado foi alterado, ou até mesmo
porque houve a necessidade de se adaptar a novas tecnologias e os pré- requisitos inicias do
software não atendem mais ao escopo inicial, um exemplo disso, é o hardware ou o sistema
operacional ser alterado por conseqüências de avanços tecnológicos (MARTINS, 2007).
De acordo com Koscianski e Soares (2007) pode-se traçar uma comparação entre as
metodologias clássicas e ágeis por meio da Ilustração 3, na qual se analisa a relação entre o
custo de mudança no software e a fase em que esta ocorre. A linha pontilhada representa essa
relação para uma metodologia clássica, enquanto a linha contínua mostra como se espera que
a relação melhore nas metodologias ágeis.
Ilustração 3 - Comparação do custo de mudanças entre metodologias clássicas e ágeis.

Fonte: Koscianski; Soares (2007).
Segundo Beck et al. (2002) apud Koscianski e Soares (2007) o termo “Metodologias
Ágeis” tornou-se popular em 2001, quando 17 especialistas em processos de desenvolvimento
de software, que representava os métodos Extreme Programming (XP), Scrum, Dynamic
Systems Development Method (DSDM), Crystal, estabeleceram princípios comuns
compartilhados por todos esses métodos e obtiveram como resultado a criação da Aliança
Ágil e o estabelecimento do Manifesto Ágil. Apesar das metodologias ágeis possuírem
variação em termos de práticas e ênfases, as mesmas compartilham algumas características
como desenvolvimento iterativo e incremental, comunicação e redução de produtos
intermediários, como documentação extensiva.
Os quatro conceitos-chave do Manifesto Ágil enfatizam:
 Indivíduos e interação em vez de processos e ferramentas: os fatores mais

importantes a considerar são as pessoas e como elas trabalham juntas. Para
construir ou desenvolver software há um grupo de pessoas essências como
programadores, testadores, gerentes do projeto, modeladores e clientes, e se
não houver uma boa sintonia entre ambos de nada adianta ter as melhores
ferramentas e processos;
 Software executável em vez de documentação: em várias ocasiões é mais útil
um protótipo simples que mostre o funcionamento de uma arquitetura, ou
ainda, o funcionamento de uma parte do sistema do que um grande e complexo
diagrama de classe ou diagrama de casos de usos. Isso não quer dizer para
abandonar o processo de documentação, mas sim minimizá-lo deixando-o
menos extenso, de modo a usar a ferramenta certa para transmitir a informação
desejada no momento;
 Colaboração do cliente ao invés de negociação de contratos: mesmo que
seja difícil o cliente acertar logo na primeira reunião o que ele espera como
resultado final do software solicitado, a colaboração do mesmo é essencial.
Isso porque, em um primeiro momento, o cliente pode não ter conhecimento
suficiente para especificar o sistema, e como conseqüência de tal fato
constantemente altera e/ou adiciona novos requisitos. Ter um contrato com o
cliente também é importante, pois através dele pode-se entender os direitos e
responsabilidades de cada um,entretanto somente o contrato pode não ser
suficiente, a comunicação com o cliente é essencial para um melhor

entendimento do resultado final;
 Respostas rápidas a mudanças em vez de seguir planos: a medida que o
sistema vai ganhando corpo e é apresentado ao cliente, a compreensão sobre o
sistema começa a mudar, os clientes captam a necessidade de alguns ajustes
e/ou novas alterações, pois o que ele está vendo não está do modo como
esperava ver. A mudança é algo esperado no desenvolvimento de software,
assim, embora existindo um plano de projeto traçado, este plano deve estar
apto as possíveis mudanças que surgirão no decorrer do projeto.
Os quatro valores do Manifesto Ágil deram origem a 12 princípios que sustentam o

desenvolvimento ágil (MANIFESTO, 2001):
1. A maior prioridade é satisfazer o cliente através da entrega contínua e rápida de

software que possua valor.
2. Mudanças nos requisitos são bem vindas, seja por motivos de alterações de
requisitos ou até mesmo por novas necessidades que surgiram no decorrer do
desenvolvimento, tais mudanças são aceitas mesmo quando realizadas
tardiamente.
3. Freqüentemente devem-se entregar versões do software funcionando, de
preferência em períodos curtos.
4. Clientes, ou representantes do cliente, devem trabalhar em conjunto com
desenvolvedores ao longo de todo o projeto.
5. O projeto deve ser construído com pessoas motivadas. Para tanto, deve ser
disponibilizado o ambiente e o suporte necessário, e é imprescindível confiar
no potencial da equipe.
6. A conversa “cara-a-cara” é o método mais eficiente para colher informações
sobre o projeto com o cliente.
7. Software funcionando é a melhor medida de progresso do projeto e não
documentação.
8. Processos ágeis promovem desenvolvimento sustentável. Stakeholders, clientes
e desenvolvedores devem descobrir o ritmo de trabalho e mantê-lo
constantemente.
9. Atenção contínua a excelência técnica e a um bom projeto promove a

agilidade.
10. Simplicidade é essencial.
11. As melhores arquiteturas, requisitos e projeto provêm de equipes auto-
organizadas.
12. A equipe deve refletir, em intervalos regulares, como se tornar mais eficiente e,
dessa forma, deve ajustar o seu comportamento conforme as necessidades.
Essas mudanças de paradigmas sobre o processo de desenvolvimento e gerenciamento

de software são o que denotam as principais diferenças entre metodologias tradicionais e
metodologias ágeis. Dessa maneira, as equipes de desenvolvimento, sujeitas a essas novas
abordagens, devem absorver esses novos princípios e pensar no processo de desenvolvimento
de forma diferente da tradicional com entregas sendo realizadas de forma contínua, iterativa e
incremental. Esse novo paradigma permite o cliente solicitar e priorizar o que deve ser feito
pela equipe de software, que deve focar-se nas solicitações, e assim, juntamente ao cliente,
realizar validações contínuas do sistema.
O manifesto ágil mostra que processo e ferramentas, documentação, negociação de
contratos e planejamento tem importância secundárias quando comparadas com os indivíduos,
com o software executável, porém isso não significa que as mesmas sejam rejeitadas, quer
dizer apenas que com a colaboração dos clientes as respostas às mudanças tornam-se mais
rápidas e precisas. Esses conceitos aproximam-se melhor da forma como as pequenas e
médias empresas trabalham e respondem às mudanças (Koscianski e Soares , 2007).
A agilidade pode ser aplicada a qualquer processo de software, desde que tenha um
bom planejamento onde a equipe de projeto possa se adaptar as tarefas e aperfeiçoá-las
eliminando barreiras e mantendo os produtos de trabalhos essenciais o mais simples possível.
Desta forma, é preciso enfatizar a estratégia incremental onde o cliente possa dar o feedback
do produto através da visualização, ou do contato com o software funcionando o quanto antes,
se possível em tempos curtos, isso faz com que o processo torne-se ágil permitindo adaptar
modificações rápidas no projeto e nas condições técnicas quando necessário (PRESSMAN,
2006).
2.2.1. Extreme Programming (XP)
De acordo com Beck apud Martins (2007), o método Extreme Programming (XP)
endereça as limitações do processo de desenvolvimento de software, usando a abordagem
orientada a objetos. Não é o foco do XP abordar o processo de gerenciamento de projetos,
análise financeira, marketing ou vendas, o que não quer dizer que estas áreas não são
cumpridas, apenas não são abordadas diretamente.
O XP inclui um conjunto de regras e práticas que ocorrem no contexto de quatro
atividades de arcabouço: planejamento, projeto, codificação e teste (PRESSMAN, 2006).
O foco do desenvolvimento de software no XP segue um estilo de excelência da
aplicação das técnicas de programação, comunicação clara e trabalho em equipe.
De acordo com Beck (2005) apud Martins (2007) o XP promove a excelência no
desenvolvimento de Software e diferencia-se de outras técnicas pelas seguintes
características:
 Iterações curtas, o que resulta em feedbacks rápidos, concretos, contínuos;
 Abordagem incremental de planejamento, podendo evoluir durante o ciclo de
vida do projeto;
 Consegue responder mais rápido as necessidades de mudanças de negócios, por
ter um bom planejamento na implantação das funcionalidades do software;
 Usa mecanismos automatizados para realizar testes, o que permite aos
programadores, equipe de qualidade e até mesmo aos clientes desenvolverem
os testes e monitorá-los, permitindo verificar o progresso de desenvolvimento e
também observar a evolução e identificar defeitos para que o mesmo seja
corrigido o quanto antes.
2.2.2. Feature Drive Development (FDD)
Segundo Martins (2007), o FDD foi concebido para ser utilizado tanto em projetos de
desenvolvimento de novos software como em projetos para evoluir software existentes. O
projeto possui uma lista de requisitos funcionais, que são utilizados na fase inicial do projeto,
esses requisitos funcionais são chamados de features. Tal lista é constituída apenas pelos
requisitos funcionais que são entendidos pelo cliente e tem valor para o negócio. As features
são utilizadas também para planejar e gerenciar o projeto, desta maneira os clientes podem
priorizar as features em função da sua importância para o negócio.
No contexto do FDD as features podem ser implantadas em duas semanas ou menos.
Abaixo, alguns benefícios que as features possuem:
 Como as features são pequenos blocos de funcionalidade que serão entregues
os usuários podem analisar, revisar e entender mais facilmente como elas se
relacionam umas com as outras, identificando possíveis ambigüidades, erros ou
omissões.
 As features podem ser organizadas em um agrupamento hierárquico
relacionado ao negócio.
 A entrega do FDD é um incremento de software, onde a equipe desenvolve
características operacionais a cada duas semanas.
 Facilidade para inspeções efetivas devido as features serem pequenas.
2.2.3. Adaptive Software Development (ASD)
Segundo Pressman (2006), o ASD (Adaptive Software Development) foi proposto por
Jim Highismith como uma técnica para construção de sistemas e software complexos. O ASD
possui como filosofia a concentração na colaboração humana e na auto-organização da
equipe.
Além do ASD prover o desenvolvimento de software complexos e de grande porte, ele
também possui uma cultura adaptativa onde há colaboração, desenvolvimento iterativo e
incremental baseado em componentes que fazem parte do ciclo adaptativo.
A filosofia ASD preocupa-se mais com os conceitos e cultura organizacional que com
práticas de software (ABRAHAMSSON, 2002).
A ênfase do ASD está na dinâmica de equipes auto-organizadas, na colaboração
interpessoal e no aprendizado individual e em capacitar equipes de projeto de software que
tenha uma probabilidade de sucesso muito maior (PRESSMAN, 2006).
2.2.4. Scrum
Segundo Caetano (2009), atualmente a metodologia ágil que está em evidência é o

Scrum e uma das principais características deste método é que o cliente se torna parte
integrante da equipe de desenvolvimento de software.
De acordo com Silva (2009), Scrum é uma metodologia de gerência de projetos que
possui um processo leve, visando gerenciar e controlar o desenvolvimento de software. Dessa
maneira, ao invés de promover a tradicional abordagem do modelo cascata (análise –
modelagem – codificação – teste – instalação do sistema). Scrum adota as prática iterativa e
incremental que não é dirigido a artefatos, onde há documentos de requisitos, especificações ,
documentos de modelagem e diagramas extensos. Pelo contrário, Scrum exige poucos
artefatos, pois sua maior preocupação está em gerenciar projetos e codificar softwares que
produzam valores de negócio.
A metodologia Scrum possui uma forma de trabalho flexível em ambientes dinâmicos,
onde há tratamento de mudanças de requisitos de software, assim como, trocas de equipes,
adaptações de cronogramas e orçamento, troca de ferramentas de desenvolvimento ou até
mesmo de linguagens de programação.
A metodologia possui alguns princípios semelhantes ao XP, onde as equipes são
pequenas, trabalhando com requisitos instáveis ou até mesmo desconhecidos e utilizando de
iterações curtas, o que promove visibilidade para o desenvolvimento (KOSCIANSKI;
SOARES, 2007).
2.2.5. Dynamic System Development Method (DSDM)
O DSDM é uma abordagem ágil de desenvolvimento de software que provê

construção e manutenção de sistemas através de um ambiente controlado de projeto, contendo
restrições de prazos utilizando-se de prototipagem incremental. Esta abordagem também
trabalha com iterações onde as entregas são freqüentes, sendo que, 80% de uma aplicação
podem ser entregue em 20% do tempo que levaria para entregar a aplicação completa (100%).
Em cada iteração é desenvolvido parte das tarefas requisitadas e só quando as mesmas

forem aceitas é que se avançam os incrementos, contendo novos requisitos de negócio ou
modificações quando forem solicitadas e aprovadas.
O DSDM recomenda utilizar cronogramas a cada intervalo de tempo, e sugere também
que em cada incremento de software seja utilizado apenas o necessário para realizar o
trabalho, isso facilita o avanço para os demais incrementos do sistema (PRESSMAN, 2006).
2.2.6. Crystal
Crystal é uma família de modelos ágeis de processos que são adotados de acordo com
características específicas de cada projeto, dessa maneira, pode ser aplicado a projetos de
tamanhos e complexidades diferentes (PRESSMAN, 2006).
A família Crystal caracteriza os projetos definindo cores diferentes a cada um, tais
cores variam entre amarelo, laranja e vermelho. As cores são definidas com base na
complexidade, tamanho e importância dos projetos, quanto maior e mais rigoroso o projeto a
cor é mais forte.
A família Crystal possui o desenvolvimento incremental com ciclos de no máximo
quatro meses, e da ênfase na comunicação e cooperação das pessoas (ABRAHAMSSON et
al., 2002).
2.2.7. Ciclo de Vida dos Métodos Ágeis
De acordo com Ramos (2010), o modelo ágil de desenvolvimento de software surgiu

nos últimos anos em contraposição ao modelo cascata e consiste em uma série de ciclos ou
iterações curtas que geralmente tem duração de semanas. Cada um dos ciclos funciona como
mini-projetos dentro de um projeto maior, o projeto original. Esses mini-projetos que
compõem os ciclos possuem as mesmas atividades e características de um projeto, sendo que
no final de cada ciclo obtêm-se como resultado a implantação de uma parte da funcionalidade
requisitada.
No modelo de ciclo de vida ágil destacam-se as seguintes vantagens:
 Diminuição da expectativa dos clientes por meio de entregas: com as

entregas realizadas por pequenas partes através de ciclos, também chamados de
Sprints no Scrum, o cliente e/ou os interessados no produto conseguem ter uma
visão se o software que está sendo desenvolvido conforme o esperado.
 Rápida adaptação a mudanças: adaptações e mudanças de novas
funcionalidades podem ser realizadas continuamente no decorrer do projeto,
porém as mesmas são analisadas para garantir que não causem nenhum tipo de
problema para o desenvolvimento do projeto ou para o negócio.
 Maior satisfação dos clientes: com entregas rápidas e prontidão nas
adaptações de possíveis mudanças.
Com as vantagens citadas acima, o ciclo de vida ágil promove a geração de valores de
negócio a cada nova iteração. Ao contrário do modelo cascata, ciclo de vida clássico, onde há
todo um planejamento inicial contendo o levantamento e análise de requisitos, projeto,
codificação, teste e por fim entrega e manutenção, o modelo de ciclo ágil permite com que o
planejamento possa ser feito em paralelo com o desenvolvimento de cada iteração,
considerando os resultados das iterações anteriores, assim como adaptando possíveis
mudanças de prioridades requisitos de negócios, e identificando o desempenho das equipes de
desenvolvimento.
De acordo com Ambler (2010) o fato do desenvolvimento de sistema ser complexo
tornou o ciclo de vida de desenvolvimento de software bastante dinâmico, pois há muito mais
a ser analisado, relacionado a tecnologia da informação do que somente o desenvolvimento.
Desta forma Ambler sugere que o ciclo de vida possua mais fases que as apresentadas, por
exemplo, no Scrum, e que cubram todo o ciclo de vida do desenvolvimento do sistema
(System Development Life Cycle – SDLC).
O SDLC ágil proposto por Ambler é composto de seis fases, que são Iteração -1
(menos um), Iteração 0 (zero), Construção, Release (Fim do jogo), Produção e Aposentadoria
(Retirement). Tais fases podem ser visualizadas na Ilustração 4.
Ilustração 4 - Ciclo de vida ágil do desenvolvimento de sistema.

Fonte: SDLC (adaptado de AMBLER, 2010).
Na fase de Iteração -1, planejamento ou pré-projeto, é realizado uma análise inicial do

negócio ou projeto em questão, buscando identificar e entender quais são os objetivos e
necessidades dos interessados no projeto, também conhecidos como stakeholders. Através
dessa análise inicial é possível identificar a viabilidade de realização do projeto, a estratégia
que deverá ser aplicada para o seu desenvolvimento, ou seja, desenvolver uma visão inicial do
sistema de maneira a identificar qual é o grande objetivo do projeto ou do negócio. É preciso
realizar essas atividades com agilidade, e contando sempre com o apoio e colaboração dos
stakeholders para que desta forma obtenha-se um entendimento do sistema permitindo tomar
decisão a respeito de levar ou não adiante o projeto.
Na fase Iteração 0 ou “Aquecimento” inicia-se o projeto e as principais atividades
referentes a obtenção do financiamento e suporte para o projeto, montagem da equipe de
desenvolvimento, montagem da arquitetura inicial do sistema e preparação do ambiente. Essa
fase refere-se a primeira semana ou primeira iteração. É nesta primeira iteração do projeto em
que, juntamente com o cliente, é obtido um escopo inicial do sistema que será refinado
durante as outras iterações.
Na fase de Iteração de Construção é onde o software é desenvolvido incrementalmente
e de forma colaborativa de acordo com as necessidades dos stakeholders. Nesta fase as
funcionalidades são desenvolvidas de acordo com a priorização determinada pelo cliente, que
detém o controle sobre o escopo, orçamento e cronograma do projeto. Ainda nesta fase são
realizadas a análise do projeto do software a ser desenvolvido. O desenvolvimento será
realizado seguindo o test driven design (TDD) no qual após a escrita de um teste deve ser
escrito o código que será validado por este teste. As entregas devem ser feitas regularmente e
a qualidade do produto desenvolvido deve ser constante. Para que a qualidade seja alcançada
pode- se haver padronização do código e de estilo de codificação, assim como, realização de
testes confirmatórios que combinam testes que confrontam o código desenvolvido e testes de
aceitação que confrontam os requisitos do sistema.
Na fase de Entrega ou Fim de Jogo (End Game) o sistema sai do ambiente de
desenvolvimento e vai para o ambiente de produção. É neste momento que são realizados
teste de sistema e de aceitação finais. Nesta fase ainda podem ser encontrados defeitos,
resultando em alguns retrabalhos de correção. É também nesta fase que finaliza-se a
documentação do sistema e do usuário e, por fim, realizam-se treinamentos com os usuários
do sistema e também com o pessoal responsável pelo suporte ao sistema.
Na fase de Produção, o objetivo é monitorar o sistema de maneira a identificar se ele
continua sendo utilizável e produtivo depois de ter sido instalado no ambiente do usuário, ou
seja, manter o sistema funcionando e prover suporte ao usuário quando necessário. Essa fase
encerra-se quando o suporte dado ao sistema se finaliza ou quando o software se torna inútil
caindo em desuso e entrando na fase “Aposentadoria” ou Retirement. Nessa fase o sistema
inteiro é removido do ambiente de produção, ou apenas uma determinada versão do sistema é
desativada.
Cada método ágil possui seu próprio ciclo de vida, respectivo a sua necessidade, na
próxima seção será apresentado o ciclo de vida ágil da metodologia Scrum.
2.2.8. Comparativo entre Metodologias Tradicionais e Metodologias Ágeis
As metodologias tradicionais adotam processos definidos para o desenvolvimento de

software, o que é diferente nas metodologias ágeis que utilizam processos empíricos. Na
Ilustração 5, é apresentado um comparativo identificando a diferença entre estas duas
abordagens.
Processo definido (clássico) Processo empírico (ágil)

Permite primeiro fazer uma especificação completa Raramente é possível fazer uma especificação
para depois construir o produto ou executar o inicial que seja detalhada e permaneça imutável.
serviço.
No inicio do projeto é possível fazer estimativas No inicio é praticamente impossível estimar o
com precisão razoável. projeto. À medida que os dados empíricos
emergirem vai ficando mais fácil planejar e
estimar.
Fornece informação sobre o estado interno do Fornece informação apenas sobre uma parte do
processo. processo, que pode ser influenciada por ações
de controle.
Promove um entendimento fundamental dos Trata o processo como uma “caixa preta”.
trabalhos internos do processo.
Requer um conhecimento abrangente e acurado Não requer conhecimento detalhado; mas um
sobre o processo. certo resultado pode ser obtido em resposta a
certas mudanças.
É possível identificar, definir, agendar e seqüenciar No início do projeto não é possível identificar as
todas as atividades de forma detalhada. atividades. São necessárias tarefas de adaptação
dirigidas pelos ciclos de contrói-avalia-adapta.
Adaptação devido a mudanças não previstas são A regra são as adaptações criativas que ocorrem
raras, e a taxa de mudanças é relativamente baixa. devido às mudanças não previstas. A taxa de
mudanças é bastante alta.
É mais adequado para processos de baixa Normalmente é a única alternativa para
complexidade e bem compreendido. processos complexos ou pouco compreendidos.
Ilustração 5 - Comparativo entre as abordagens clássica e ágil.

Fonte: Martins (2007).
Nesta seção foram apresentados alguns conceitos relacionados à Engenharia de

Software, sendo abordado as metodologias tradicionais e o ciclo de vida do modelo clássico,
assim como, foram apresentados os conceitos das metodologias ágeis, exemplos e ciclo de
vida , sendo está considerada uma alternativa para metodologia tradiconal.
Foi realizado também uma comparação entre as metodologias tradicionais e ágeis,
podendo chegar a um consenso de que a abordagem clássica possui um processo definido
onde há uma especificação dos requisitos predefinida a qualquer custo, ou seja, os requisitos
são conhecidos e estáveis, sendo que dessa maneira o envolvimento do cliente no projeto é
escasso. O grande foco da abordagem tradicional está em projetos grandes, onde há uma
grande preocupação com a documentação do sistema, pois a confiança do projeto está
centrada na documentação e é de acordo com ela que o sistema é desenvolvido. Dessa
maneira tal documentação deve ser bem detalhada e específica precavendo-se de retrabalho e
reestruturação no sistema, para que sejam evitados também custos e desperdícios pois o
processo que esta abordagem adota é definido e não esta apto a receber mudanças.
Já na abordagem ágil o processo é empírico, adaptativo onde a documentação do
sistema é bem enxuta, até mesmo porque os requisitos são mutáveis, ou seja, são adaptados ao
sistema conforme as solicitações de mudanças, o que também caracteriza essa abordagem

flexível.
O foco da abordagem ágil concentra-se em projetos inovadores, onde as equipes são
pequenas e médias, facilitando a adaptação e a auto-organização das mesmas. Essa
abordagem adota o cliente como parte integrante da equipe e seu comprometimento com o
projeto permitem que o resultado do projeto seja mais rápido e eficaz. Tendo o cliente como
parte da equipe as solicitações de mudança, assim como, a reestruturação e retrabalho tornam-
se mais baratos, pois no momento em que o cliente encontra necessidades de alterações no
sistema imediatamente o mesmo já notifica para que seja corrigida.
Na próxima seção será abordado os conceitos da metodologia ágil Scrum, e também
será representado seu ciclo de vida com suas respectivas fases, papéis e artefatos.
3. METODOLOGIA ÁGIL SCRUM
Martins (2007) e Camara (2008) afirmam que a origem do Scrum está associada a um
artigo chamado “O jogo do desenvolvimento de novos produtos” que foi publicado em
Harvard Bussiness Review em janeiro de 1986 e foi escrito por Takeuchi e Nonaka. O artigo
descreve um tipo de processo de desenvolvimento de produtos utilizado no Japão. Baseado
neste artigo, Jeff Sutherland em 1994 introduziu algumas das práticas descritas no artigo na
empresa Easel Corporation na qual trabalhava na época. Martins (2007) explica ainda, que
Jeff Sutherland foi influênciado por um relatório que indicava produtividade acima da média
nos projetos realizados na Borland Corporation, na qual haviam sido introduzidas as reuniões
diárias entre outras coisas. Em 1995 Ken Schwaber uniu-se a Jeff Sutherland na Easel
Corporation e juntos formalizaram o Scrum.
Tanto Martins (2007) quanto Camara (2008) explicam que o nome Scrum possui
origem de um jogo chamado Rugby, no qual, Scrum é o nome de uma reunião feita em círculo
entre os jogadores para decidirem a próxima jogada. Dessa forma, indica que o projeto deve
seguir em pequenos ciclos com a visão de longo prazo de ganhar o jogo.
Segundo Koscianski e Soares (2007), o Scrum é uma metodologia ágil que segue as
filosofias: iterativa e incremental. Iterativa devido ao projeto trabalhar com partes pequenas
por vez e incremental, pois, permite adaptar possíveis mudanças como alteração nos
requisitos de software e outras situações, como: trocas de equipes, adaptações de cronogramas
e orçamento, trocas de ferramentas de desenvolvimento ou mesmo de linguagens de
programação.
A concentração da metodologia Scrum está no gerenciamento de projetos e na criação
de produtos que agreguem valor ao negócio. O processo da metodologia Scrum é bastante
leve para gerenciar, controlar projetos de desenvolvimento de software e também para a
criação de produtos, devido a metodologia possuir uma forma de trabalho flexível, pronta para
adaptações em ambientes dinâmicos (MARTINS, 2007).
Os princípios do Scrum são usados para guiar as atividades de desenvolvimento dentro
de um processo que contêm as seguintes atividades: requisitos, análise, projeto, evolução e
entrega. Para tal processo existe um padrão chamado de Sprint que no qual ocorrem as tarefas
de trabalho de acordo com as atividades do projeto. O trabalho que é realizado em cada Sprint
é conduzido de acordo com a complexidade e com o tamanho do produto, sendo assim, a
quantidade de Sprints necessários para suprir as atividades é adaptado freqüentemente e

modificado em tempo real pela equipe Scrum (PRESSMAN, 2006).
Segundo Yoshima (2007), um projeto Scrum é composto por vários Sprints,
geralmente com um período de trinta dias. O autor afirma que não é viável que o período dos
Sprints varie, pois com um período de tempo fechado é mais fácil medir e avaliar o
desempenho, produtividade da equipe e os resultados de cada Sprint. Na Ilustração 6 exibe
como são representados os Sprints de um processo iterativo.
Ilustração 6 - Processo Iterativo.

Fonte: Yoshima (2007).
Para facilitar o entendimento do que ocorre em cada Sprint representado na Ilustração

6, o autor representa na Ilustração 7, o que contém dentro de tais Sprints, ou seja, ele exibe
como é planejado o período de trabalho, o qual a equipe tem que respeitar, desenvolver suas
tarefas para atender as regras de negócio e satisfazer os objetivos do cliente.
Ilustração 7 - Estrutura de um Sprint.

A Ilustração 7 representa os dias evoluindo no sentido horizontal. Neste caso o autor

padronizou este Sprint contendo trinta dias. Todos os Sprints possuem uma estrutura
exatamente igual, na qual no início é planejado o que deverá acontecer durante o Sprint para
cumprir o seu objetivo e por fim é avaliado se o planejado foi atendido e quais foram os seus
resultados, com base nestes resultados é possível obter lições aprendidas, experiências
possibilitando buscar melhoria contínua.
O Scrum enfatiza o uso de um conjunto de padrões de processo de software que têm
comprovada efetividade para projetos com prazos apertados, requisitos mutáveis e
criticalidade de negócio. Cada padrão de processo define um conjunto de tarefas de
desenvolvimento e permite à equipe Scrum construir um processo que seja adaptado às
necessidades do projeto (PRESSMAN, 2006).
3.1. Ciclo de Vida
Como Scrum é um framework que possui um conjunto de práticas objetivas, papéis

bem definidos e totalmente adaptáveis, seu ciclo de vida adota métodos de iterações, assim
como, atividades incrementais, o que permite ter um melhor controle e gerenciamento de

projetos (JUNIOR, 2008).
Segundo Martins (2007), o Scrum usa a técnica de antecipar o lucro do projeto de
forma controlada baseando-se no desenvolvimento iterativo, ou seja, os produtos podem ser
entregues aos clientes de forma incremental, antecipando o momento de entrega. Para que isto
aconteça o Scrum produz uma versão do produto e distribui ao mercado em intervalos
regulares de 30 dias, desta maneira o projeto agrega valor e lucro muito mais cedo.
Na Ilustração 8 é representado o ciclo de vida do Scrum, no qual o mesmo é baseado
em três fases: pré-game, game e pós-game.
Ilustração 8 - Ciclo de vida de desenvolvimento do Scrum.

Fonte: (adaptado de [AMBLER, 2010]).
3.1.1. Pré-game
Esta fase é composta por duas partes que são o planejamento e a arquitetura do
projeto. No planejamento é definido o release com base nas informações que constituem o
Product Backlog. Durante a elaboração da arquitetura é definida a base para a construção do
produto. Ainda nessa fase é importante que se tenha um Plano de Projeto e Estimativas do
projeto. Ter um plano de projeto é importante no Scrum devido ao fato dos projetos serem
complexos impossibilitando o detalhamento logo no início. Desta maneira, tais planos

começam como esboços e depois são ajustados e adaptados durante o projeto, sendo assim, o
planejamento mínimo necessário para começar um projeto Scrum consiste de uma Visão e do
Product Backlog. O Plano de Projeto deve ter detalhes suficientes, para convencer ao
patrocinador do projeto que certas coisas serão entregues em certos períodos de tempo, e que
os benefícios superam os riscos e custos e também que os membros da equipe do projeto
possuem competência para executar o plano.
As estimativas têm a finalidade de esboçar uma idéia do tamanho de cada requisito,
tanto do tamanho dele próprio como do tamanho relativo quando comparado com os demais
requisitos do projeto. É através das informações obtidas pelas estimativas que consegue-se
dar prioridades aos itens que compõe o Product Backlog, e assim, definir os itens que serão
desenvolvidos no Sprint.
Para que se faça uma estimativa justa, todos os membros da equipe deverão estimar os
itens do Product Backlog baseando-se nos mesmos critérios. Dessa forma, para estimar um
código fonte, por exemplo, o mesmo deve estar limpo, ou seja, não conter bugs, não ter
duplicação de código e ser fácil de ler e compreender. Para tanto, a estimativa deve ser
realizada considerando a análise, o projeto técnico, a codificação e os testes de requisitos.
3.1.1.1. Planejamento
O planejamento pode ser realizado em duas situações diferentes são elas: no

desenvolvimento de um novo produto ou na evolução de um produto existente. No
desenvolvimento de um novo produto deve-se conceitualizar e analisar o problema, e na
evolução do produto existente deve-se conter de uma análise limitada do problema
(MARTINS, 2007).
No planejamento, a equipe do projeto e o Scrum Master possuem uma visão como um
todo do projeto, sendo que essa visão vai amadurecendo a cada Sprint, quando o
conhecimento e experiência com o produto se torna maior. O Dono do Produto disponibiliza
uma lista com os requisitos e funcionalidades do sistema, chamado Product Backlog, com
base nos itens que compõe o Product Backlog, a equipe de projeto seleciona os que possuem
maior priorização, definido pelo Dono do Produto, e aloca-os para serem desenvolvidos no
Sprint (SCRUMALLIANCE, 2010).
Segundo Martins (2007), o release de um software é planejado com base nas seguintes
variáveis:
 Requisitos do cliente: esta variável refere-se às funcionalidades que precisam
ser adicionadas ao produto. Tais funcionalidades são identificadas pelo Dono
do Produto e tabuladas no Product Backlog;
 Prazo: esta variável define o prazo disponível para construir o produto;
 Concorrência: considera-se no produto que será construído as características
dos produtos concorrentes;
 Qualidade: esta variável permite que a qualidade seja atendida com base nas
variáveis acima;
 Visão: esta variável equivale a ter uma visão ampla do produto que muitas
vezes pode abranger mudanças ou novas funcionalidades que precisam ser
consideradas para que o produto seja construído;
 Recursos: esta variável refere-se a disponibilidade de recursos humanos, assim
como, a infra-estrutura,por exemplo o hardware, disponíveis para o projeto.
É importante ter essas variáveis identificadas no momento da Reunião de

Planejamento, pois tais variáveis estão sujeitas a mudanças a qualquer momento do projeto.
De tal modo, as mesmas precisam ser analisadas para que sejam consideradas no
planejamento dos vários Sprints que o projeto pode conter.
Segundo Soares (2010), na fase do planejamento os requisitos são descritos em um
documento chamado Product Backlog, que posteriormente deve ser priorizados e deve ser
realizada também as estimativas de esforço para cada um dos requisitos. Entre outras
atividades do planejamento também estão a definição da equipe do projeto, das ferramentas a
serem usadas, deve-se planejar também dos possíveis riscos do projeto e também a
identificação das necessidades de treinamento. Essas são atividades essenciais do Scrum, e
devem ser cumpridas para que esta fase tenha sucesso. É importante saber que eventuais
alterações nos requisitos descritos no Product Backlog são identificados, assim como seus
possíveis riscos, e os mesmos devem estar inseridos no Product Backlog. Depois que estas
atividades forem cumpridas, então é proposta uma arquitetura de desenvolvimento.
O processo de planejamento estabelece as expectativas dos envolvidos no projeto, que
podem ser as pessoas que proveram fundos para o projeto, que se beneficiarão dos resultados,
que utilizarão o produto que será desenvolvido, e outros que serão afetados pelo projeto.
Desta maneira é possível sincronizar as expectativas dos envolvidos no projeto com as da

equipe do projeto.
O planejamento também permite acompanhar o progresso do projeto, pois no final de
cada Sprint é realizado uma reunião de revisão, na qual a presença dos envolvidos do projeto
juntamente com a equipe de projeto, o Scrum Master e a presença do Dono do Produto são
fundamentais para o alinhamento e comparação do progresso atual contra o planejado. As
mudanças no planejamento sempre são discutidas nestas reuniões de revisões.
3.1.1.2. Arquitetura
Segundo Martins (2007), a arquitetura é projetada com base nos itens do Product
Backlog, visando à implementação. Esta é uma fase em que deve-se incluir definições
sabendo que as mesmas poderão ser modificadas no decorrer do projeto.
Esta fase deve conter algumas etapas, tais como, realizar uma analise do domínio, ou
seja, identificar se o desenvolvimento equivale a um software novo que será construído, ou se
equivale à evolução de um software, contendo melhorias, desta maneira é possível verificar o
contexto do sistema e dos requisitos. Outras etapas a serem consideradas são: o refinamento
da arquitetura provendo suportar o contexto e os requisitos, a revisão dos itens do Product
Backlog, identificando se as mudanças necessárias que constam nele irão trazer algum tipo de
problema no momento da implementação das mesmas, a realização de reuniões de revisão de
design para discussão da abordagem e das mudanças necessárias para implementar cada item
do Product Backlog.
3.1.2. Game
Esta é a fase de desenvolvimento do projeto, tal fase é composta por um ou mais

Sprints cujo objetivo é desenvolver as funcionalidades de um novo release, respeitando suas
regras como as restrições de prazos, requisitos, qualidade e características dos concorrentes
(MARTINS, 2007).
Segundo DevMedia (2010), as mudanças tanto na parte técnica quanto na parte do

ambiente são identificadas e controladas durante o desenvolvimento. Tais mudanças não são
consideradas apenas no início do projeto, como ocorre nas metodologias tradicionais, muito
pelo contrário, no Scrum essas mudanças são acompanhadas e tratadas continuamente no
decorrer do desenvolvimento dos Sprints, sendo que ações corretivas podem ser aplicadas.
Desta maneira a metodologia Scrum provê flexibilidade para visionar possíveis mudanças no
projeto.
Nesta fase o software é desenvolvido em Sprints em que novas funcionalidades são
adicionadas, seguindo as etapas de análise, projeto, implementação e testes. Os Sprints são
planejados para durar de uma semana a um mês. De acordo com Silva et al. (2006) cada
membro da equipe recebe uma parte dos itens que compõe o Sprint Backlog e são
responsáveis por desenvolveram como suas tarefas, apresentando sempre no final do Sprint
um produto executável.
Ainda nesta fase é realizada uma atividade essencial que permite medir o andamento
do Sprint, a Reunião Diária . A reunião diária tem duração de quinze minutos e é conduzida
pelo Scrum Master com o objetivo de obter medição contínua do progresso do Sprint, resolver
os problemas com maior agilidade, uma vez que os mesmos são identificados nesta reunião e
também garantir que a equipe esta trabalhando com integração e sem qualquer tipo de
conflitos (SILVA et al., 2006).
3.1.3. Pós-Game
De acordo com DevMedia (2010) após a fase de desenvolvimento são realizadas

reuniões como Revisões de Sprint e a Reunião de Retrospectiva para analisar o progresso do
projeto e demonstrar o software para o cliente.
A finalidade da revisão do Sprint é apresentar ao cliente o produto que foi
desenvolvido no Sprint, desta maneira é possível obter um resultado concreto do cliente sobre
sua satisfação a fim de integrar e testar boa parte do software como também motivar a equipe
com os resultados obtidos (SILVA et al., 2006).
Na reunião de retrospectiva o grande propósito é discutir sobre o trabalho que foi
realizado no Sprint, assim como, as lições aprendidas com as experiências.
Nesta fase o produto é preparado para distribuição, e para que isto ocorra são incluídas
as integrações, testes adicionais, documentação do usuário, preparação do material para
treinamento e de marketing (MARTINS, 2007).
3.2. Artefatos
O Scrum utiliza artefatos que ajudam a monitorar o processo e o desenvolvimento do

projeto, assim como, apóiam o acompanhamento do progresso do mesmo. Esses artefatos por
serem tão simples auxiliam na comunicação face a face entre os envolvidos do projeto. (KEN;
COLIN, 2009).
3.2.1. Product Backlog
De acordo com Ken e Colin (2009), o Product Backlog é o artefato mais fundamental
no Scrum, pois é ele que indica o que a equipe irá desenvolver. Trata-se de uma lista
priorizada de requisitos funcionais e não- funcionais juntamente com uma estimativa de alto
nível que é elaborada de acordo com os esforços de cada requisito. Segundo Scribd (2009) o
responsável pelo conteúdo, disponibilidade e priorização deste artefato é o Product Owner.
O Product Backlog nunca está completo, ele evolui à medida que o produto e o
ambiente em que ele será usado evoluem. Inicialmente ele é composto apenas pelos requisitos
conhecidos e melhor entendidos. Este é um artefato que sofre mudanças constantemente,
devido a novas necessidades que o produto encontra, por isso ele é considerado dinâmico. Um
detalhe importante do Product Backlog é que ele tem vida útil enquanto houver um produto
que o alimente, ou seja, enquanto houver requisitos, funcionalidades ele tem utilização, no
momento em que, o Product Backlog vai ficando vazio devido ao projeto utilizar os itens que
os pertencem, para construir o projeto, ele começa a perder a utilidade. O correto é que ao
final do projeto todos os itens que compõem este artefato sejam consumidos deixando-o
vazio.
Segundo Scribd (2009), o Product Backlog contém todas as informações que são
necessárias para desenvolver o produto com sucesso, pois ele é uma lista de todas as
características, funções, tecnologias, melhorias e correções de defeitos que constituem as

mudanças que serão realizadas no produto em releases futuros.
Os itens que compõem o Product Backlog são caracterizados por prioridades,
descrições e estimativas. A prioridade deverá ser atribuída aos itens que apresentarem maior
risco e necessidade e também para aqueles que representam maior valor para o negócio ou
que oferecem um maior retorno sobre o investimento (ROI). Tal lista pode ser evoluída
conforme há alterações nos negócios ou mudanças de tecnologias, desta maneira deve-se
priorizar novamente os itens da lista.
A ordenação dos itens que compõem o Product Backlog é feita de acordo com a
prioridade de cada um, sendo que os itens que possui maior prioridade são desenvolvidos
mais rápido, pois possui informações mais detalhadas do que os itens de menor prioridade o
que os torna mais claros (KEN e COLIN, 2009).
Os requisitos do Product Backlog são decompostos nos Sprints, ou seja, em cada
Sprint são selecionados e desenvolvidos apenas partes dos requisitos do Product Backlog.
Para realizar a seleção dos requisitos que farão parte do Sprint além das prioridades que os
mesmos possuem também devem ser analisadas suas características, tecnologias e arquitetura
(SCRIBD, 2009).
3.2.2. Planning Poker
Segundo Agilez (2010), um dos maiores desafios para quem trabalha com
desenvolvimento de software é conseguir mensurar com precisão o tamanho de cada tarefa, e
ainda, conseguir prever o prazo em que esta tarefa deverá ser concluída.
O Planning Poker é uma das técnicas de estimativas mais utilizadas pelas
metodologias ágeis. Para tal técnica ter sucesso é primordial o consenso de todos da equipe
sobre a estimativa, desta maneira utiliza-se de um conjunto de cartas com valores específicos
que podem representar pontos relativos ou até mesmo horas, os valores das cartas seguem a
seqüência de Fibonacci1.
1
Um número da Seqüência de Fibonacci é gerado pela soma dos dois números anteriores. A seqüência se inicia
com os números 0,1, então somando os dois primeiros, o número seguinte será 1, sendo assim, a seqüência agora
é 0, 1, 1. Repetindo isto, temos o número 2, gerando a seqüência 0, 1, 1, 2 e assim sucessivamente. (ESPINHA,
2010).
A estimativa acontece após a apresentação da estória ou da tarefa para o time, onde

todos discutem brevemente sobre suas características e escolhem uma carta. O valor da carta
deve ser reservado até que todos escolham suas cartas, depois disso, as cartas são exibidas a
todos para que haja um consenso entre os valores escolhidos, as diferenças são discutidas
rapidamente, e uma nova escolha acontece ate que haja a convergência.
As vantagens de utilizar a técnica do Planning Poker para estimativa é que a equipe
torna-se mais comprometida devido a participação de todos. A utilização dessa técnica força a
equipe a ter um conhecimento maior sobre o negócio tornando o entendimento mais
homogêneo e considerando a experiência de todos para o estabelecimento das estimativas.
Além dessas características o Plannig Poker tem se mostrado como uma prática que atrai a
participação de todos, pois muitas vezes torna-se divertida.
3.2.3. Sprint Backlog
O Sprint Backlog corresponde a uma lista de tarefas que a equipe do projeto define e
se compromete a implementar no Sprint. Esta lista de tarefas é derivada do Product Backlog,
onde estão todos os requisitos priorizados do sistema. A cada novo Sprint é realizado uma
seleção dos itens do Product Backlog de acordo com o planejamento que a equipe aderiu para
o Sprint (MARÇAL, 2009).
Segundo Improveit (2007), a equipe de projeto se compromete a desenvolver
funcionalidades selecionadas para o Sprint de acordo com as prioridades dos itens do Product
Backlog que o Dono do Produto estipulou e também com a experiência de percepção, que a
equipe possui, analisando cada item e estimando o tempo necessário para desenvolver todas
as tarefas do Sprint, sendo assim, a equipe determina a quantidade de itens que serão migradas
do Product Backlog para o Sprint Backlog.
Durante o Sprint, o Scrum Master analisa os itens do Sprint Backlog atualiza-o quando
necessário, afim de identificar a quantidade de tarefas que foram finalizadas e quanto tempo a
equipe acredita que será necessário para finalizar aquelas que ainda não estão prontas. Desta
maneira, o Scrum Master consegue estimar o trabalho restante do Sprint diariamente, podendo
então, armazenar e esboçar as informações para todos os interessados em um gráfico
denominado Sprint Burndown Chart.
3.2.4. Sprint Burndown Chart
O Sprint Burndown Chart é um artefato do Scrum que representa graficamente o

trabalho restante para finalizar o Sprint. As informações inseridas no gráfico são coletadas
diariamente, durante as Reuniões Diárias, pelo Scrum Master e desta maneira o mesmo
consegue realizar a estimativa e representá-la graficamente.
A Ilustração 9 esboça o Sprint Burndown Chart.
Ilustração 9 - Sprint Burndown Chart.

Fonte: Eclipse (2010).
De acordo com o gráfico no eixo vertical são representadas as horas de esforço

restante no Sprint e no eixo horizontal são representados os dias do Sprint. O Sprint
Burndown Chart deve ser representado uma linha que saí do início do Sprint com as horas
iniciais, descendo até o final do Sprint, sem deixar horas sobrando.
Na Reunião Sprint Planning a equipe do projeto deve alocar a quantidade certa de
trabalho para o Sprint, mas nem sempre isso acontece, às vezes alocam-se tarefas a mais ou a
menos e, neste caso, o time precisa adicionar ou remover tarefas. Quando isso ocorre, o Sprint
Burndown Chart pode conter variações entre horas e os dias do Sprint, ou seja, se houver
muita tarefa a ser cumprida para pouco tempo deve-se consultar o Dono do Produto para que
ele possa tomar uma decisão, ou se ocorrer o contrário, se houver tempo sobrando para poucas
tarefas a serem finalizadas, deve-se consultar o Dono do produto novamente para verificar se
novas tarefas serão incrementadas no Sprint (ECLIPSE, 2010).
O Sprint Burndown Chart é um recurso de medição muito valioso para a metodologia
Scrum, pois é através do mesmo que consegue-se medir o andamento do processo de
desenvolvimento do projeto, tais informações tornam deste artefato um diferencial para a
metodologia Scrum (CISNEIROS et al., 2009).
3.2.5. Sprint Task Board View
Este artefato como o próprio nome diz é um quadro de tarefas, que é utilizado pela
equipe do projeto e pelo Scrum Master nas Reuniões Diárias. Este quadro exibe todo o
trabalho que a equipe está desenvolvendo durante o Sprint.
A Ilustração 10 esboça o Sprint Task Board View.
Ilustração 10 - Task Board View.

As tarefas que compõe o quadro são os itens selecionados do Product Backlog para
serem desenvolvidos no Sprint. Cada linha no Quadro de Tarefas equivale a um item do
Product Backlog, tais itens são representados como estórias. As colunas representadas no
quadro são os status em que as tarefas se encontram pode ser: TO DO (PENDENTE), IN
PROCESS (ALOCADO) e DONE (PRONTO).
As tarefas que estiverem com o cartão em TO DO são as tarefas que terão que ser
realizadas no decorrer do Sprint, já as tarefas cujos cartões estiverm em IN PROCESS são
tarefas que estão sendo realizadas neste momento do Sprint e por fim as tarefas cujos os
cartões estiverem em DONE são tarefas do Sprint que já foram finalizadas. Os cartões com as
tarefas poderão ser movidos nas Reuniões Diárias do Sprint, onde toda a equipe e o Scrum
Master devem estar presentes (ECLIPSE, 2010).
3.3. Papéis
A metodologia Scrum é baseada em papéis e responsabilidades, porém , os papéis do

Scrum são abrangentes e direcionados para o sucesso do projeto.
De acordo com Martins (2007) o Scrum trabalha com três papéis basicamente: o Dono
do Produto, o Scrum Master e a Equipe do Projeto.
3.3.1. Dono do Produto/ Product Owner
O Dono do Produto representa os interesses do projeto, ou seja, representa os

interesses das pessoas que apostaram no projeto e no produto resultante. O Dono do Produto é
responsável também por conseguir a verba, definir os requisitos iniciais e gerais do projeto,
sejam eles funcionais ou não-funcionais, assim como, definir os objetivos de ROI e o plano de
releases (MARTINS, 2007).
De acordo com (Cisneiros et al., 2009), o Dono do Produto tem que ser a interface
entre o cliente e o time de desenvolvedores, o contato entre ambos é de extrema importância,
pois só assim ele saberá o que realmente o projeto tem que ser.
Um dos trabalhos mais difíceis do Dono do Produto é definir o Backlog do
Produto,que é um artefato do Scrum. Tal artefato representa a lista de requisitos do projeto.
Seguem algumas das responsabilidades do Dono do Produto:
 Definir as características e conteúdo do produto;

 Decidir sobre a data de término;
 Ser responsável pela rentabilidade do produto;
 Priorizar as funções de acordo com o valor de mercado e como cliente;
 Ajustar recursos e priorizar tarefas a cada 30 dias;
 Aceitar ou rejeitar o resultado do trabalho.
O dono do produto muitas vezes será um gerente de projeto, um patrocinador do

projeto, um membro da equipe de marketing ou um cliente interno.
3.3.2. Mestre Scrum / Scrum Master
O Scrum Master apesar de ocupar uma posição similar a de um gerente de projeto, não
é um gerente, mas sim um líder responsável por forçar as práticas e valores do Scrum, assim
como, remover os obstáculos, ensinar o processo a todas as pessoas, implementar o Scrum e
garantir que todas as pessoas sigam suas regras e práticas (MARTINS, 2007).
De acordo com (Cisneiros et al., 2009) o Mestre Scrum como líder da equipe de
desenvolvimento, tem um contato maior com o Dono do Produto, dessa maneira ele deve
gerenciar e repassar o trabalho que foi decidido durante o planejamento pelo Proprietário do
Produto.
Seguem algumas das responsabilidades do Scrum Master (MARTINS, 2007 e
(Cisneiros et. al., 2009):
 Remover as barreiras entre a equipe de desenvolvimento e o Dono do Produto,

de modo que o Dono do Produto possa orientar o desenvolvimento;
 Auxiliar ao Dono do Produto como maximizar o ROI e atingir os seus
objetivos através do Scrum;
 Manter a informação sobre o progresso da Equipe sempre atualizada e
disponível para todos os interessados;
 Assegurara que a equipe de desenvolvimento funcione plenamente e seja

produtiva;
 Assegurar-se de que a metodologia está sendo seguida, incluindo chamadas
para reuniões diárias (Daily Scrum Meetings), revisões de atividade (Sprint
Reviews) e reuniões de planejamento (Sprint Planning);
 Ajudar na cooperação entre todas as funções e papéis do time.
De acordo com Devin (2010), devido ao fato do Scrum Master possuir todas essas
responsabilidades citadas acima, pode-se chamá-lo também de coordenador de projeto, ou
seja, ele deve também coordenar o projeto fazendo com que a comunicação entre as pessoas
sejam constante a fim de facilitar o andamento do projeto.
O Scrum Master além de comandar as reuniões diárias ele também possui mais três
responsabilidades, que podem ser designadas como principais. São elas:
 Acompanhar o andamento do projeto, identificando quais atividades foram
concluídas, quais foram iniciadas, quais são novas, ou seja, que tiveram
mudanças no decorrer do projeto. De acordo com este acompanhamento o
Scrum Master pode alterar suas estimativas para o projeto, e também atualizar
o Burndown Chart, que permite mostrar quanto falta para um Sprint acabar, dia
por dia. Desta maneira o Scrum Master deve estar sempre atento ao numero de
tarefas em aberto e tentar minimizar o máximo possível essas tarefas para que
o trabalho seja ágil e eficiente;
 Avaliar as dependências, bloqueios, impedimentos que causam prejuízo ao
andamento do projeto. Para isto, deve-se fazer um plano de solução e
priorizando os itens mais críticos;
 Perceber e resolver problemas pessoais ou conflitos entre os integrantes do
time de desenvolvimento Scrum. Tais problemas devem ser resolvidos através
de diálogos com o time, e caso não tenha um bom resultado com o diálogo,
então o Scrum Master deve envolver a gerência ou até mesmo o departamento
de Recursos Humanos. O Scrum Master deve estar sempre atento ao time para
fazer dele totalmente funcional e produtivo.
3.3.3. Equipe de Projeto / Team Members
A equipe de projeto é o grupo de pessoas responsáveis por construir as

funcionalidades do produto e pode ser composto por desenvolvedores em tempo integral e
participantes externos (marketing, vendas, clientes (MARTINS, 2007).
Segundo Yoshima (2007), as equipes são auto-gerenciadas, auto-organizadas e multi-
funcionais,ou seja, cada membro da equipe deve ter o conhecimento técnico sobre todo o
processo de desenvolvimento do produto. De tal maneira, em projetos de desenvolvimento de
software, a equipe de projeto deve ser composta de pessoas capazes de analisar a solução,
codificá-la e testá-la sem necessitar de outros times ou outras pessoas.
Geralmente a equipe é composta por 5 a 10 membros, porém o recomendado é 7
pessoas (MARTINS, 2007). Esta equipe é responsável pelo desenvolvimento das
funcionalidades do produto (Backlog do produto), que foram identificados pelo Dono do
Produto, desta maneira a equipe define as metas do Sprint, junto ao Scrum Master, organizam
os trabalhos para atingir os objetivos dos Sprints, assim como, especificam os resultados de
trabalho.
É importante ressaltar que a responsabilidade pela qualidade do produto é do time, ele
deve verificar se suas práticas de desenvolvimento são compatíveis com as necessidades de
qualidade e disponibilização da aplicação. No momento em que o time encontra necessidades
de refatorar seu código ou construir novos testes ele deve notificar tais necessidades ao
Product Owner (VARASCHIM, 2009).
3.4. Reuniões Scrum (Cerimonies)
O Scrum possui diversas reuniões, cada qual é realizada em fases específicas do

projeto, o que facilita muito o gerenciamento e o controle do mesmo. A seguir serão
apresentadas as reuniões e as fases na qual as mesmas acontecem.
3.4.1. Reuniões Gerais (General Meeting)
Segundo Félix (2010), todas as reuniões do Scrum seguem um padrão comum. Este
padrão é constituído por regras básicas que são essenciais para ter-se uma reunião eficiente e
satisfatória para todos os participantes.
No Scrum as reuniões são planejadas seguindo critérios e pré-condiçòes fundamentais
para alcançar o seu objetivo, abaixo são listados alguns exemplos:
 Deve-se definir a agenda, pelo menos, um dia antes, para que seja possível
reservar espaço fisíco e infra-estrutura para que a reunião ocorra;
 Deve-se enviar para todos os participantes da reunião a agenda e quais são os
objetivos a serem abordados na mesma;
 Deve-se reservar todos os recursos necessário para a realizaçao da reunião, por
exemplo: sala, notebook com acesso à internet, projetor, enfim, deve-se
garantir que a sala de reunião está totalmente preparada antes do início da
reunião.
Durante a reunião, deve-se apresentar o objetivo planejado, respeitando o horário

agendado. Se o horário exceder e não for cumprido todo o objetivo, deve-se agendar um outro
encontro para que a reunião possa ser finalizada. É importante que todos os participantes da
reunião concordem com os resultatos obtidos pela mesma, e assumam o compromisso com
tais objetivos.
3.4.2. Reunião de Estimativa (Estimation Meeting)
A reunião de Estimativa acontece antes do planejamento do Sprint, pois é nesta

reunião que serão priorizados os itens do Product Backlog.
Os participantes desta reunião são: o Dono do Produto, o Scrum Master e a Equipe de
Projeto.
O Dono do Produto apresenta os itens do Product Backlog que ele deseja que seja
estimado, para a equipe do projeto, pois é função da mesma estimar tais itens. Desta maneira,
o Dono do Produto explica os detalhes de cada item para que a equipe possa realizar o método
de estimativa, o Scrum utiliza o Planning Poker para realizar as estimativas, afim de que
todos da equipe chegam a um consenso único. Enquanto a equipe toda não estiver de acordo
com o resultado estimado para o item, a estimativa não é finalizada, se houver necessidade o
item é explido e discutido novamente entre todos da equipe. Tais estimativas são a base para o
planejameto dos Sprints.
Nesta reunião, o Scrum Master deve apenas assegurar que a mesma está sendo
realizada seguindo as regras do Scrum, ele em momento algum pode influênciar a equipe na
estimativa dos itens (FÉLIX, 2010).
3.4.3. Reuniões de Planejamento do Sprint ( Sprint Planning)
No fluxo do Scrum existem duas atividades a serem realizadas antes de começar um

Sprint, são elas: o Sprint Planning 1 e o Sprint Planning 2. Esta é uma das etapas mais
importantes relacionadas às atividades do Scrum, pois nestas reuniões são identificadas e
discutidas as expectativas do ciclo de desenvolvimento, juntamente com os envolvidos do
projeto. Os participantes da reunião de planejamento do Sprint são: o líder do projeto (Scrum
Master), a equipe de projeto (Scrum Team), o dono do produto (Product Owner), porém além
destes participantes podem ser convidados outros profissionais que estejam relacionados e
apresentam interesses nos resultados do projeto (VAILATI, 2010).
O Sprint Planning 1 é a primeira reunião de planejamento do Sprint, por tanto é
fundamental a presença do Dono do Produto, pois é ele o responsável pelos requisitos do
Product Backlog, tendo conhecimento amplo das regras de negócios, das funcionalidades, e
também por saber quais itens tem maior prioridade para serem alocados e desenvolvidos no
Sprint.
De acordo com Vailati (2010), o foco desta reunião é que além do Dono do Produto
apresentar as funcionalidades que serão desenvolvidas deverão ser esclarecidas as dúvidas
levantadas pela equipe, de maneira que a equipe consiga absorver todo conhecimento possível
sobre as prioridades apontadas pelo Dono do Produto.
Nesta reunião a equipe de projeto deverá escolher quais itens do Product Backog
deverão ser desenvolvidos no Sprint. Tais itens também são conhecidos como estórias, sobre
as quais todos da equipe deverão chegar a um acordo de que terão condições de
desenvolverem as estórias escolhidas. Após as escolhas das estórias que serão implementadas
no Sprint pode-se realizar o Sprint Planning 2.
No Sprint Planning 2 toda a equipe concentra seus esforços em quebrar as estórias do
Product Backlog em unidades menores de trabalho, que são conhecidas como Tasks. Cada
Task pode ser representada por post-its e inseridas na Sprint Task Board View, podendo
mudar de status no decorrer do Sprint (to do, in progress, done). A importância dos membros
da equipe quebrar essas estórias em tarefas é a facilidade de desenvolvimento do Sprint. É
recomendado que as tarefas sejam detalhadas e quebradas o máximo possível para serem
realizadas em um dia de trabalho ou menos, pois com isso além de identificar possíveis riscos
também facilitará o gerenciamento e visualização no momento da Reunião Diária (BURGOS,
2010).
Após esta reunião é elaborado o artefato Sprint Backlog que contem a especificação de
todas as atividades técnicas do Sprint são especificadas, assim como, os devidos esforços que
deverão ser tomados para que seja alcançado o objetivo do Sprint que iniciará.
Além da lista de atividades, que é elaborada na reunião de planejamento de Sprint, a
equipe de projeto junto com o Dono do Produto devem descrever o objetivo da iteração, de tal
maneira que esse objetivo servirá como critério de avaliação dos resultados do Sprint. Os itens
do Product Backlog que não foram inseridos no Sprint Backlog ficarão pendentes para serem
analisados na próxima reunião de planejamento de Sprint ( VAILATI, 2010).
3.4.4. Reuniões Diárias Scrum (Daily Meeting)
No Scrum o Scrum Master e a Equipe do Projeto fazem uma reunião diária que limita-
se ao tempo de 15 minutos que, caso seja necessário pode chegar a durar até 30 minutos. Esta
reunião é curta, pois seu propósito é ser mais objetiva (MARTINS, 2007). Essas reuniões
geralmente são realizadas no mesmo horário e mesmo local todos os dias e, como esta é uma
reunião que apóia a determinação das atividades daquele dia, é recomendado que ela seja
realizada no período da manhã (ECLIPSE, 2010).
Na reunião diária Scrum não é o momento de solucionar problemas ou dúvidas, mas

sim o momento de notificá-las, pois as mesmas deverão ser tratadas imediatamente após a
reunião. O objetivo da reunião é conhecer o status do projeto até o momento. Desta maneira, o
Scrum Master faz três perguntas para cada membro da equipe de projeto:
1. O que você fez ontem?

2. O que você vai fazer hoje?
3. Existe algum impedimento?
No momento em que o Scrum Master descobre o que cada membro concluiu ontem e
irá realizar hoje, já é possível ter uma visão de como está o andamento do trabalho, ou seja, se
está sendo cumprindo o prazo estimado, do mesmo modo em que a equipe de trabalho
também consegue identificar quais trabalhos ainda faltam concluir.
A reunião diária Scrum é realizada também para verificar o comprometimento entre os
membros da equipe, por exemplo, se um programador diz “Hoje eu vou terminar o módulo de
armazenamento de dados” todos sabem que na reunião de amanhã ele dirá se terminou ou
não. Desta maneira, é possível que cada membro da equipe compreenda que cada um tem
compromisso uns com os outros, não com um cliente distante ou com um vendedor.
É papel do Scrum Master remover os impedimentos que surgirem durante a reunião.
Impedimentos esses, que a equipe de projeto identifica, porém se ocorrer de ser um
impedimento em que o Scrum Master não consiga remover diretamente, ele deve assegurar
que alguém do time solucione o mais breve possível (ECLIPSE, 2010).
3.4.5. Reunião de Revisão do Sprint (Sprint Review)
De acordo com Martins (2007), a Reunião de Revisão do Sprint ocorre no final de

cada Sprint. Esta reunião provê que a equipe de projeto apresente ao Dono do Produto, e
outros stakeholders interessados, o trabalho que foi desenvolvido durante o Sprint. Esta é uma
reunião informal que ajuda a equipe de forma colaborativa a obter o feedback e determinar
quais são os objetivos da próxima iteração. Através da Reunião de Revisão do Sprint é
possível verificar periodicamente se o projeto está produzindo valor para o negócio e também
analisar se a qualidade e as funcionalidades estão sendo produzidas.
Após a execução do Sprint, a equipe apresenta o incremento que foi implementado
para os gestores, clientes, usuários e o dono do produto, de modo que eles possam avaliar a
iteração. Eles escutam da equipe do projeto qual foi a trajetória até chegar no final do Sprint,
quais foram os erros e acertos. De acordo com os fatos divulgados pela a equipe o dono do
produto pode tomar uma decisão informal do que fazer em seguida, ou seja, se a equipe pode
avançar para o próximo Sprint (KEN e COLIN, 2009).
Nesta reunião também deve ser apresentado o relatório de mudanças, no qual são
descritos o que aconteceu durante o Sprint, o que foi discutido e decidido nas últimas reuniões
de revisão, e as adaptações que foram feitas. Deve ser apresentado também a versão anterior e
a atual do Product Backlog do projeto entre os Sprints, assim com o relatório de mudanças em
que deve ser documentado a diferença entre os dois Product Backlog e suas causas. O
documento de mudança além de documentar todas as mudanças que ocorreram no projeto,
também documenta as inspeções e adaptações que o projeto sofreu em um período de tempo
(MARTINS, 2007).
Seguem as regras da Reunião de Revisão de Sprint de acordo com Ken e Colin
(2009):
 Procurar não ultrapassar uma hora na reunião de revisão do Sprint;
 As funcionalidades que não foram implementadas não podem ser apresentadas;
 Os artefatos que não são funcionalidades também não podem ser apresentados
exceto quando são usados para compreender o produto;
 A funcionalidade deve ser apresentada num ambiente mais próximo possível
ao real, por exemplo, no ambiente de produção ou homologação;
 A revisão do Sprint começa com um membro a equipe apresentando os
objetivos do Sprint, mostrando as funcionalidades selecionadas do Product
Backlog que foram implementadas e as que não foram implementadas. Os
membros fora da equipe discutem os pontos positivos e negativos do Sprint;
 A maior parte do tempo com a revisão do Sprint é gasto com os membros da
equipe apresentando as funcionalidades, respondendo perguntas a respeito das
funcionalidades da apresentação e anotando possíveis mudanças;
 Ao final da apresentação as partes interessadas do produto avaliam as
mudanças desejadas e indicam as prioridades destas mudanças;
 As partes interessadas do produto comentam, fazem observações e/ou criticam

as funcionalidades implementadas do produto da apresentação;
 O Dono do Produto pode identificar as funcionalidades que não foram
entregues de acordo com o esperado e pedir que seja colocado novamente ao
Product Backlog;
 As partes interessadas do produto podem identificar as funcionalidades novas
enquanto vêem a apresentação e pedir que a funcionalidade seja adicionada ao
Product Backlog;
 O Scrum Master deve avaliar quantas pessoas terão que participar da reunião e
fazer os arranjos necessários para que a reunião possa acontecer de forma
confortável;
 Ao final da reunião, o Srum Master agenda a próxima reunião junto ao Dono
do Produto e as partes interssadas.
Após a reunião de revisão do Sprint, algumas conseqüência podem ser levantadas:
 Restaurar as funcionalidades que não foram implementadas do Product

Backlog e priorizá-las;
 Remover as funcionalidades do Product Backlog que já foram implementadas;
 Trabalhar com o Scrum Master para reformular a equipe se necessário.
3.4.6. Reunião de Retrospectiva (Retrospective)
A reunião de retrospectiva ocorre logo após a reunião de revisão do Sprint. Esta é uma
reunião dirigida pelo Srum Máster que encoraja a equipe do projeto a revisar o seu processo
de trabalho, tendo em vista o framework e as práticas do Scrum, para se obter um melhor
desempenho na próxima iteração (MARTINS, 2007).
De acordo com Ken e Colin (2009), esta é uma reunião que permite a equipe do
projeto a discutir o Sprint que foi concluído de maneira a expressar o que poderia ser mudado,
em relação a comunicação, o ambiente de trabalho, os artefatos e as ferramentas que são
utilizadas durante cada Sprint, para fim de que o Scrum Master juntamente com a equipe
busquem a melhor alternativa para tornar o próximo Sprint mais agradável e produtivo.
Segundo Ken Schwaber apud Martins (2007) esta reunião apresenta as seguintes
características:
 A equipe inteira, o Scrum Master e o Dono do Produto devem participar da
reunião;
 A reunião começa com cada membro respondendo duas perguntas, que são: “O
que deu certo durante o Sprint?” e “O que pode ser melhorado para o próximo
Sprint?”;
 O Scrum Master toma nota das respostas dos membros da equipe;
 A Equipe prioriza em que ordem ela quer discutir as melhorias potenciais;
 O Scrum Master não está na reunião para prover as respostas, mas ajudar a
equipe descobrir novas formas de trabalhar dentro do processo Scrum.
Nesta seção foram apresentados alguns conceitos da metodologia ágil Scrum, assim como,
seu ciclo de vida e suas três fases: pré-game, game e pós-game. Cada fase foi desdobrada
apresentando suas respectivas atividades, artefatos e papéis.
Foi possível verificar que o Scrum está apto a receber mudanças e inovações contínuas em
seus projetos, pois o mesmo aborda métodos iterativos e incrementais. Ainda neste contexto,
pode-se notar que Scrum possui boas práticas para gerenciar e atender mudanças advindas do
mercado.
Na próxima seção serão abordados conceitos de gerenciamento de projetos de software e
por fim o Scrum será associado a este contexto.
4. GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE
COM A METODOLOGIA SCRUM
No cenário atual de Tecnologia de Informação em que o mercado se encontra, um dos

fatores que chama mais a atenção em comparação ao desenvolvimento de software com
relação às últimas décadas é a concorrência e agilidade em desenvolver softwares inovadores
e complexos. Logo, é fundamental que exista um bom gerenciamento caminhando em
paralelo com o desenvolvimento de software para obter-se resultados de sucesso. Para tanto, a
atividade de gerenciamento de projetos, engloba diversos fatores chaves, como por exemplo,
pessoas, prazo e custo.
Contudo, gerentes de projetos ágeis ajudam suas equipes se equilibrar no limite entre o
caos e a normalidade buscando realizar algumas atividades, como por exemplo,
documentação adequada e antecipação de arquitetura. Porém, o nível de detalhe destes
artefatos conseguido nesse momento é muito baixo, até porque, ter um conhecimento inicial,
que permita ter uma visão geral do software a ser desenvolvido é o ponto importante para
atingir o equilíbrio da arte em gerenciar o projeto.
O grande objetivo do gerenciamento ágil de projetos é encorajar as mudanças,
tornando-as desafios futuros, no qual há uma grande interação entre pessoas que possibilita
descobrir novas informações que irão ajudar a tornar real a visão de produtos.
A metodologia Scrum oferece um framework com um conjunto de práticas simples e
objetivas, fácil de aprender que permite que a equipe de projeto e outros interessados, saibam
o que está acontecendo no projeto, mantenham o controle e monitoramento do mesmo. Isso
torna possível a tomada de decisão, quando necessária, direcionando o projeto para o rumo
que for pertinente (MARTINS, 2007).
4.1. Definição do Gerenciamento ágil do projeto
De acordo com Highsmith (2004) apud Martins (2007), o mercado concorrente exige
cada vez mais das empresas diferencial, porém que contenha inovações, agilidade e qualidade,
desta maneira, empresas e/ou indústrias de diversos ramos (farmacêutica, automotiva,
software, circuitos integrados, dentre outras) estão buscando atender as demandas constantes
dos clientes por inovação e redução de custos com experimentações. Tais empresas estão
passando por mudanças massivas do estilo de desenvolvimento antecipatório, como PMI
(Project Management Institute), para o adaptativo, como o APM (Agile Project
Management).
Por exemplo, no desenvolvimento de software, o grande motivo que levou as empresas
a mudarem do estilo de desenvolvimento antecipatório para adaptativo, foi justamente pelo
fato de o modelo adaptativo ter uma visão geral do projeto, e no decorrer dos ciclos
realizarem explorações detalhando mais os requisitos e artefatos. Desta maneira a facilidade
para adaptações no projeto, levando a resultados confiáveis torna-se maior, pois não é preciso
esperar que o projeto acabe para notificar que o mesmo não está exatamente como era o
esperado pelo cliente.
Para o modelo adaptativo a equipe toda tem que ter uma visão clara do produto e de
como ele afetará os negócios dos clientes, assim como tem que estar claro a data limite da
entrega de cada ciclo, com uma versão funcional do produto, além de saber quais recursos
farão parte do projeto. Com a visão geral do “todo” do produto e/ou do projeto, como a
metodologia ágil Scrum propõe, torna-se fácil adaptar e evoluir os ciclos conforme as
necessidades identificadas pelos clientes, dessa maneira o produto irá amadurecendo no
decorrer dos ciclos do projeto e o seu gerenciamento conseqüentemente será mais fácil devido
o seu controle por ciclos pequenos.
De acordo com Chin (2004) apud Araujo (2008), em 2001 quando o Manifesto Ágil
foi lançado, algumas empresas de software passaram a utilizar práticas de metodologias ágeis
nos métodos e técnicas de gerenciamento clássico de projetos, tentando suprir a complexidade
do gerenciamento de projetos. Porém, essas adaptações não obtiveram como resultado
eficácia, devido às restrições aos métodos e técnicas do gerenciamento clássico de projeto, os
resultados muitas vezes apresentavam desempenho ruim. Desta maneira, Chin propõe uma
nova abordagem para o gerenciamento ágil de projetos, no qual a visão do forte planejamento
prévio das atividades é quebrada denominada Gerenciamento Ágil de Projetos ou o Agile
Project Management (APM).
4.1.1. Objetivos, Valores, Princípios e Fases do Gerenciamento de Projetos Ágeis
Segundo Highsmith (2004) apud Martins (2007), geralmente as empresas tentam

planejar e depois executar as atividades de um projeto, porém em um ambiente volátil de
desenvolvimento de software essa não é a maneira mais propícia. A melhor alternativa é o
processo adaptativo e experimental, no qual é criada uma visão inicial, que será depois
explorada no decorrer do projeto. Tal processo é chamado de Agile Project Management
(APM) como mencionado na seção anterior. O APM tem cinco objetivos principais de
negócio, são eles: inovação contínua, adaptabilidade do produto, entregas com cronogramas
reduzido, adaptabilidade do processo e das pessoas e resultados confiáveis.
 Inovação contínua: Este é um processo básico para o APM, que busca
entregar valores para o cliente por saber que os mesmos sempre possuem idéias
inovadoras, ou seja, devido aos clientes ter novas necessidades constantemente.
Mas esta é uma característica que ocorre apenas em ambientes ágeis, pelo fato
de serem adaptativos e flexíveis diferente dos ambientes clássicos onde se tem
processos e estruturas bem definidos e planejados o que o torna burocráticos e
por conseqüência as adaptações são rejeitadas;
 Adaptabilidade do produto: Esta é uma prática muito importante para
responder às mudanças no negócio e no produto. Contudo esta prática possui
um diferencial muito relevante no mercado concorrente, onde as empresas se
destacam justamente por suprir as mudanças através da adaptabilidade do
produto. No APM busca-se produzir um produto que atenda o valor requerido
pelo cliente hoje, mas que seja fácil agregar adaptações futuras, isso ajuda a
reduzir o custo com mudanças e/ou adaptações no processo de
desenvolvimento;
 Entregas com cronogramas reduzido: Devido o fato da concorrência ser
muito grande, dos clientes cada vez mais querer resultados rápidos, as janelas
de oportunidades abrem e fecham também rapidamente, o APM propõe
entregas de versão do produto no menor prazo possível, de maneira que as
janelas se abram constantemente fazendo com que o ROI seja aumentando.
Para ter redução no cronograma de entrega o APM busca priorizar as
características e requisitos do produto o que ajuda a reduzir o retrabalho,
concentrar-se também nas atividades que agregam maior valor para o cliente,
eliminando a carga extra como de atividades burocráticas o que agiliza o
processo de desenvolvimento. Por fim o APM busca selecionar e desenvolver
os indivíduos com o melhor perfil para o projeto;
 Adaptabilidade do processo e das pessoas: Esta é a prática do APM
designada para atender rapidamente às mudanças no negócio e no produto,
desta maneira é importante que a equipe entenda que o produto pode ser
modificado no decorrer do seu desenvolvimento e adaptações devem ser feitas
sempre que necessário. As equipes também devem saber que poderão ser
alocadas em projetos diferentes a qualquer momento, basta surgir esta
necessidade, sendo assim, é importante que os valores da equipe estejam claros
para todos os membros que a compõe, onde o auto-aprendizado e as
adaptações são fatores integrais dos valores da equipe;
 Resultados confiáveis: Este é o ultimo objetivo do APM e também muito
importante, pois é através dos resultados confiáveis que se alcança o
crescimento do negócio. Devido aos projetos ágeis serem exploratórios, e
possuírem diversas incertezas que cercam os requisitos e as novas tecnologias,
esses projetos não conseguem entregar um resultado conhecido e pré-
especificado. Porém com o bom gerenciamento é possível entregar resultados
de valor para o cliente que atendam as necessidades atuais para o negócio. Isso
ocorre devido o fato dos processos tradicionais de gerenciamento serem
medidos pelo escopo, custo e prazo. Os processos tradicionais enfatizam que o
planejamento deve ser realizado logo no início do projeto, assim como, seus
respectivos requisitos são capturados e congelados após serem capturados,
enquanto que nos processos exploratórios são avaliados pela visão, custo e
prazo, o planejamento é minimalista, com requisitos mínimos e suficientes para
serem explorados e evoluírem através do aprendizado e da mudança.
Na Ilustração 11 é representado o framework do APM que consiste em cinco fases,
cada qual com suas características próprias, que são: visão, especulação, exploração,
adaptação e fechamento.
Ilustração 11 - Framework APM.

Fonte: Martins (2007).
 Visão: Nesta fase tem-se uma visão ampla do negócio ou do produto suficiente
para manter as próximas fases coesas. Esta fase tem três objetivos, sendo o
primeiro obter a visão do produto e o escopo do projeto, definindo o que será
entregue na iteração, o próximo passo, que é o segundo objetivo, é definir as
pessoas que estarão envolvidas no projeto, sendo elas: clientes, gerentes do
produto membros da equipes, dentre outros interessados no projeto. O terceiro
objetivo consiste na equipe do projeto criar uma visão de como irão trabalhar
em conjunto. Nesta fase, há uma documentação mais enxuta do produto,
descrita em alto nível, tal documentação vai amadurecendo nas próximas fases
de especulação e exploração.
 Especulação: Esta fase tem como foco desenvolver um plano de releases
baseado em características e funcionalidades do produto, definir marcos para o
acompanhamento do projeto e um plano de iteração para concretizar a visão.
Nesta fase é estabelecido um plano de ação, porém tal plano no APM é
baseado em especulações e assim são criadas hipóteses de acordo com
informações incompletas. A fase de Especulação possui uma extensão da fase
Visão que consiste de:
o Obter os requisitos básicos e abrangentes do produto;

o Definir a carga de trabalho através de uma lista de funcionalidades e
características do produto;
o Criar um plano de entregas, marcos, plano de iterações no qual inclui
alocação de tempo e recursos para estas features;
o Incorporar estratégias de mitigação de riscos ao plano;
o Estimar o custo do projeto e gerar outras informações administrativas e
financeiras que possam ser necessárias.
 Exploração: Esta fase é composta por três objetivos principais que são:
entrega das features através do gerenciamento da carga de trabalho, ou seja,
entregar o produto que foi planejado para determinada iteração respeitando o
trabalho planejado, o gerente de projetos deve criar uma comunidade
colaborativa e auto-organizada, a colaboração e auto-organização podem
ocorrer naturalmente pelos membros da equipe, e por fim deve ser realizado o
gerenciamento do relacionamento entre as pessoas envolvidas no projeto,
como por exemplo, a interação da equipe com os clientes do projeto.
 Adaptação: Nesta fase a equipe busca rever os resultados das entregas

produzidas, comparando-as com o planejado, onde seu foco está no controle e
na correção. Nesta fase também são absorvidas as lições aprendidas, onde a
equipe procura aprender com seus próprios erros. Ainda nesta fase é realizada
uma análise comparando o desempenho da equipe de projeto e de mudanças,
caso seja necessária, com os resultados da fase Adaptação pode ser elaborado o
replanejamento do projeto e também o planejamento para a próxima iteração.
 Fechamento: Esta é a última fase, na qual a equipe vai concluir o projeto,

passar adiante as lições aprendidas e celebrar a conclusão dos trabalhos. As
características desta fase se aplicam tanto no final dos projetos como no final
de cada “mini-projeto” que ocorre com o término de cada iteração. O objetivo
principal desta fase é revisar e armazenar o histórico das lições aprendidas
tornando-as como experiências para próximos projetos ou para as próximas
iterações.
O APM também possui alguns princípios e valores aplicados a sua prática, os mesmos
devem ser utilizados para que um bom gerenciamento de projeto seja realizado. Os quatro
valores centrais adotados pelo APM são os mesmos descrito no Manifesto Ágil: Resposta a
mudanças ao invés de seguir um plano; Produtos funcionando no lugar de documentações;
Colaboração no lugar de contrato com o cliente; e Interação entre as pessoas no lugar de
processos.
De acordo com Highsmith (2004) apud Araujo (2008), o APM apresenta seis
princípios que são divididos em duas categorias, sendo a primeira relacionada ao produto e ao
cliente e a segunda relacionada ao gerenciamento. Esses princípios e seus relacionamentos
estão representados na Ilustração 12.
Ilustração 12 - Princípios do Gerenciamento Ágil de Projetos.

Fonte: Highsmith (2004) apud Araujo (2008).
Para que a equipe aplique as práticas do APM e consiga obter com seus resultados
alguns benefícios, é fundamental que os valores e seus respectivos princípios sejam seguidos,
pois os princípios possuem pontos importantes para a caracterização do APM, tais como a
geração de entregas iterativas, tendo seus prazos de entrega curtos e fixos e construção de
equipes aptas a mudanças durante o desenvolvimento do projeto, assim como variações de
ambientes.
4.2. Gerenciamento de projetos de software usando o Scrum
Segundo Martins (2007), falar em projeto é basicamente falar em empreendimento, em

que seu trabalho consiste em criar um produto ou executar um serviço especifico, temporário,
não repetitivo e que envolve certo grau de incerteza na realização. Tal trabalho é exercido por
pessoas que despendem horas na realização das atividades e devem cumprir prazo limitado,
custo e escopo. Devido a esses motivos essas atividades devem ser planejadas, programadas e,
durante sua execução, precisam ser controladas.
A disciplina gerenciamento de projetos vem sendo desenvolvida desde a década de 60,
justamente para auxiliar e cumprir os objetivos esperados pelo projeto. O PMI que é um
instituto de gerenciamento de projetos, sem fins lucrativos, é pioneiro na regulamentação e
distribuição deste conhecimento.
O PMI registrou um conjunto de procedimentos associados à teoria de gerência de
projeto em um documento chamado Project Management Body Of Knowledge (PMOK). Tal
documento é utilizado como um guia a fim de orientar, os profissionais da área, sobre o
conhecimento de gerenciamento de projetos, ou seja, trata-se de uma bibliografia de
referência, cujo propósito é padronizar a terminologia e os processos utilizados por meio da
identificação e descrição dos conceitos e práticas de gerenciamento.
De acordo com PMBOK (2008), o PMBOK possui um padrão de processos de
gerenciamento de projetos que são agrupados em cinco categorias, conhecidas como grupos
de processos: Grupo de processos de iniciação, Grupo de processos de planejamento, Grupo
de processo de execução, Grupo de processos de monitoramento e controle e Grupo de
processos de encerramento, como é representado a seguir, na Ilustração 13.
Ilustração 13 - Grupo de processos de gerenciamento de projetos.

Fonte: PMBOK (2008).
 Grupo de processos de iniciação: São os processos realizados para definir um

novo projeto ou uma nova fase de um projeto existente através da obtenção de
autorização para iniciar projeto ou fase. Logo, são identificadas as
necessidades e oportunidade do negócio, avaliando se o mesmo se tornará um
projeto. Para isto, devem ser definidos alguns critérios, pré-requisitos e outras
informações que tornem possível ter a visão de rastreabilidade entre
planejamento e execução. Tais necessidades e oportunidades devem ser
traduzidas, de maneira com que seja possível medir a solução para as mesmas.
Ainda nesta fase, deve ser estimado os recursos necessários e disponíveis, a
viabilidade de atingir os objetivos, apresentar e avaliar a proposta de venda das
idéias, contudo, é possível decidir se a proposta se tornará um projeto;
 Grupo de processos de planejamento: São os processos realizados para
definir o escopo do projeto, refinar os objetivos e desenvolver o curso de ação
necessário para alcançar os objetivos para os quais o projeto foi criado. Esta
fase baseia-se nas informações coletadas e compiladas pelo grupo de processo
de iniciação, tais informações são refinadas e alimentam um plano de trabalho
que será executado durante o processo de execução. Com base na proposta
aprovada, no processo de iniciação, as metas e os objetivos são detalhados,
assim como, é programado os recursos humanos e matérias necessários para
execução do projeto, as atividades, tempo, marcos para acompanhar os
resultados do projeto, comprometimento dos envolvidos no projeto;
 Grupo de processo de execução: São os processos realizados para executar o

trabalho definido no plano de gerenciamento de projeto para satisfazer as
especificações do mesmo. É neste momento que as atividades planejadas
devem ser cumpridas, e caso estejam atrasadas as mesmas devem ser
aceleradas para serem concluídas, mesmo que seja preciso a realocar mais
recursos humanos para isto. Ainda aqui são elaborados os manuais e relatórios
com os resultados finais do projeto, avaliações sobre o desempenho da equipe
do projeto, assim como, os resultados alcançados;
 Grupo de processos de monitoramento e controle: São os processos
necessários para acompanhar, revisar e regular o progresso e desempenho do
projeto, identificar todas as áreas nas quais serão necessárias mudanças no
plano e iniciar as mudanças correspondentes. Logo, os objetivos do projeto
devem ser assegurados de que serão alcançados, do mesmo modo em que o
plano de projeto deve ser seguido. Os processos de controle possuem relação
com os processos de execução, onde mensuram o desempenho das atividades e
verificam se está equivalente ao contrato acordado com os fornecedores.
 Grupo de processos de encerramento: São os processos executados para
finalizar todas as atividades de todos os grupos de processos, visando encerrar
formalmente o projeto ou fase.
Esses processos são organizados em nove em áreas do conhecimento, sendo elas:
Integração, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicação, Riscos e
Aquisições.
Segundo Ávila (2010), baseando-se nas nove áreas citadas, às principais para cumprir
o objetivo de um projeto, de maneira a entregar resultado de acordo com o escopo,
respeitando o prazo e o custo definido e com a qualidade adequada, identificam-se as áreas:
Escopo, Tempo, Custos e Qualidade, que com outra maneira de se expressar é o mesmo que
dizer “o que – equivalente as regras, características e funcionalidades acordadas no escopo,
quando – equivalente ao prazo combinado para a entrega do projeto ou parte do projeto,
quanto – equivalente ao valor monetário, ou seja, valor proposto no orçamento do projeto e
como – equivalente ao resultado final do produto, ou seja, entregar o projeto com a qualidade
adequada a ele”.
As áreas de Recursos Humanos e Aquisições são os recursos para produzir o trabalho
do projeto. Nas áreas de Comunicação e Riscos devem ser controladas as expectativas e
incerteza de maneira continua e controlada, para que desta maneira mantenha o projeto no
rumo certo. E por fim a área de Integração que é responsável por abranger todas as áreas de
maneira organizada.
Na metodologia Scrum os cinco processos de gerenciamento de projetos, existentes no
guia do PMBOK estão indiretamente associados as suas fases, pré-game, game e pós-game,
da seguinte maneira:
Segundo Mota (2010), na metodologia Scrum os processos de iniciação e
planejamento são realizados na fase de pré-game. É nesta fase em que são criados o Product
Backlog e o documento de visão, onde ambos os artefatos conseguem prover a definição do
escopo do projeto, sendo que, por meio deste escopo inicial é possível estimar a quantidade
de iterações e o tempo de desenvolvimento necessário para a construção do produto.
Segundo Viana (2010), no Scrum o cronograma é definido de acordo com o produto
que será produzido em cada Sprint, sendo que tal produto é planejado de acordo com a
prioridade funcional definida pelo cliente ou pelo Dono do Produto. Esses Sprints devem ser
curtos, tendo duração de duas a quatro semanas, de maneira que atenda rapidamente as
necessidades do cliente. Logo, o prazo final do projeto não é claramente definido, pois ele
depende da informação de quanto tempo de duração terá o Sprint e qual a quantidade de
Sprints para o projeto. Mas para o cliente isto não é um grande impacto, até porque o mesmo
recebe produtos parciais, porém funcionais no final de cada Sprint.
Para projetos de gerenciamento ágil como o Scrum, ou em qualquer outro projeto ágil
e até mesmo tradicional, o planejamento do custo é essencial para manter o controle do
retorno de investimento (ROI). Para o Scrum, no qual, alterações e adaptações ocorrem
constantemente, sendo incorporadas dentro dos Sprints, a atenção deve ser maior, pois é
necessário avaliar se tais mudanças irão impactar no escopo do projeto e até onde isso trará
custos não planejados. Esta metodologia favorece a flexibilidade em atender ao cliente, porém
deve-se ficar atendo às variações de custo que a mesma pode trazer com tais mudanças,
portanto é ideal que sejam documentadas e reportadas ao Dono do Produto ou ao Cliente o
quanto antes, para que se faça um replanejamento sobre o custo inicial (VIANA, 2010).
No Scrum a alocação dos recursos humanos necessários para compor o time de
desenvolvimento do projeto ocorre no início do projeto, assim como, toda a infra-estrutura
necessária para realizar o desenvolvimento. Os responsáveis por controlar e monitorar tais
recursos e a continuação do projeto é o Scrum Master e o Dono do Produto, que realizam
essas atividades por meio de reuniões que acontecem ao início de cada iteração e também por
meio da remoção de impedimentos levantados pelo time.
A organização do time que irá fazer parte da iteração ou do projeto é realizada

baseando-se nos conhecimentos e nas habilidades técnicas e de negócios que cada integrante
possui de maneira que os mesmos atendam as necessidades que compõe o Product Backlog.
Segundo Martins (2007), o time é auto-organizado e auto-dirigido sendo responsável
por gerenciar seu próprio trabalho e tendo autoridade por fazer mudanças e adaptações que
julgarem necessárias, porém devem sempre respeitar as práticas e princípios do Scrum para
que o objetivo do projeto seja alcançado. Logo, é necessário que a equipe tenha um objetivo
comum, pois é desta forma que ela consegue adquirir a capacidade de ser auto-organizada
para decompor problemas complexos e produzir planos de ação. O Scrum parte justamente do
principio de que quando os membros da equipe atacam os problemas em conjunto
conseguem obter soluções mais rápidas e criativas.
De acordo com Mota (2010), no Scrum o planejamento das tarefas e produtos de
trabalho é estimado a cada Sprint. As estimativas são baseadas em dados históricos, ou seja,
na experiência que a equipe obteve de outros projetos e no projeto em questão na medida em
que o mesmo avança o seu desenvolvimento.
A qualidade do produto no Scrum é medida no final de cada Sprint, pelo simples fato
de o produto ser entregue em partes pequenas, para as quais são desenvolvidos o código e os
testes. O conjunto do código desenvolvido e os testes aplicados a ele são entregues ao cliente
dando-lhes maior confiabilidade no produto final garantindo sucesso para o projeto como um
todo.
No Scrum os riscos do projeto são tratados como impedimentos, sendo identificados
nas Reuniões Diárias. Tais riscos, considerados impedimentos, são anotados em uma Lista de
Impedimentos e são monitorados e controlados pelo Scrum Master dando um feedback deles
à equipe durante as Reuniões Diárias.
De acordo com Viana (2010), se os riscos não foram corrigidos no próprio Sprint onde
foram identificados, devem ser reavaliados durante as Reuniões de Retrospectiva do Sprint e
ações corretivas devem ser tomadas para que os mesmos sejam eliminados, de maneira que os
próximos Sprints não sejam afetados por eles.
A comunicação no Scrum, com os envolvidos e as partes interessadas, ocorre durante
o projeto inteiro por meio das diversas reuniões que o mesmo possui, por exemplo, nas
Reuniões Diárias todos os envolvidos no desenvolvimento do produto notificam um ao outro
a situação de suas atividades e possíveis impedimentos que estejam afetando o
desenvolvimento. Há também as reuniões de planejamento Sprint Planning 1 e Sprint
Planning 2 onde todos se reúnem para entender a razão do negócio e do produto, assim como
é comunicado a cada membro da equipe quais são suas respectivas tarefas. Além destas
reuniões ainda ocorrem a Reunião de Revisão de Sprint e a Reunião de Retrospectiva onde
por meio das mesmas, são identificadas a situação do projeto e todos podem expressar quais
foram suas experiências e lições aprendidas para o projeto, assim como, dizer o que foi bom e
o que poderia ter sido melhor. Enfim, o Scrum permite que a comunicação seja realizada de
diversas maneiras, porém em todos os momentos de comunicação é importante que se tenha
um documento formal descrendo os respectivos assuntos abordados, nota-se que tais
documentos devem ser simples e objetivos, mantendo a agilidade que a metodologia propõe
(VIANA, 2010).
A fase Game do Scrum refere-se ao processo de Execução, onde o software é
desenvolvido de acordo com o planejado na fase de pré-game, ou seja, nesta fase já estão
definidos os integrantes da equipe, o prazo de duração do Sprint, assim como, as
funcionalidades e características que o Sprint deve conter. Durante esta fase o Scrum Master e
o Dono do Produto devem estar gerenciando e controlando todas as atividades que foram
planejadas para o Sprint, e caso alguma delas estejam atrasadas ações corretivas devem ser
tomadas para eliminá-las.
O controle do andamento do projeto, ou desenvolvimento, é obtido diariamente
através das Reuniões Diárias com a equipe, reuniões essas que devem ser rápidas e objetivas.
Por meio destas reuniões o Scrum Master é responsável por ser o facilitador no projeto
evitando que interferências externas possam vir a prejudicar o trabalho realizado dentro do
Sprint, além das interferências externas é controlado também todo e qualquer tipo de
interferência interna entre a equipe evitando qualquer desvio do objetivo traçado. Além disso,
há mais dois artefatos considerados muito importantes no Scrum que consegue obter o
controle e monitoramento do projeto: Sprint Task Board View – representação gráfica da
quantidade de tarefas, que são medidas em horas, em relação à quantidade de dias que ainda
restam para finalizar o Sprint, por meio deste artefato consegue-se medir a velocidade em que
a equipe está andando e se a mesma irá conseguir cumprir as tarefas planejadas para o Sprint,
logo o outro artefato é Sprint Task Board View – representação por meio de uma lousa a
quantidade de tarefas referente a cada item do Sprint Backlog e suas respectivas situações,
sendo que tais situações podem estar Pendentes, Em Andamento ou Prontas (MOTA, 2010).
E por fim, a fase de Pós-Game é equivalente ao processo de encerramento do projeto.
Esta fase consiste em entregar o produto para o cliente de acordo com o planejado, mas para
que isso aconteça o Scrum tem como prática realizar a reunião de Sprint Review ao final de
cada Sprint, obtendo os resultados do Sprint e analisando o progresso do projeto, assim como,
se os cumprimentos dos compromissos realmente estão de acordo com o planejado. Dessa

forma, é possível avaliar se as variáveis de tempo, requisitos, custo e qualidade estão coesas e
se finalmente estas variáveis estiverem adequadas o release é fechado e a fase de pós-game
entra em andamento com suas devidas atividades, sendo elas: integração, testes adicionais,
documentação de usuário e preparação de material de treinamento (MARTINS, 2007).
Nesta seção foi apresentada a importância em gerenciar projetos com agilidade e
flexibilidade, sendo estes dois pontos essenciais para atuar no mercado competitivo.
Foram apresentados alguns conceitos da definição do gerenciamento ágil de projetos, no
qual foi ilustrado o framework do APM com a descrição de suas respectivas fases.
Ainda nesta seção foram apresentados conceitos de gerenciamento de software utilizando
a metodologia Scrum, na qual a mesma foi associada às práticas do guia do PMBOK, mais
especificamente aos grupos de processos que o mesmo contêm.
Logo, foi possível identificar que o Scrum se adéqua as práticas de gerenciamento de
projetos, por meio das comparações entre as fases, atividades, artefatos e papéis que a
metodologia possui relacionando-as com os grupos de processos e áreas do PMBOK.
Na próxima seção será apresentado um Estudo de Caso, cujo objetivo é apresentar os
conceitos de gerenciamento de projetos, utilizando a Metodologia Scrum, em um cenário real.
5. ESTUDO DE CASO
Segundo Yin (2005), um estudo de caso é uma investigação empírica que investiga um
fenômeno contemporâneo dentro de seu contexto da vida real. Tal investigação pode ser
realizada por meio de entrevistas ou questionários. Para este trabalho, o método adotado para
coletar as informações é a aplicação de entrevista.
5.1. Caracterização da empresa
Atualmente, a tecnologia da informação é encarada como o pilar de sustentação dos

negócios das empresas. Não é possível imaginar uma empresa sem sistemas de gestão que
controlem produção, pessoas, faturamento e estratégias. Além disso, a competitividade do
mercado exige que todos esses sistemas estejam totalmente integrados, melhorando assim,
seus processos internos e conseqüentemente seus produtos e serviços. É outra exigência do
mercado, ainda, que a informação circule rapidamente dentro e fora da empresa.
A empresa Alfa justamente pensando nas exigências do mercado criou uma Fábrica de
Software, localizada na cidade de Araraquara, na qual é composta por profissionais
capacitados. A missão da Empresa Alfa é atender prontamente às necessidades de TI de seus
clientes de maneira isenta, superando suas expectativas através da inovação, do dinamismo,
da criatividade e da qualidade de suas soluções, produtos e serviços. Para tanto, a empresa
busca atender tais necessidades do mercado, por meio de uma gestão ágil e flexível para seus
projetos.
A Empresa Alfa foi a empresa escolhida para a realização do Estudo de Caso, por
possuir características que se adéquam às metodologias ágeis e abordar a metodologia Scrum
para gerenciar seus projetos. O objetivo de entrevistá-la é justamente enxergar a teoria,
levantada com a revisão bibliográfica, por meio de um cenário real. Nas próximas seções
serão apresentados os resultados que tal metodologia trouxe para a empresa.
5.2. Condução do Estudo de Caso
O estudo de caso foi conduzido por meio de entrevista, conforme citado na seção
anterior, no qual foram entrevistados dois gestores da Fábrica de Software. É importante saber
que os dois gestores responderam as mesmas questões, e os dados das respostas obtidas foram
tabulados e descritos na seção seguinte. Abaixo serão apresentadas as questões aplicadas para
o resultado do Estudo de Caso.
1- Há quanto tempo à empresa adota a Metodologia Scrum em seus projetos?

Existia outra Metodologia para gerenciar projetos antes do Scrum?
2- Por que a empresa escolheu a metodologia Scrum para o gerenciamento de
projetos?
3- Quais práticas do Scrum a empresa adotou? Teve alguma prática adotada que
não deu certo?
4- Qual é o tamanho dos Sprints para cada projeto?
5- Existem interação e comunicação dos envolvidos (equipe de projeto, cliente)
nas fases do projeto? Como?
6- Como o gestor monitora e controla as atividades do Sprint?
7- Como é realizado o planejamento de um Sprint?
8- Como é realizada a entrega do produto para os clientes?
9- Qual é o processo quando o cliente solicita alterações ou novas mudanças no
Software que está em desenvolvimento?
10- Em seu ponto de vista quais são as principais vantagens do Scrum? Existe
alguma prática do Scrum que a empresa adota, mas que na sua visão não é tão
viável, ou que poderia ser melhorada? Qual (is) e como?
Nesta seção foram descritas questões aplicadas a entrevista. Os dados obtidos serão
apresentados na próxima seção.
5.3. Tabulação dos Dados
Nesta seção serão apresentados os resultados obtidos na entrevista com os dois

gestores, no qual as respostas serão descritas seguindo a ordem de entrevista, por exemplo, a
resposta obtida pelo primeiro gestor será demarcada por Gest.1 e as respostas do segundo
gestor por Gest.2.
Resultado obtido do primeiro entrevistado (Gest.1):
1- A Empresa Alfa aborda a metodologia ágil Scrum para gerenciar seus projetos
desde 2008, sendo que a metodologia existente antes da mesma era a metodologia
tradicional RUP.
2- A Empresa Alfa passou a adotar a metodologia Scrum, porque um cliente, que a
utilizava, proporcionou a metodologia, afirmando que a mesma era simples, fácil
de aprender e que trazia bons resultados para os projetos. Com isso, a Empresa
Alfa passou a experimentar tal metodologia em seus projetos e, desta maneira,
foram analisados os resultados que a mesma oferecia, na qual se identificou que
realmente eram bons resultados, pois os projetos passaram a cumprir prazo, houve
maior qualidade no produto entregue ao cliente, houve queda nos custos dos
projetos, a equipe se sentia mais motivada, pois a mesma passou a ter uma maior
integração com todos os envolvidos no projeto, inclusive com o cliente e também
os clientes passaram a ter maior satisfação nos produtos entregues a eles. Todos os
envolvidos nos projetos aceitaram o uso da nova metodologia ágil, pois a mesma
foi útil e satisfatória a todos. Segundo o gestor o serviço em si que era realizado
nos projetos, praticamente não mudaram nada, o que aumentou foi à comunicação,
que segundo a visão dos envolvidos, este foi um dos pontos positivos.
3- Inicialmente, a empresa adotou as seguintes práticas: Planning 1, Planning 2,
Estimation, Retrospective, Review, Scrum Board e Product Backlog, Burndown
Chart. Porém, com os resultados obtidos das experiências na utilização da
metodologia, algumas práticas precisaram ser um pouco customizadas para atender
as necessidades da Empresa Alfa . Tais práticas estão descritas abaixo.
 Planning 1 e Planning 2 se resumiram a uma única reunião, sendo
denominada Planning, nesta reunião são apresentadas as estórias
associadas ao Sprint em questão, assim como, já ocorre a divisão e

atribuição das tarefas para os membros da equipe do projeto. O
planejamento do Sprint é relativo a um projeto de escopo fechado, no qual
as datas de início e término são definidas nesta fase.
 O Estimation acontecia exatamente igual no Scrum, utilizando o método do
Planning Poker, no qual se reuniam toda a equipe, juntamente com o
Scrum Master e o Dono do Produto, e desta forma, a equipe estimava cada
estória do Product Backlog.
 Retrospective é uma reunião muito boa perante a visão do Gestor, pois é
possível adquirir as lições aprendidas de cada integrante da equipe, o que
permite saber os pontos fortes e fracos, ou seja, o que pode ser melhorado
no próximo Sprint ou projeto, assim como, o que deve ser mantido, pois
obteve resultado de sucesso.
 Review é uma prática considerada fundamental, perante a visão do Gestor
pois permite o cliente ter contato com o software, no final de cada Sprint,
no qual é obtido feedback do mesmo. Esta é uma prática boa para
identificar riscos e manter o controle do desenvolvimento do produto.
 Daily Meeting é uma reunião que ocorre diariamente, a fim de obter de
cada membro da equipe de projeto o status de suas tarefas, ou seja, o que
cada um fez, o que cada um está fazendo e o que cada um irá fazer até a
próxima reunião. Está reunião é utilizada também para o apontamento de
possíveis impedimentos que podem ocorrer no Sprint.
 Scrum Board é um artefato adotado para controlar o desenvolvimento das
tarefas associadas ao Sprint, por meio deste artefato é possível ter um
feedback diariamente do desempenho da equipe em construir o produto.
 Product Backlog é a lista de todas as funcionalidades que irão compor o
Sprint. Tal lista deve ser elaborada no mínimo duas semanas antes do
Sprint presente.
Segundo o Gestor a única prática que não deu certo foi o Estimation, pois a equipe não
tinha maturidade suficiente para estimar as estórias e por se tratar de um projeto de escopo
fechado, muitas vezes o cliente juntamente com o analista de requisitos, decidiam os itens que
iriam compor o Product Backlog sendo que tais itens teriam que ser desenvolvidos por
questões de regra de negócio, maior retorno de investimento (ROI) e até mesmo pelo fato da
arquitetura do software.
4- O tamanho dos Sprints variam entre duas a três semanas, dependendo do escopo,
em alguns casos raros juntam-se dois Sprints de duas semanas.
5- Durante o Daily Meeting, há a comunicação entre a equipe de projeto, na qual há
uma interação interna entre os membros da equipe do projeto. Há um tempo a
empresa envolvia o cliente a participar desta reunião, porém hoje esta prática não
ocorre mais. Hoje o gestor de projetos ou analista de requisitos faz esta interface
entre cliente e equipe de projeto.
6- Através do Daisy Meeting; gráficos como o Sprint Burndown Chart que visam
obter a quantidade de tarefas que estão sendo realizadas diariamente, assim como
quantidade de tarefas novas inseridas no Sprint, tempo restante para realizar o
release e finalizar o Sprint.
7- O planejamento dos Sprints ocorre da seguinte forma, primeiramente é obtida uma
visão geral, contendo todas as funcionalidades do projeto, o responsável por obter
este primeiro contato com o cliente é o analista de requisitos ou até mesmo o
gestor do projeto. Após este levantamento inicial, da visão geral do projeto, é
realizado o Planning, cujo suas características foram descritas anteriormente, na
questão 3.
8- A entrega do produto para os clientes é realizada por partes, ou seja, é entregue um
conjunto de funcionalidades, que foram acordados para serem desenvolvidos no
Sprint. Desta forma, a Empresa Alfa instala tais funcionalidades (parte do
software) no ambiente do cliente e apresentam-nas à eles por meio do Review. O
objetivo de realizar o Review com o cliente é justamente de obter o feedback dele
referente ao software, sendo que neste momento, é possível que o cliente aceite,
rejeite ou solicita algumas mudanças no produto.
9- Quando o cliente solicita mudanças em um software que já está sendo
desenvolvido, ou seja, há um Sprint no qual estão sendo realizadas as atividades
planejadas, o gestor avalia a granularidade das solicitações e, então verifica se é
possível adaptá-las no Sprint, caso seja possível, pois são mudança simples e que
não afetará o prazo e custo do projeto, as mesmas são adaptadas, mas caso
contrário as solicitações são analisadas e priorizadas podendo entrar, ou não, em
um Sprint futuro.
10- Segundo a opinião do Gestor 1, as principais práticas do Scrum é a comunicação,

modelo do processo simples e eficiente, considerada uma metodologia padrão de
mercado e a Reunião de Retrospectiva é utilizada também para medir o
desempenho dos colaboradores.
Resultado obtido do segundo entrevistado (Gest.2):
1- Desde 2008, a empresa adota a metodologia Scrum para controlar o gerenciamento

de seus projetos de software. Antes de Scrum a metodologia que era abordada era
o RUP.
2- A escolha por utilizar o Scrum, se deu devido a um cliente de TI da Empresa Alfa ,
que a utilizava, ter indicado e relatado que tal metodologia trazia bons resultados,
além de facilitar o gerenciamento tornando-o flexível e ágil, dessa maneira a
Empresa Alfa abordou a metodologia em seus projetos e a utiliza até hoje.
3- Inicialmente a empresa adotou todas as práticas do Scrum, porém ao longo dos
projetos algumas práticas foram customizadas para atender as necessidades da
Empresa Alfa . A única prática que não teve um resultado bom foi a Estimation,
devido a equipe não ter um nível de maturidade para estimar os itens, gastava-se
muito tempo para estimar e reuniam-se muitas pessoas o que não estava sendo
viável para os projetos.
4- Normalmente os Sprints são de duas semanas, dependendo da necessidade do
cliente o mesmo pode ter duração de um mês. Não houve projetos em que o Sprint
foi menor que duas semanas.
5- Há um tempo atrás havia um relacionamento entre equipe de projeto e cliente por
meio do Daily Meeting, porém foi detectado que despendia-se um tempo muito
maior do que o planejado para o Daily Meeting, que deve durar 15 minutos, então
o cliente não participa mais das reuniões diárias. Hoje a interação do cliente ocorre
apenas com o Gestor do projeto e com o Analista de Requisitos, e ambos se
responsabilizam em passar todas as informações para equipe de projeto.
6- A principal ferramenta utilizada para o controle das atividades do Sprint é a Scrum
Board, existe também uma planilha de métricas na qual se encontra o Burndown
Chart, entre outras ferramentas da empresa de gestão de horas e relatórios
desenvolvidos durante os projetos. Porém, por meio da Scrum Board e do
Burndown Chart é possível verificar se o projeto está cumprindo o prazo e custo.
7- Normalmente as estórias que compõe o Product Backlog já são identificadas e

priorizadas entre o cliente e o Gestor/Analista de Requisitos antes da reunião de
Planning, porém tais estórias do Product Backlog são levadas ao Planning
explicadas a equipe de projeto, obtém o entendimento e o compromisso de todos e
desta forma é construído o Sprint.
8- A entrega do produto ocorre no final de cada Sprint, no qual é instalada a aplicação
no ambiente do cliente e posteriormente a aplicação é apresentada pela equipe de
projeto.
9- Quando a alteração solicitada está relacionada a um Sprint que já está em
desenvolvimento, é realizada uma análise com relação ao impacto que tal alteração
poderá trazer no momento ao projeto, em termos de custo, prazo. Se o impacto for
baixo, então a alteração solicitada pode ser adaptada ao Sprint, senão ela é
discutida e priorizada podendo entrar no próximo Sprint.
10- Todas as práticas são boas, às vezes é preciso adaptar uma coisa ou outra nelas
para que as mesmas satisfaçam as necessidades da empresa. A única prática que
não deu certo foi o Estimation, devido aos fatos relatados anteriormente, porém ele
tinha seus pontos positivos como agregar idéias de cada um da equipe, o que era
considerado muito valioso para o projeto.
Nesta seção foram tabuladas as respostas equivalentes as entrevistas realizadas com os

gestores, respectivamente com o Gest.1 e Gest.2, conforme citado anteriormente. Desta
maneira, foi possível identificar que a empresa adota parcialmente as práticas do Scrum, ou
seja, ela adota as práticas que são necessárias para gerenciar seus projetos.
A Empresa Alfa trabalha com projetos de escopo fechado e aberto, porém as práticas
do Scrum utilizadas nestes dois tipos de projetos são as mesmas, o que diferencia é que para
escopo fechado é preciso tomar um cuidado maior, pois há prazos para a entrega dos Sprints.
Foi relatado pelos dois Gestores que as reuniões Daily Meeting, Planning,
Retrospective e Review, além de alguns artefatos como Scrum Board e Burndown Chart, são
muito bem aplicadas e atendem as expectativas para controlar e monitorar os projetos.
Nas reuniões diárias, Daily Meeting, é utilizado o artefato Scrum Board, no qual
propõe uma visão rápida e clara sobre o Sprint. Nesta reunião participam todos os membros
da equipe de projeto, como: gestor, desenvolvedores, testers e pessoal de infra-estrutura.
O objetivo desta reunião é para que todos os envolvidos no projeto tomem
conhecimento por meio de uma lousa (Scrum Board), as tarefas que cada membro deve
realizar, também é possível comunicar a todos as dificuldades encontradas na realização de

alguma tarefa, se tais tarefas forem difíceis de solucionarem no momento em que a reunião
está ocorrendo, então as mesmas são marcadas como Impedimentos na lousa e o Gestor se
responsabilizará em resolvê-la.
Enfim, o Daily Meeting é realizado em uma sala com duração de aproximadamente 15
minutos, no qual os membros utilizam a Scrum Board para representar as tarefas que a
compõe, tais tarefas são associadas as suas respectivas estórias, e cada qual possui um status
sendo eles: TO DO (a serem realizadas), WIP (em andamento) ou DONE (concluídas). É
importante destacar que está ferramenta permite que sejam criadas, alteradas, ou excluídas as
tarefas, estórias ou membros da equipe.
O resultado dessa reunião propõe um ótimo entendimento tanto para o gestor do
projeto quanto para a equipe sobre o andamento das tarefas do projeto, no qual é possível
presumir se o Sprint está cumprindo o planejado, caso seja identificado o contrário então há a
possibilidade de realizar um replanejamento imediato com base nos atrasos que foram
identificados.
O artefato Scrum Board é representado por uma ferramenta free e seu acesso é via
web, o que a torna uma ferramenta flexível, possibilitando que qualquer participante da
reunião possa utilizá-la sem estar na empresa. Tal ferramenta esta ilustrada no Anexo 2 a
seguir.
Foi constatado também que a Empresa Alfa utiliza uma Planilha de Métricas,
representada no anexo 2, para complementar e formalizar o controle e monitoramento do
Sprint/Projeto. Tal planilha de métricas é composta pelo Burndown Chart, que contêm
informações das tarefas planejadas do Sprint, as datas planejadas para o Sprint. Diariamente
esta planilha é atualizada de acordo com o andamento das tarefas, que são acompanhadas
usando o Scrum Board. Além do Burndown Chart há outras informações na Planilha de
Métricas que complementam outros tipos de gráficos, como a quantidade de horas planejadas
e realizadas para cada membro da equipe, quantidade de casos de testes e de defeitos
encontrados no Software para tal Sprint, entre outros.
Enfim, as demais reuniões como Retrospective e Review também ofereceram um
resultado bastante significante a empresa permitindo um feedback nos finais dos Sprints, tanto
da a equipe de projeto, quanto para os clientes. Todos os feedbacks obtidos são tratados como
lições aprendidas, nas quais são analisadas e transformadas em melhorias contínuas.
Os dois Gestores relataram que o Estimation, reunião na qual a equipe do projeto
estimam as estórias do Product Backlog, não trouxeram bons resultados para o projeto,
devido a equipe despender um tempo grande nas estimativas. Isto acontecia muitas vezes por
conta da imaturidade de alguns membros da equipe que, por exemplo, ou não conheciam
muito bem a regra de negócio, ou não entendiam a complexidade de tal funcionalidade.
Porém por outro lado, como relatou o Gest.2, está prática era boa para se trocar idéias e
informações sobre as possibilidades de como desenvolver tal funcionalidade, assim como, era
possível identificar a dificuldade que cada um tinha para desenvolver determinadas
funcionalidades.
Segundo a Empresa Alfa a metodologia Scrum possui boas práticas para gerenciar
projetos de Software, sejam eles projetos simples, complexos, pequenos, grandes, de escopo
aberto ou fechado. Cada projeto deve ser analisado e se necessário algumas customizações
devem ser aplicadas, porém as experiências relatadas com todos esses tipos de projetos nunca
trouxeram problemas à empresa, o gerenciamento utilizando a metodologia Scrum sempre
supriu todas as necessidades.
Nesta seção foram tabulados os resultados do Estudo de Caso aplicado a uma Fábrica
de Software, no qual foram relatados os resultados obtidos pela mesma. Por meio das
entrevistas foi possível notar que é possível gerenciar projetos de Software com Scrum, pois
ela é uma metodologia leve e fácil de usar. Como foi possível notar, a Empresa Alfa não teve
problemas em questão de resistência em adotar a metodologia Srum, sendo o único problema
encontrado a aplicação das estimativas, o que não trouxe grandes problemas à empresa.
CONCLUSÃO
A Engenharia de Software é uma área que cresce a cada dia que passa. Como foi visto
neste trabalho, a busca por softwares inovadores é grande, porém é preciso ter agilidade e
flexibilidade para conquistar o mercado concorrente. É este fato que leva as empresas de
desenvolvimento de software adotarem metodologias ágeis para desenvolver e gerenciar seus
projetos, pois as mesmas não se prendem a contratos e documentações, e sim buscam por
interação e comunicação com os clientes, o que gera maior confiança, troca de informações e
resulta em satisfação para todos.
Desta maneira, como apresentado neste trabalho, por meio da literatura e
principalmente pelo Estudo de Caso, Scrum é uma metodologia de gerenciamento de projetos
que está sendo utilizada por empresas do segmento da Tecnologia de Informação, e está
trazendo resultados positivos em termos de prazos, custo e satisfação dos clientes em relação
aos produtos entregues a eles. Como pôde ser notado por meio do estudo de caso, algumas
empresas não aplicam todas as práticas do Scrum, customizando aquilo que não se adéqua a
sua realidade, pois as necessidades e objetivos organizacionais não são iguais em todas as
organizações.
A Empresa Alfa , como pequena empresa de software, obteve, segundo se pôde
observar, bons resultados aplicando o Scrum. Tanto para projetos de escopo aberto ou
fechado, a empresa aplica as boas práticas do Scrum em todos os seus projetos com as suas
devidas customizações.
Um dos pontos que se observou também foi a dificuldade em aplicar as técnicas de
estimativa propostas pelos métodos ágeis. A imaturidade dos membros da equipe em aplicar
tais técnicas, como por exemplo, o Planning Poker impede que, mesmo sendo uma técnica
simples, seja possível obter os benefícios de discutir a complexidade do trabalho a ser feito
com todos os membros da equipe.
Foi visto também que uma tendência das empresas de pequeno porte ao aplicar os
métodos ágeis para o gerenciamento de projeto é o uso de ferramentas, livres ou não, que
permitam que o gerenciamento possa ser feito de forma ágil e que a equipe possua uma maior
visibilidade do trabalho que está sendo feito. A Empresa Alfa aplica duas ferramentas simples
que auxiliam no decorrer das atividades, a ferramenta ScrumBoard, que permite acompanhar
as tarefas realizadas por todos os membros e a ferramenta Excel, que permite que seja
possível realizar o cálculo de métricas como a relação entre tempo gasto e trabalho realizado,
bem como outras métricas.
Com os resultados obtidos durante as entrevistas realizadas no estudo de caso foi
possível perceber que o Scrum pode auxiliar as empresas de desenvolvimento a realizarem um
melhor gerenciamento dos seus projetos de software. A aplicação do Scrum pode se dar de
forma customizada ou não, bem como com o suporte de ferramentas que auxiliem no
acompanhamento do trabalho.
REFERÊNCIAS
ABRAHAMSSON, P. et al. Agile software development methods Review and analysis.

Relatório Técnico. Finlândia:VIT Publications. 2002.
AGILEZ. Mais agilidade em suas estimativas com o Planning Poker. Disponível em:
<http://www.brasiltech.net/agilez/2009/12/13/mais-agilidade-em-suas-estimativas-com-o-
planning-poker/>. Acesso em: 18 out. 2010.
AMBLER, S. W. Agile Testing and Quality Strategies: Discipline Over Rhetoric.

Disponível em:< http://www.ambysoft.com/essays/agileLifecycle.html>. Acesso em: 20 ago.
2010.
ARAUJO, C. Softwares de apoio ao gerenciamento ágil de projetos colaborativos de

novos produtos: Análise teórica e identificação de requisitos.2008.154 p. Dissertação
(Mestrado) – Universidade de São Paulo, Campus de São Carlos, São Carlos, 2008.
ÁVILA, M. PMBOK e Gerenciamento de Projetos. Disponível em:

<http://www.mhavila.com.br/topicos/gestao/pmbok.html>. Acesso em 28 out. 2010.
BURGOS, T. O desafio do Sprint Planning 2 no Scrum. Disponível em: <

http://imasters.com.br/artigo/18359/agile/o_desafio_do_sprint_planning_2_no_scrum/>.
Acesso em 12 out. 2010.
CAETANO, R. Metodologias de desenvolvimento: qual a mais adequada?. Disponível

em: <http://computerworld.uol.com.br/gestao/2009/08/05/metodologias-de-desenvolvimento-
qual-a-mais-adequada/>. Acesso em: 18 jun. 2010.
CISNEIROS, H.; JACOB, M. S.;MAZZA, S.;PEREIRA,T. Engenharia de Software:

Modelo de Desenvolvimento Ágil Scrum. 2009. 16p. Trabalho Graduação – Faculdade de
Informática e Administração Paulista, Curso de Sistema de Informação, São Paulo, 2009.
CERVO, A. L.; BERVIAN, P.A. (1996). Metodologia científica. 4. ed. São Paulo : Makron
Books, 209 p.
DEVMEDIA.Processos Ágeis para desenvolvimento de Software – Parte 2. Disponível em

< http://www.devmedia.com.br/articles/viewcomp.asp?comp=9209> Acesso em 17 out. 2010.
DEVIN. Modelo de Desenvolvimento Ágil Scum. Disponível em <

http://www.devin.com.br/modelo-scrum/> Acesso em 06 nov. 2010.
ECLIPSE. Scrum: the daily scrum. Disponível em:

<http://www.eclipse.org/org/documents/epl-v10.php>. Acesso em 10 0ut. 2010.
ESPINHA, R. Estimativa utilizando Planning Poker. Disponível em: <

http://blog.euax.com.br/estimativa-utilizando-planning-poker>. Acesso em 06 nov. 2010.
FÉLIX, L. Scrum Checklist. Disponível em:

http://lucianofelix.wordpress.com/2008/04/19/scrum-checklists/. Acessado em 09 nov.2010.
IMPROVEIT. Sprint Backlog. Disponível em: <

http://improveit.com.br/scrum/sprint_backlog>. Acesso em 11 out.2010.
KEN, S.; COLIN, B. SCRUM For Team System. Disponível em:

<http://www.scrumforteamsystem.com/ProcessGuidanceOld/v2/ProcessGuidance.aspx>
______. Sprint Review. Disponível em:

<http://www.scrumforteamsystem.com/ProcessGuidanceOld/v2/Process/SprintReview.aspx>
______. Product Backlog. Disponível em: <

http://www.scrumforteamsystem.com/ProcessGuidanceOld/v2/Artefacts/ProductBacklog.asp
x>Acesso em 12 out. 2010.
______. Artefacts. Disponível em: <

http://www.scrumforteamsystem.com/ProcessGuidanceOld/v2/Artefacts/Artefacts.aspx>Aces
so em 12 out. 2010.
KOSCIANSKI,A.; SOARES, M. S. Qualidade de Software : aprenda as metodologias e

técnicas mais modernas para o desenvolvimento de software. 2.ed. São Paulo: Novatec
Editora, 2007.
MARÇAL, A. S. C. SCRUMMI: um processo de gestão ágil baseado no SCRUM e

aderente ao CMMI. Dissertação (Mestrado) - Fundação Edson Queiroz. Universidade de
Fortaleza. Centro de Ciências Tecnológicas. Fortaleza, 205 p. 2009. Disponível em<
http://www.cin.ufpe.br/~if720/downloads/SCRUMMI%20-%20AnaSofia.pdf>. Acessado em:
09 out. 2010.
MANIFESTO.Princípios por trás do Manifesto Ágil. (2001).Disponível em:

<http://www.agilemanifesto.org/iso/ptbr/principles.htm>l. Acesso em 31 ago. 2010.
MARTINS, J. C. C. TÉCNICAS PARA GERENCIAMENTO de PROJETO de

SOFTWARE. Rio de Janeiro: Brasport ,2007.
MOTA, C. Mapeamento do Scrum para o nível G do MPS.BR. Disponível em:

<http://www.gerenciamentodeprojeto.com/2009/10/mapeamento-do-scrum-para-o-nivel-g-
do.html> Acesso em: 02 nov. 2010.
PRESSMAN, R. Engenharia de Software. 6ª Edição. São Paulo: McGraw-Hill, 2006. 880p.

SILVA, T. F. Compondo Métodos Ágeis de Desenvolvimento de Software. 2009. 83p.
Dissertação (Graduação) – Universidade Federal de Pernambuco, Centro de Informática,
Recife, 2009. Disponível em: <http://www.cin.ufpe.br/~tg/2009-1/tfs.pdf> Acesso em 19 ago.
2010.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. 4.ed.

Project Management Institute, Inc. 2008.
RAMOS, R. Uma comparação entre os modelos ágil e cascata de desenvolvimento de

software. Disponível em: < http://brainstormdeti.wordpress.com/2010/05/25/uma-
comparacao-entremodelo-agil-e-cascata/>. Acesso em: 21 ago 2010.
REZENDE, D. A. ENGENHARIA DE SOFTWARE E SISTEMA DE INFORMAÇÃO.

Disponível em: <http://books.google.com.br/books?hl=pt-BR&lr=&id=rtBvl_L-
1mcC&oi=fnd&pg=PT23&dq=Engenharia+de+Software+%2B+metodologias+tradicionais&
ots=9xho-P_rXu&sig=ssCBaFQzGrypF8uXqBJ2DHdog7o#v=onepage&q&f=false>. Acesso
em: 15 jun. 2010.
SCRIBD.Guia do Scrum. Disponível em: < http://www.scribd.com/doc/35288418/Scrum-

Guide-PTBR>. Acesso em 15 out. 2010.
ScrumAlliance. Scrum é uma abordagem inovadora para receber o trabalho feito.

Disponível em: <http://translate.google.com.br/translate?hl=pt-
BR&sl=en&u=http://www.scrumalliance.org/learn_about_scrum&ei=zpq4TKbYEsP38Aag8I
3DDw&sa=X&oi=translate&ct=result&resnum=4&ved=0CCgQ7gEwAw&prev=/search%3F
q%3Dframework%2Bdo%2BScrum%26hl%3Dpt-BR>. Acesso em 17 out. 2010.
SILVA, A. L. P.; UESONO, G; PEGIHINI, L.; LOPES, P. A. Agile Métodos Ágeis.

Trabalho (Graduação) – Universidade Federal de São Carlos. Centro de Ciências Exatas e
Tecnologia. São Carlos, 8 p. 2006 Disponível em <
http://www2.comp.ufscar.br/~bruno_abrahao/Aulas/ES/MetodosAgeis.pdf>. Acesso em 16
out.2010.
SOARES, M. S. Metodologias Ágeis Extreme Programming e Scrum para

Desenvolvimento de Software. Disponível
em:<http://revistas.facecla.com.br/index.php/reinfo/article/view/146/38 >. Acesso em: 8 jul.
2010.
VAILATI, T. Scrum: Sprint Planning Meeting. Disponível em:

<http://www.vailati.com.br/index.php/scrum-sprint-planning-meeting/> Acesso em 7 out.
2010.
VARASCHIM, J.D. Implantando o SCRUM em um Ambiente de Desenvolvimento de

Produtos para Internet. Disponível em: < http://www.dbd.puc-
o.br/depto_informatica/09_07_varaschim.pdf> Acesso em 6 out. 2010.
VIANA, A. G. G. Gerenciamento de projetos em processo ágil de desenvolvimento de

software. Disponível em: <
http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/393> Acesso em 01 nov. 2010.
YIN, R. Estudo de Caso: planejamento e métodos. 3.ed. Porto Alegre: Bookman.
YOSHIMA, R. Gerenciamento de Projetos com Scrum. Disponível

em<http://www.aspercom.com.br/ead/mod/resource/view.php?id=245>. Acesso em 14 out.
2010.
ANEXO 2 – ARTEFATOS PERTINENTES AO ESTUDO DE CASO


Monografia Meire Scrib

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Monografia Meire Scrib

Caricato da

Copyright:

Formati disponibili

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA “PAULA SOUZA”

FACULDADE DE TECNOLOGIA DE TAQUARITINGA

GRADUAÇÃO EM PROCESSAMENTO DE DADOS

AUTORA: MEIRE ELEN ALVES DA SILVA

ORIENTADORA: PROFª. Ms. ANGELITA MOUTIN SEGORIA

METODOLOGIA ÁGIL DE GERENCIAMENTO DE

Monografia apresentada à Faculdade de Tecnologia de

Orientadora: Profª. Ms. Angelita Moutin Segoria

Meire Elen Alves da Silva

Monografia apresentada à Faculdade de Tecnologia

Data da aprovação: ___/___/______

Aos meus pais, namorado e

Agradeço primeiramente a Deus por me guiar em todo o meu caminho, me dando

A todos os meus amigos e professores de faculdade, por sempre estarem presentes me

A todos os meus familiares e pessoas que me incentivaram em todos os momentos da

À Professora Angelita Mountin Segoria Gasparotto, minha orientadora, pelo apoio,

Cirque Du Soleil – A Reinvenção do Espetáculo; Ed. Campus; Elsevier

Este trabalho visa abordar a metodologia de gerenciamento ágil de projetos de software

Palavras-chave: Metodologias Ágeis. Scrum. Gerenciamento de Projetos. Metodologias

Keywords: Agile Methodologies. Scrum. Project Management. Traditional methodologies.

Ilustração 1- Ciclo de vida Clássico. ..................................................................................................................... 16

1.1. CONTEXTUALIZAÇÃO DO TEMA................................................................................................... 12

2. ENGENHARIA DE SOFTWARE ................................................................................................. 14

2.1. METODOLOGIAS TRADICIONAIS .................................................................................................. 15

3. METODOLOGIA ÁGIL SCRUM .............................................................................................. 32

3.1. CICLO DE VIDA........................................................................................................................... 34

4.1. DEFINIÇÃO DO GERENCIAMENTO ÁGIL DO PROJETO................................................................. 56

5. ESTUDO DE CASO ..................................................................................................................... 70

5.1. CARACTERIZAÇÃO DA EMPRESA.................................................................................................. 70

ANEXO 1 – DECLARAÇÃO PARA REALIZAR ESTUDO DE CASO ........ ERRO! INDICADOR

ANEXO 2 – ARTEFATOS PERTINENTES AO ESTUDO DE CASO ......................................... 87

1.1. Contextualização do Tema

1.2. Justificativa para a escolha do Tema

1.3. Método de Pesquisa Adotado

Este trabalho adotou duas metodologias: Revisão Bibliográfica e Estudo de Caso.

1.4. Estrutura do Trabalho

Este trabalho é composto por 5 seções organizadas da seguinte forma:

Primeira seção: Nesta seção foi apresentada a introdução caracterizando-se a

Segundo Pressman (1995), no início da década de 1980 já haviam reportagens e

 Métodos: Proporcionam os detalhes de “como fazer” para construir um

2.1. Metodologias Tradicionais

De acordo com Martins (2007) as metodologias tradicionais, possuem os processos

2.1.1. O ciclo de vida Clássico

Segundo (PRESSMAN,1995) o ciclo de vida clássico, também chamado de Modelo

Ilustração 1- Ciclo de vida Clássico.

Na primeira atividade, denominada análise e engenharia de sistemas, o principal foco é

constituído de múltiplos passos, sendo os mais importantes a estrutura de dados, os detalhes

A Ilustração 2 representa como o custo de uma modificação torna-se mais elevado

Ilustração 2 - Custo de Modificações no modelo Clássico.

2.2. Metodologias Ágeis

Ilustração 3 - Comparação do custo de mudanças entre metodologias clássicas e ágeis.

Os quatro conceitos-chave do Manifesto Ágil enfatizam:

 Indivíduos e interação em vez de processos e ferramentas: os fatores mais

suficiente, a comunicação com o cliente é essencial para um melhor

Os quatro valores do Manifesto Ágil deram origem a 12 princípios que sustentam o

1. A maior prioridade é satisfazer o cliente através da entrega contínua e rápida de

9. Atenção contínua a excelência técnica e a um bom projeto promove a

Essas mudanças de paradigmas sobre o processo de desenvolvimento e gerenciamento

2.2.1. Extreme Programming (XP)

2.2.2. Feature Drive Development (FDD)

2.2.3. Adaptive Software Development (ASD)

Segundo Caetano (2009), atualmente a metodologia ágil que está em evidência é o

2.2.5. Dynamic System Development Method (DSDM)

Data da aprovação: _/_/______