USCS - UNIVERSIDADE MUNICIPAL DE SÃO CAETANO DO SUL

PROGRAMA DE GRADUAÇÃO EM SISTEMAS PARA INTERNET

(WEB DESIGN)

FELIPE PELICHERO DE SOUZA

AGILE PROJECT MANAGER

Desenvolvimento de um gerenciador Scrum de projetos ágeis

Trabalho de Conclusão de Curso

apresentado como exigência para a
obtenção do título de Graduação
tecnológica em Sistemas para
Internet (Web Design) da
Universidade Municipal de São
Caetano do Sul

Orientador(a)

São Caetano do Sul

2014
FICHA CATALOGRÁFICA

de Souza, Felipe Pelichero

Agile project manager – Desenvolvimento de um Gerenciador de
projetos ágeis/ Felipe Pelichero de Souza – São Caetano do Sul, 2014. Col.
66p.
Trabalho de Conclusão de Curso (graduação tecnológica) –
Universidade Municipal de São Caetano do Sul, Curso de Sistemas para
Internet (Web Design)
Orientador: Dr. Marco Antonio Pinheiro da Silveira
 FELIPE PELICHERO DE SOUZA

Agile Project Manager

Desenvolvimento de um gerenciador de projetos ágeis

Trabalho de Conclusão de Curso

apresentado à Universidade
Municipal de São Caetano do Sul
para a conclusão da graduação
tecnológica em Sistemas para
Internet (Web Design)

Resultado: ___________________________

BANCA EXAMINADORA

Prof.
Universidade Municipal de São Caetano do Sul ________________________

Prof.
Universidade Municipal de São Caetano do Sul ________________________

Prof.
Universidade Municipal de São Caetano do Sul ________________________
DEDICATÓRIA
Dedico este trabalho primeiramente a Deus,
pela saúde, fé e perseverança que tem me
dado. Aos meus pais e amigos pelo incentivo a
busca de novos conhecimentos e
principalmente ao meu orientador, que partilhou
de sua experiência e conhecimento para que
fosse possível a conclusão deste trabalho.
“Quem é dotado de inteligência não se assusta com a inteligência alheia... a ela se
associa.”
(SANTAYANA – 1863-1952)
 Resumo

Neste trabalho foi criado um sistema gerenciador de projetos nomeado APM

(Agile Project Manager), que se apoiou na metodologia Scrum de gerenciamento de
softwares ágeis. O sistema APM foi desenvolvido na linguagem JAVA e uma cópia
está anexada no trabalho. O texto deste Trabalho de Conclusão de Curso está
estruturado da seguinte forma: inicialmente são apresentados conceitos de Métodos
Ágeis, com ênfase na metodologia Scrum. Em seguida apresentam-se as telas e
funcionalidades do Sistema APM, buscando-se apontar a relação entre as
funcionalidades e os conceitos de Scrum apresentados. Por último, apresenta-se um
exemplo de utilização do Sistema APM para acompanhamento do desenvolvimento
de um projeto específico, que se trata do próprio sistema desenvolvido neste estudo.
Entende-se que este trabalho traz uma contribuição relevante, tanto do ponto de
vista teórico como prático, à medida que reúne os conceitos de Scrum e gera uma
aplicação em nível básico, que pode ser usada e servir como referência para outros
usuários ou pesquisadores.

Palavras-chave: SCRUM, Gerenciamento de projetos, Metodologia Ágil.

 Abstract

At this work, a Project manager system was created and named APM (Agile
Project Manager), which relied on agile software managing methodology called
Scrum. The system was developed in JAVA language and a copy is attached at this
work. The text of this end of course paper is structured as follows: first agile
methodology concepts, with emphasis on Scrum methodology, are presented. Then
we present the screens and APM system functionalities, seeking to point out the
relationship between the features and concepts of Scrum presented. Finally it
presents an example of using the APM system for monitoring the development of a
specific project, at this case, the development of this system itself. It is understood
that this work brings significant contribution, both theoretically and practically, as it
brings together the concepts of Scrum and generates an application at a basic level,
that can be used and serve as reference for other users or researchers.

.
Key-words: SCRUM, Project Managing, Agile Methodology.
 LISTA DE FIGURAS

Figura 1 – Jogada do Rugby denominada Scrum. Fonte: 16

Figura 2 - APM Logo 19
Figura 3 - Login 20
Figura 4 - Listagem de projetos 20
Figura 5 – Cadastro de projetos 21
Figura 6 – Menu do sistema 21
Figura 7 - Visão Geral 22
Figura 8 – Sprints visão geral 22
Figura 9 – tarefas visão geral 23
Figura 10 - Gráfico BurnDown 23
Figura 11 – Quadro de tarefas 24
Figura 12 – Post-it 24
Figura 17 - Pesquisa tarefas 24
Figura 18 - Listagem sprints 25
Figura 19 - Cadastro sprints 25
Figura 20 - Pesquisa sprint 26
Figura 21 - Informações Sprint 26
Figura 22 – Ações 27
Figura 23 - Editar sprint 27
Figura 24 - Listagem de backlogs 28
Figura 25 - Filtrar backlog 28
Figura 26 - Cadastro backlog 28
Figura 27 - informações do backlog 29
Figura 28 – Ações 29
Figura 29 - Editar backLog 29
Figura 30 - Listagem de tarefas 30
Figura 31 - Filtro de tarefas 30
Figura 32 - Cadastro de tarefas 30
Figura 33 - Tempo da tarefa 31
Figura 34 - Informações da tarefa 32
Figura 35 – Ações 32
Figura 36 - Editar tarefa 32
Figura 37 – Prova de conceito - login 33
Figura 38 – Prova de conceito – projetos 34
Figura 39 – Prova de conceito – Diagrama de tarefas 35
Figura 40 – Prova de conceito – Backlogs 36
Figura 41 – Prova de conceito - tarefas 37
Figura 42 – Prova de conceito – Mensuração de tempo 37
Figura 43 – Prova de conceito - Sprints 38
Figura 44 – Prova de conceito – Visão Geral 38
Figura 45 – Prova de conceito – Visão Geral (Sprints) 38
Figura 46 – Prova de conceito – Visão Geral (Tarefas) 39
Figura 47 – Prova de conceito – Visão Geral (BurnDown) 39
Figura 48 – Prova de conceito – Quadro de tarefas 40
Figura 49 – Prova de conceito – Quadro de tarefas B 40
Figura 50 – Prova de conceito – Visão Geral (Tarefas) - B 41
Figura 51 – Prova de conceito – Visão Geral (BurnDown) - B 41
Figura 52 – Prova de conceito – Comparação BurnDown 42
Figura 53 – Prova de conceito – Visão Geral (Tarefas) - C 42
Figura 54 – Prova de conceito – Análise BurnDown 43
Figura 55 – Arquitetura MVC. Fonte: http://betterexplained.com/articles/intermediate-
rails-understanding-models-views-and-controllers/ [2014] 44
Figura 56 - APM MER 45
 LISTA DE GRÁFICOS

Gráfico 1 - Usaram metodologia de workflow 51

Gráfico 2 - Controles 51
Gráfico 3 - Metodologia 52
Gráfico 4 - Usuários de Scrum 52
Gráfico 5 - Usaria a solução 53
Gráfico 6 - Considera coerente 53
Gráfico 7 - Mobile 54
Gráfico 8 - Enxergam ganhos financeiros 54
Gráfico 9 - Considera benéfico 55
 SUMÁRIO

Resumo 6

Abstract 7

Capítulo 1 Introdução 13

1.1 Objetivo 13

1.2 Manifesto Ágil 13

1.3 Scrum 15

1.3.1 Características 17

Capítulo 2 Sistema 18

2.1 Apresentação do sistema 19

2.1.1 Logotipo 19

2.1.2 Tela de Login 19

2.1.3 Tela de cadastro e pesquisa de projetos 20

2.1.4 Visão Geral 21

2.1.5 Quadro de tarefas 23

2.1.6 Tela de cadastro e pesquisa de sprints 25

2.1.7 Tela de cadastro e pesquisa de backlogs 27

2.1.8 Tela de cadastro e pesquisa de tarefas 29

Capítulo 3 Aplicação do sistema APM em um projeto 33

Capítulo 4 Características tecnicas 43

4.1 Arquitetura 43

4.1.1 MVC 43

4.2 Tecnologias 44

4.2.1 MySQL 44

4.2.2 JAVA 45
 4.2.3 V-Raptor 3 46

4.2.4 Hibernate 46

Capítulo 5 Conclusão 46

ANEXO A – Instalação do sistema 48

ANEXO B – Pesquisa de viabilidade 49

Referências bibliográficas 56
 13

Capítulo 1 Introdução

Em um processo de desenvolvimento de software existem muitas variáveis a

serem administradas, tais como prazos, custos, balanceamento de tarefas por entre
os participantes do projeto além da constante preocupação com o produto final que
será exposto ao cliente.
A qualidade do produto final está diretamente ligada ao processo e a
organização com o qual o projeto foi desenvolvido e arquitetado, tornando
impossível a execução de tais tarefas de maneira inteiramente manual, expondo o
projeto a riscos que podem causar o comprometimento da entrega por motivos
simples que poderiam ser facilmente administrados, de acordo com Beck [2004], o
desenvolvimento de software tem falhas na entrega e nos valores entregues e essas
falhas têm impactos econômicos e humanos enormes, por isso é de vital importância
o uso de um software de automatização de algumas tarefas auxiliando e dando mais
conforto às pessoas envolvidas.

1.1 Objetivo

O trabalho teve como objetivo a criação de apoio ao gerenciamento de

projetos, a fim de contribuir para suprir algumas carências de gestão de
desenvolvimento de software. O sistema se baseou nas metodologias ágeis e foi
estruturado com base nos pilares do Scrum, que foram implementados na
ferramenta desenvolvida. O sistema busca suprir algumas das constantes
necessidades de controle que ocorrem quando se desenvolve um software.

1.2 Manifesto Ágil

Em fevereiro de 2001, um grupo de desenvolvedores e consultores de

software, insatisfeitos com as técnicas e métodos de desenvolvimento de sistemas
usados até o momento, se juntaram para compartilhar valores e princípios comuns
 14

que eram utilizados em suas práticas e criaram uma aliança que denominaram Agile
Software Development Alliance, mais conhecida como Agile Alliance [SAVOINE et
al., 2009].
Estes profissionais de diversas áreas de formação, com pontos de vista
diferentes sobre os modelos e métodos de desenvolvimento de software em comum,
publicaram um manifesto para encorajar melhores meios de desenvolvedor software
[AMBLER, 2004]. Este documento, definido como o Manifesto Ágil ou Agile
Manifesto, teve como idealizadores: Kent Beck, Ken Schwaber e Martin Fowler, e
tem como foco um conjunto de princípios, que definem critérios para o processo de
desenvolvimento de software ágil, que seguem:
 Indivíduos e iterações acima de processos e ferramentas. Com esse princípio,
o movimento ágil enfatiza que a comunidade de desenvolvedores de software e
seu relacionamento, bem como o aspecto humano, repercutem nos contratos,
em oposição aos processos institucionalizados e ferramentas de
desenvolvimento. Nas práticas ágeis existentes, isso se manifesta nas relações
internas da equipe, nos acordos de trabalho, de ambiente e outros
procedimentos, visando aumentar o espírito de equipe [ABRAHAMSSON et al.,
2002].

 Software em funcionamento acima de documentação abrangente O objetivo

primordial da equipe de desenvolvimento de software é continuamente entregar
releases testados.

 Colaboração com o cliente acima de negociação de contratos.

 Responder a mudanças acima de seguir um plano Segundo Highsmith e

Cockburn [2001, p. 122], “o que há de novo a respeito dos métodos ágeis não
são as práticas que usam, mas o reconhecimento das pessoas como os
principais impulsionadores do sucesso do projeto, juntamente com um intenso
foco na eficácia e capacidade de manobra. Isso gera uma nova combinação de
valores e princípios que definem uma visão de mundo ágil.”. Cockburn [2002, p.
xxii] define o núcleo dos métodos ágeis de desenvolvimento de software como o
uso de regras “leves-mas-suficientes” para comportamento do projeto. O
 15

processo é ágil leve e suficiente. “Leveza é um meio de permanecer manobrável.

Suficiência é uma questão de ficar no jogo” [ABRAHAMSSON et al., 2002].

 Os princípios básicos de métodos ágeis compreendem honestidade ao código

de trabalho, eficácia das pessoas que trabalham em conjunto e foco no trabalho
em equipe. Assim, o grupo de desenvolvimento, incluindo desenvolvedores e
representantes do cliente, deve ser bem informado, competente e autorizado a
considerar o eventual ajuste das necessidades emergentes durante o processo
de ciclo de vida do desenvolvimento. Isto significa que os participantes estão
preparados para fazer mudanças, e que também os contratos existentes são
formados com as ferramentas que suportam permitem que essas melhorias
sejam feitas.

1.3 Scrum

As primeiras referências na literatura ao termo “Scrum” apontam para o artigo

de Takeuchi e Nonaka [1986], The New Product Development Game, um estudo de
aso da indústria de computadores e impressoras e automobilística [TAKEUCHI &
NONAKA, 1986] que relata o processo de desenvolvimento adaptativo, rápido auto
organizado iniciado por dez empresas inovadoras japonesas. O termo “Scrum” – que
deriva de uma estratégia no jogo de rúgbi, conforme Figura 1.
 16

Figura 1 – Jogada do Rugby denominada Scrum. Fonte:

http://cs.wikipedia.org/wiki/Rugby_union [2014]

Foi introduzido para definir práticas adaptativas utilizadas em times auto

gerenciáveis. Após a introdução do conceito japonês, Jeff Sutherland e Ken
Schwaber, em 1994, se reuniram para formalizar, refinar e implantar o processo
Scrum dentro da sua organização, produzindo o artigo The Scrum Development
Process, primeira referência formal ao processo ágil de desenvolvimento de
software. Em 2001, Ken Schwaber e Mike Beedle editaram o primeiro livro sobre
Scrum e, em 2004, foi lançada uma nova apresentação da metodologia.
Assim, a metodologia Scrum pôde ser formalmente definida como um
processo de gerenciamento de projetos que pode ser utilizado em diversas áreas, se
concentrando no atendimento às necessidades do negócio [SCHWABER &
BEEDLE, 2002].
Pode ser considerado mais como um framework que uma metodologia, cujas
práticas são aplicadas em um processo empírico iterativo e incremental, para
desenvolvimento de qualquer produto e gerenciamento de qualquer trabalho. A sua
novas realidades organizacionais em ambientes de constante mudança. Além disso,
Scrum foca-se, a partir de princípios herdados de Lean [POPPENDIECK &
POPPENDIECK T., 2003], na ampla comunicação da equipe e cooperação dos
envolvidos no projeto. É suportado por três pilares: transparência, inspeção e
 17

adaptação. A transparência assegura que os aspectos do processo que afetam o

resultado devem ser visíveis para aqueles que administram os resultados
[SCHWABER & SUTHERLAND, 2009].
Os vários aspectos do processo devem ser inspecionados com frequência
suficiente para que as variações inaceitáveis no processo possam ser detectadas. A
frequência de inspeção tem que levar em consideração que todos os processos são
alterados pelo ato da inspeção [SCHWABER & SUTHERLAND, 2009]. Assim, se o
inspetor determina que um ou mais aspectos do processo estejam fora dos limites
aceitáveis, e que o produto resultante será inaceitável, o inspetor deve ajustar o
processo ou o material a ser processado, e essa adaptação deve ser feita o mais
rápido possível [SCHWABER & SUTHERLAND, 2009]. Não há especificações
quanto às práticas de construção; as equipes são auto organizadas e o processo é
orientado a objetivos e resultados [SCHWABER & BEEDLE, 2002]. Decisões de
como usá-la e criação de estratégias para obter produtividade e realizar entrega de
artefatos, ficam por conta de quem está aplicando o processo [SCHWABER, 2004].

1.3.1 Características

 Sprint: É uma iteração (que pode ser parte de uma entrega) que deve ser
realizada entre 2 a 4 semanas, no qual a equipe do projeto deverá produzir um
pacote de valor para o cliente.

 Backlog: O Backlog é uma lista contendo todas as funcionalidades desejadas

para um produto, as funcionalidades então são quebradas em itens e tais itens
são, então, transferidos do Backlog para o Sprint. Ao fazer isso, a equipe quebra
cada item do backlog em uma ou mais tarefas do sprint ajudando a dividir o
trabalho entre os membros da equipe.

 Gráfico Burndown: É uma forma visual e rápida de enxergar o status atual do

projeto. Ele possui uma estrutura simples, onde o eixo X representa os dias do
sprint e eixo Y representa o trabalho restante. É formado por duas retas: uma de
tendência, que representa uma iteração ideal onde o trabalho é concluído de
forma uniforme e estável, e a reta real, que representa o trabalho realizado pela
 18

equipe ao longo do tempo estipulado. A reta real decresce conforme as tarefas

vão sendo finalizadas ao longo da sprint [SCHWABER, 2004].
Para montar o BurnDown Chart é utilizado o método de Planning Poker. Esse
método foi primeiramente descrito por James Grenning [2002] e popularizado nas
metodologias ágeis através de Mike Conh no seu livro Agile Estimating and
Planning [COHN, 2005]. O Planning Poker não é nativo de Scrum, mas é
largamente utilizado no seu processo de estimativa, que utiliza cartas de baralho
que somente são exibidas após a descrição da atividade a ser executada.
Usualmente se utiliza a escala de Fibonacci (1, 2, 3, 5, 8, 13, 21...) para a
avaliação de complexidade; assim, o valor quantitativo escolhido para um item
através da escala é diretamente proporcional a sua complexidade.
No Planning Poker cada tarefa é discutida de modo sucinto. Cada participante dá
sua nota de complexidade com base na escala definida para cada tarefa e, caso
haja consenso, a complexidade é validada e atribuída à tarefa. Se houver
divergência se abre espaço para discussão com as pontas de maior e menor
valor e são reapresentadas as escolhas do valor de complexidade da equipe
após a discussão. Caso ainda não haja consenso o Scrum Master tem a
responsabilidade de intervir [BENTZEN, 2009].

 Quadro de tarefas: Depois de estimadas todas as tarefas, o Scrum Board

montado com os post-its de cada funcionalidade e estórias, com suas devidas
pontuações de complexidade O quadro de tarefas utilizado no SCRUM é uma
maneira gráfica de representar em qual estado a tarefa está no momento e é
dividido em quatro principais etapas.
o A fazer
o Em progresso
o A verificar
o Concluído
Os integrantes do time têm o poder de manipular as tarefas conforme
desejado.

Capítulo 2 Sistema
 19

O sistema é dotado das seguintes características:

 Gerenciamento de projetos: O gerenciamento de projetos será possível a
partir da tela de Visão Geral, proposta pela qual o usuário poderá navegar por
entre as tarefas e processos pertencentes ao desenvolvimento, será possível ter
a ampla visão do projeto como um todo a partir do Gráfico BurnDown, lista de
sprints e tarefas de cada sprint.

 Gerenciamento dos sprints de um projeto: A equipe de desenvolvimento

poderá acompanhar o andamento do sprint, e manipular o status das tarefas, a
partir do quadro de tarefas.

 Priorização de tarefas do projeto: O usuário será capaz de manipular o tempo

da tarefa na tela de tarefas.

2.1 Apresentação do sistema

2.1.1 Logotipo

Figura 2 - APM Logo

O Logotipo (Figura 2) é composto de dois elementos principais, a bola de

futebol americano representando o rúgbi que é símbolo da metodologia, e o fogo
que traz a ideia de velocidade, agilidade, que representa o desenvolvimento ágil.
 20

2.1.2 Tela de Login

Tela de acesso (Figura 3), responsável por validar o usuário a usar o sistema.

Figura 3 - Login

2.1.3 Tela de cadastro e pesquisa de projetos

 21

A tela de projetos (Figura 4) será a porta de entrada para o sistema.

Figura 4 - Listagem de projetos

O usuário poderá escolher qual será o projeto ele atuará clicando no botão
“trabalhar”. O usuário também será capaz de inserir um novo projeto clicando no
botão “novo”, e será aberto uma tela modal para o cadastro de um novo projeto,
conforme Figura 5.

Figura 5 – Cadastro de projetos

Será possível que o usuário entre com o nome e a descrição do projeto. Após
inserir, a tela será automaticamente recarregada com o projeto novo.
A partir da escolha do projeto, o usuário terá acesso as seguintes ferramentas
do sistema:
 Visão Geral: Tela que proporcionará a visão do andamento do projeto.
 22

 Quadro de tarefas: Quadro de manipulação das tarefas cadastradas.

 Sprints: Tela de cadastro e listagem de sprints.
 Backlogs: Tela de cadastro e listagem de backlogs.
 Tarefas: Tela de cadastro e listagem de tarefas.
Todas as funcionalidades do sistema poderão ser acessadas através de um
menu horizontal, conforme Figura 6.

Figura 6 – Menu do sistema

2.1.4 Visão Geral

A tela de visão geral é a mais importante do sistema, dado que o usuário tem
acesso as informações pertinentes ao andamento do projeto, levando em
consideração o andamento de cada sprint, quantos backlogs o sprint possui, total de
tarefas, dias de trabalho do sprint e as tarefas que estão vinculadas ao sprint, como
pode ser analisado na Figura 7.

Figura 7 - Visão Geral

Tabela de sprints em aberto do projeto, conforme Figura 8:

 23

Figura 8 – Sprints visão geral

Ao clicar na linha do sprint desejado, as informações pertinentes a ele serão

atualizadas na tabela de tarefas referentes ao sprint clicado, contendo o código da
tarefa o nome da tarefa, o backlog o qual a tarefa está atrelada, o colaborador, a
duração da tarefa, a data de conclusão e o status o qual a tarefa se encontra, abaixo
a tabela de tarefas referentes ao sprint clicado, como pode ser analisado na Figura
9.

Figura 9 – tarefas visão geral

Ao clicar no sprint desejado o gráfico Burndown também é atualizado que é

uma representação gráfica de Trabalho X Tempo, conforme Figura 10.
 24

Figura 10 - Gráfico BurnDown

2.1.5 Quadro de tarefas

O quadro de tarefas é outra ferramenta utilizada no Scrum com a finalidade

de gerenciar o status de cada tarefa permitindo que o usuário manipule, de maneira
gráfica e clara, as tarefas pertencentes ao projeto, segue o quadro analisado na
Figura 11.

Figura 11 – Quadro de tarefas

 25

Nota-se que existem quatro áreas principais na tela e cada área é pertinente a
um status da tarefa, para que o usuário altere o quadro basta clicar e arrastar a
tarefa para a área desejada.
A tarefa aparece no quadro representada por um post-it, conforme Figura 12.

Figura 12 – Post-it

A tela também possui um filtro de pesquisa, para que o usuário possa filtrar as
tarefas de acordo com as opções que desejar. Podendo filtrar tarefas pelo nome,
status, backlog, sprint e membro do time que está em posse da tarefa, segue
imagem abaixo do filtro de pesquisa, como mostra a Figura 17.

Figura 17 - Pesquisa tarefas

2.1.6 Tela de cadastro e pesquisa de sprints

Tela de listagem e cadastro de sprints, nesta tela o usuário terá a opção de

cadastrar e listar os sprints que desejar, veja a Figura 18.
 26

Figura 18 - Listagem sprints

O usuário também terá a opção de cadastrar um novo sprint clicando no

botão “Novo” na parte inferior da tela, conforme Figura 19.

Figura 19 - Cadastro sprints

Ao cadastrar um sprint, o usuário deverá informar o nome do sprint, a

descrição, a data de início e término e devera associar um ou mais backlogs
referentes a ele, os backlogs poderão pertencer apenas a um sprint, portanto só
aparecerá na lista de backlogs para associação os quais não tiverem nenhum sprint
atrelado a ele.
 27

A tela também tem a opção de filtrar o sprint que o usuário desejar a partir
dos campos, na Figura 20.

Figura 20 - Pesquisa sprint

Para visualizar dados referentes ao sprint, basta clicar duas vezes sobre a
linha do sprint que deseja ver e abrirá uma janela modal com as informações extra
do sprint, conforme Figura 21.

Figura 21 - Informações Sprint

O usuário também terá a opção de editar e cancelar, conforme Figura 22.

Figura 22 – Ações

Ao clicar em “editar”, uma janela modal abrirá com o objetivo de editar o

sprint, conforme Figura 23.
 28

Figura 23 - Editar sprint

2.1.7 Tela de cadastro e pesquisa de backlogs

Tela de listagem e inclusão de backlogs, nesta tela o usuário terá a opção de

cadastrar e listar os backlogs que desejar, veja a Figura 24.

Figura 24 - Listagem de backlogs

Também será possível a filtragem dos backlogs desejados a partir do filtro

que se encontra na parte superior da página, conforme Figura 25.

Figura 25 - Filtrar backlog

 29

O usuário também terá a opção de cadastrar um novo backlog clicando no

botão “novo” na parte inferior da tela, conforme Figura 26.

Figura 26 - Cadastro backlog

Para visualizar dados referentes ao backlog, basta clicar duas vezes sobre a
linha do backlog que deseja ver e abrirá uma janela modal com as informações extra
do backlog, conforme Figura 27.

Figura 27 - informações do backlog

O usuário também terá a opção de editar e cancelar, conforme Figura 28.

Figura 28 – Ações

Ao clicar em “editar”, uma janela modal abrirá com o objetivo de editar o

backlog, conforme Figura 29.
 30

Figura 29 - Editar backLog

2.1.8 Tela de cadastro e pesquisa de tarefas

Tela de listagem de tarefas, nesta tela o usuário poderá listar as tarefas que
desejar, veja a Figura 30.

Figura 30 - Listagem de tarefas

Também será possível a filtragem das tarefas desejadas a partir do filtro que
se encontra na parte superior da página, conforme Figura 31.

Figura 31 - Filtro de tarefas

 31

O usuário também terá a opção de cadastrar uma nova tarefa clicando no

botão “Novo” na parte inferior da tela, veja a Figura 32.

Figura 32 - Cadastro de tarefas

Na hora de cadastrar uma tarefa, o usuário será capaz de priorizar a tarefa

estimando o tempo no qual a tarefa será concluída vide Figura 33.
 32

Figura 33 - Tempo da tarefa

Para visualizar dados referentes à tarefa, basta clicar duas vezes sobre a
linha do backlog que deseja ver e abrirá uma janela modal com as informações extra
da tarefa, conforme Figura 34.

Figura 34 - Informações da tarefa

O usuário também terá a opção de editar e cancelar, conforme Figura 35.

Figura 35 – Ações

Ao clicar em “editar”, uma janela modal abrirá com o objetivo de editar a

tarefa, conforme Figura 36.
 33

Figura 36 - Editar tarefa

Capítulo 3
 34

Aplicação do sistema APM em um projeto

Para realizarmos uma prova de conceito, será utilizado como exemplo a

criação do próprio Gerenciador de projetos para que seja possível assim provar de
alguns conceitos citados neste trabalho, será portanto usado dados fictícios, porém
cabíveis manipulando situações para que seja possível efetivamente colocar em
prática o que foi dito.
No sistema apresentado, serão utilizados dois recursos fictícios (Felipe e
Marco), simulando situações e iterações entre eles utilizando a ferramenta.
A primeira tela é de cadastramento e login, podemos analisar na Figura 37.

Figura 37 – Prova de conceito - login

Após entrar no sistema, serão apresentados todos os projetos cadastrados no

APM, como mostra a Figura 38.
 35

Figura 38 – Prova de conceito – projetos

Ao clicar em “trabalhar”, é possível acessar então as efetivas informações do

projeto.

Foram então granularizadas de maneira simples as tarefas que serão

exploradas no sistema que serão listadas em macro tarefas e micro tarefas,
demonstrado no modelo caótico analisado na Figura 39.
 36

Figura 39 – Prova de conceito – Diagrama de tarefas

A partir da granularização das tarefas será possível efetuar o cadastro no

sistema de maneira detalhada, a tradução do modelo caótico acima (Figura 39) será
representada no sistema de acordo com as normas do Scrum. A imagem abaixo,
retrata o cadastramento das atividades em grupos denominados “backlogs”, estes,
são compostos de tarefas.
 37

Para a primeira etapa do projeto, vamos delimitar o primeiro sprint como

“montagem de ambiente”, e será criado o backlog, conforme a Figura 40.

Figura 40 – Prova de conceito – Backlogs

Na tela acima (Figura 40) é possível verificar dois elementos importantes para
a análise do backlog, que são a quantidade de tarefas granulares e o seu status.

A partir da criação dos backlogs, se faz necessário o preenchimento com as

tarefas associadas, conforme a Figura 41.
 38

Figura 41 – Prova de conceito - tarefas

Na tela de cadastros de tarefas, encontra-se um dado importante definido no

Scrum, que é a mensuração da duração da tarefa. No caso damos foi dito como
verdade que cada hora é um ponto, portanto 12 horas são equivalentes a 12 pontos.
Tal mensuração é totalmente mórfica de acordo com as necessidades de cada
projeto, como trata-se de um projeto ágil, foi estabelecido que as tarefas terão no
máximo 20 pontos, sendo que cada dia pode-se consumir 8 pontos por recurso.
Abaixo pode ser analisado na Figura 42 como é estimada a tarefa.

Figura 42 – Prova de conceito – Mensuração de tempo

Portanto, na criação da tarefa, contamos com a iteração física dos recursos

envolvidos, o Scrum conta com uma metodologia já discutida neste trabalho, o
“Plainning Poker”, onde os envolvidos se reúnem para que seja discutida a duração
e dificuldade de cada tarefa. Para facilitar o entendimento do conceito, não será
utilizado dados fracionados, contando apenas como horas cheias.

Após o cadastro das tarefas que comporão o backlog é criado o sprint, a partir
de cada sprint teremos a visão do andamento do projeto, como é visto na tela abaixo
ilustrado na Figura 43.
 39

Figura 43 – Prova de conceito - Sprints

Na tela de sprints, é possível avaliar o início e o término definidos, as tarefas

que o compõe, e os backlogs que o compõe. Um sprint portanto pode compor um ou
mais backlogs, e esses, uma ou mais tarefas, sendo apenas necessário que o sprint
tenha os dias mensurados necessários para que seja plausível e possível a
conclusão de todas as tarefas dada a sua respectiva pontuação.

Vamos analisar agora a tela de “visão geral”, que é o dashboard do nosso

sistema, é por ali que minera-se as informações úteis para a agilização do projeto,
como ilustra a Figura 44.

Figura 44 – Prova de conceito – Visão Geral

Para facilitar a análise da tela, foi dividida em três partes:

1- Sprints (Figura 45):

Figura 45 – Prova de conceito – Visão Geral (Sprints)

 40

Nesta área da tela, destaca-se duas informações, o início e o término do

sprint e os dias de trabalho.

2- Tarefas (Figura 46):

Figura 46 – Prova de conceito – Visão Geral (Tarefas)

No segundo elemento da tela, “tarefas” pode-se observar os colaboradores, a

duração a data de conclusão e o status da tarefa

3- Gráfico-BurnDown (Figura 47).

Figura 47 – Prova de conceito – Visão Geral (BurnDown)

Finalmente o “Gráfico BurnDown”, a linha vermelha representa o consumo

padronizado de horas por dias corridos, seria a linha de tempo ideal do consumo de
tempo por tarefa, a linha azul representa o consumo real de pontos por tarefa em
função do eixo de tempo, podemos então ter uma visão planificada do andamento
das tarefas em relação ao tempo decorrido, mais pra frente nesta simulação vamos
 41

simular a passagem de tempo em relação ao gasto de horas necessárias para cada

atividade e assim apontar o que ocorreu com as atividades e os recursos. Para
darmos continuidade a simulação do sistema entraremos na outra tela do sistema, o
“quadro de tarefas” seremos capazes portanto de manipular os status de cada tarefa
de acordo com o ocorrido. Veja a Figura 48.

Figura 48 – Prova de conceito – Quadro de tarefas

O quadro de tarefas, não é nada mais que um simulador virtual do quadro

branco onde seriam colados os “post-its” com cada tarefa, portanto capabilita os
usuários de “mover os post-its” virtualmente com um recurso “drag-n-drop”, de
acordo com a necessidade de cada tarefa.

É Composto de quatro status, sendo eles: “A fazer”, “Em progresso”, “A

verificar” e “Concluído”. Será simulado então a passagem de um dia da criação do
sprint e a conclusão da primeira tarefa, ilustrado na Figura 49.

Figura 49 – Prova de conceito – Quadro de tarefas B

 42

O início do Sprint foi dia 29/04/2014, a conclusão da primeira tarefa foi

efetivada dia 30/04/2014. Tomando como verdade será analisada a tela de “visão
Geral” (Figura 50).

Figura 50 – Prova de conceito – Visão Geral (Tarefas) - B

O quadro de tarefas foi atualizado, pode-se reparar que a tarefa finalizada

encontra-se concluída. Para que seja possível uma visão melhor sobre o andamento
do Sprint, será novamente analisado o gráfico “BurnDown” (Figura 51).

Figura 51 – Prova de conceito – Visão Geral (BurnDown) - B

No quadro vermelho destacado no gráfico, observa-se o consumo de pontos

de acordo com a passagem de tempo.
 43

A figura abaixo (Figura 52) denota a comparação do gráfico no dia 29/04/14

com o gráfico do dia 30/04/14.

Figura 52 – Prova de conceito – Comparação BurnDown

Ficando claro então o andamento do Sprint ao decorrer dos dias.

A conclusão de cada Sprint fica intrínseca com a data de término comparada

a data atual, portanto, cabe aos integrantes do projeto que se reúnam diariamente
garantindo o andamento de cada tarefa. Será simulada a passagem de 8 dias desde
a criação do Sprint e seu término.

Figura 53 – Prova de conceito – Visão Geral (Tarefas) - C

Podemos analisar na figura acima (Figura 53), que a conclusão das atividades
restantes do sprint se deram perto do término. Abaixo outra análise do gráfico
ilustrada na Figura 54.
 44

Figura 54 – Prova de conceito – Análise BurnDown

O período entre o dia 30/04 e 05/05 não houve consumo de horas, porém a cada
dia passado é realizado o “daily meeting”, que são reuniões pontuais que denotam
se há ou não algum problema para a efetivação da tarefa.

Com o andamento do projeto, as ações simuladas neste trabalho serão apenas

repetidas para cada sprint definido pelo usuário, sendo que a conclusão do projeto
será a entrega de todos os sprints que encontram-se no prazo determinado do
projeto, definindo assim o processo ágil de gerenciamento de projetos.

Capítulo 4 Características tecnicas

4.1 Arquitetura

4.1.1 MVC

Foi adotado como um design-pattern1 arquitetural, o famoso MVC, modelo de

três camadas físicas (3-tier).
 Model - Na arquitetura MVC o modelo representa os dados da
aplicação e as regras do negócio que governam o acesso e a modificação
dos dados.

1
Padrão de projetos
 45

 View - Um componente de visualização renderiza o conteúdo de uma

parte particular do modelo e encaminha para o controlador as ações do
usuário; acessa também os dados do modelo via controlador e define como
esses dados devem ser apresentados.
 Controller - Um controlador define o comportamento da aplicação, é ele
que interpreta as ações do usuário e as mapeia para chamadas do modelo.
Abaixo está ilustrado na Figura 55 o modelo MVC.

Figura 55 – Arquitetura MVC. Fonte: http://betterexplained.com/articles/intermediate-rails-

understanding-models-views-and-controllers/ [2014]

4.2 Tecnologias

4.2.1 MySQL
Possui consistência, alta performance, confiabilidade e é fácil de usar. A
imagem abaixo (Figura 56) ilustra o MER (Modelo de Entidade Relacional).
 46

Figura 56 - APM MER

4.2.2 JAVA
Foi utilizada a tecnologia JAVA voltada à plataforma WEB por ser uma
ferramenta poderosa e eficaz totalmente gratuita, além de ter uma vasta gama de
frameworks desenvolvidos no auxílio do desenvolvimento de aplicações WEB. Suas
principais vantagens:
o Gratuito
o A Linguagem é Orientada a Objetos (OO).
o Possui portabilidade
 47

4.2.3 V-Raptor 3
Como front-controller, que atuará na camada de controle do padrão MVC foi
usado o V-Raptor 3, que é uma iniciativa da empresa brasileira Caelum de
desenvolvimento e consultoria.
O V-Raptor 3 foca em simplicidade e, portanto, todas as funcionalidades que
você verá têm como primeira meta resolver o problema do programador da maneira
menos intrusiva possível em seu código.

4.2.4 Hibernate
Na camada “Model” do MVC, foi usado o Hibernate, framework para
de mapeamento objeto-relacional escrito na linguagem Java, facilita o mapeamento
dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de
uma aplicação, mediante o uso de arquivos (XML) ou anotações Java.

Capítulo 5 Conclusão

O sistema completo foi implementado em um período de aproximadamente

140 horas, utilizando a plataforma de desenvolvimento JAVA e apenas frameworks
gratuitos. Durante o processo de desenvolvimento foi possível utilizar o próprio
Scrum estudado para que fosse possível o controle do projeto de maneira ágil,
conforme a proposta do trabalho.
Pode-se concluir que o trabalho realizado gerou um sistema utilizável
seguindo as premissas e filosofias impostas pela metodologia aplicada, no estudo do
sistema foi possível utilizar do conhecimento adquirido para que o produto final
condissesse com o que foi apresentado, portanto a entrega do sistema já denota de
maneira realística que o Scrum é, de fato uma poderosa ferramenta de gestão de
projetos, mostrando-se versátil e totalmente mórfica para um projeto como este
apresentado.
Assim podemos definir que baseando-se na metodologia SCRUM aliada a um
ambiente de desenvolvimento bem implementado propicia-se um ganho notável em
produtividade e qualidade no exercício da engenharia de software.
 48

ANEXO A – Instalação do sistema

É necessário que você baixe e instale o servidor Apache Tomcat. Após a

instalação, o processo de instalação da aplicação se resume a copiar o arquivo
“.war” (que está no CD anexo) para o diretório webapps da instalação do Tomcat.
Acessar a URL que permite acessar a aplicação. Este passo final consiste em
abrir o navegador e apontar para a URL da aplicação. Para um teste local você pode
ter algo como http://localhost:8080/apm.
É necessário que seja instalado o banco de dados MySQL, as tabelas são
geradas automaticamente assim que você subir a aplicação, para tanto é necessário
apenas a criação de um banco de dados chamado “apm”, servidor deverá ser
configurado com o usuário “root” e a senha “senha”.
 49

ANEXO B – Pesquisa de viabilidade

1- Qual o ramo de atividade de sua empresa?

2- Sua empresa trabalha com desenvolvimento de softwares?

( ) sim
( ) não

3- Sua empresa trabalha com implementação de softwares?

( ) sim
( ) não

4- Você usa alguma metodologia de workflow para controlar os projetos?

( ) sim
( ) não

5- Se não usa nenhuma metodologia como faz seus controles?

( ) manual
( ) relatórios na internet
( ) excel
( ) outros. Especificar:

6- Se usa alguma metodologia, por favor identifique qual

7- Você está satisfeito com o tipo de controle utilizado nos projetos?

( ) sim
( ) não

8- Já usou Scrum?
( ) sim
( ) não
 50

9- Você usaria a ferramenta proposta?

( ) sim
( ) não

10- Você considera coerente com as necessidades de controle

De projetos?
( ) sim
( ) não

11- Seria interessante que esta ferramenta tivesse suporte para

mobile?
( ) sim
( ) não

12 - Na sua opinião é possível enxergar algum ganho financeiro com

A proposta apresentada?

13 - Em uma escala de 0 a 10, qual seria o impacto da implantação de

Tal projeto no caso da sua empresa (levando em consideração mudanças
No workflow da empresa)

14 - Quanto a qualidade do produto oferecido, a proposta do projeto

Afetará beneficamente no produto final? Justifique

15 - É possível enxergar um ganho de tempo após a implantação do

Sistema apresentado?

Com base nas perguntas foi realizada uma pesquisa com 20 participantes
desenvolvedores na área de WEB, verificando a viabilidade da proposta embasada
na opinião dos candidatos vide formulário no Anexo A.
Foi constatado que 80% dos participantes já utilizam alguma metodologia
para desenvolver software.
 51

Não Você
20% usa
algu
ia de
dolog
meto
ma
Não
Sim
os?
projet
os
olar
contr
para
low
workf

Sim
80%

Gráfico 1 - Usaram metodologia de workflow

Não é usado nenhum tipo de gerenciador de projetos criado especificamente

para o desenvolvimento de software, sendo que 75% dos entrevistados utilizam a
ferramenta Excel como controle e 25% das pessoas não utiliza ferramenta algum,
realizando todo o processo manualmente.

25% Se não usa nenhuma

metodologia como faz
seus controles?
Manual
Relatório na internet
75% Excel
Outra

Gráfico 2 - Controles

Um total de 27% das pessoas já conhecem o SCRUM e utilizam como base

de desenvolvimento, em contrapartida a grande maioria utiliza RUP.
 52

Se usa alguma
27% metodologia, por favor
identifique qual
FDD
XP
73% SCRUM
RUP

Gráfico 3 - Metodologia

A grande maioria já teve contato com o SCRUM e 85% dos entrevistados que
já utilizam ou não a metodologia, está disposta a utilizar o gerenciador de projetos
proposto, concluindo assim, que o não uso da metodologia está diretamente ligado a
falta de um sistema automatizado como o APM.

25%

Sim
Não

75%

Gráfico 4 - Usuários de Scrum

 53

15%
Você usaria a solução
proposta
profissionalmente
Sim
Não
85%

Gráfico 5 - Usaria a solução

Diante das necessidades de um controle de fluxo de trabalho, a grande

maioria (75%) concorda que o sistema é coerente com as necessidades que está
disposto a suprir.

25%
Você considera coerente
com as necessidades de
controle de projetos?
Sim
Não
75%

Gráfico 6 - Considera coerente

Fica claro que com o avanço tecnológico a tecnologia mobile é unanimemente

agradável aos entrevistados, mostrando uma grande necessidade de futuramente
ser implementado um sistema voltado a dispositivos como celulares e tablets.
 54

Seria interessante que

esta esta ferramenta
tivesse suporte para
mobile?
Sim
Não
100%

Gráfico 7 - Mobile

85% dos participantes concordam que a utilização do gerenciador trará

ganhos financeiros consequentes do fato de uma disponibilização de um produto
final com mais qualidade e menor incidências de erros durante as manobras do
projeto, sendo que a mesma porcentagem de pessoas acreditam que o produto final
sofrerá impacto positivo diante da utilização do gerenciador de projetos.

15%
Na sua opinião é
possível enxergar algum
ganho financeiro com a
proposta apresentada?
Sim
Não
85%

Gráfico 8 - Enxergam ganhos financeiros

 55

A qualidade de seu
15% produto final será
afetada beneficamente
com a utilização do
software de
gerenciamento de
projetos oferecido?
85% Sim
Não

Gráfico 9 - Considera benéfico

 56

Referências bibliográficas

IMPROVEIT.COM.SCRUM.Acesso em 04 mar. 2012. Disponível em:

<http://improveit.com.br/Scrum>

SCRUM.ORG.WHAT-IS-SCRUM.Acesso em 04 mar. 2012. Disponível em: <

http://www.Scrum.org/what-is-Scrum />

Camara,Fabio.SCRUM. Uma metodologia ágil.Acesso em 04 abr. 2012. Disponível

em: <http://imasters.com.br/artigo/10699/gerencia/Scrum_uma_metodologia_agil/>

DEVMEDIA.COM.Conceitos básicos sobre Metodologias Ágeis para

Desenvolvimento de Software (Metodologias Clássicas x Extreme
Programming).Acesso em 30 abr. 2012. Disponível em:
<http://www.devmedia.com.br/conceitos-basicos-sobre-metodologias-ageis-para-
desenvolvimento-de-software-metodologias-classicas-x-extreme-
programming/10596>

MANIFESTOAGIL.COM.Manifesto para o desenvolvimento ágil de software.Acesso

em 16 mai. 2012. Disponível em: <http://manifestoagil.com.br/>

SCRUMBOARD.COM.What is ScrumBoard ?.Acesso em 24 mai. 2012. Disponível

em: <http://www.Scrumboard.com/>

Burgos,Thiago. Scrum Boards fora da parede.Acesso em 24 mai. 2012. Disponível

em: <http://bytesdontbite.com/tag/Scrum-board/>

MOUNTAINGOATSOFTWARE.COM.Release Burndown.Acesso em 25 mai. 2012.

Disponível em: <http://www.mountaingoatsoftware.com/Scrum/release-burndown>

SCRUMALLIANCE.COM.Glossary of Scrum Terms.Acesso em 25 mai. 2012.

Disponível em: <http://www.Scrumalliance.org/articles/39-glossary-of-Scrum-terms>

VRAPTOR.CAELUM.COM.BR. VRaptor3 - One minute guide Acesso em 30 mai.

2012. Disponível em: <http://vraptor.caelum.com.br/documentation/vraptor3-one-
minute-guide/ >

Cavalcanti,Lucas.Vraptor 3.Acesso em 15 mar. 2012. Disponível em:

<http://www.infoq.com/br/articles/VRaptor3>
 57

WBOTELHOS.COM.BR.JPA e VRaptor 3.Acesso em 15 mar. 2012. Disponível em:

<http://www.wbotelhos.com.br/2010/02/23/jpa-e-vraptor-3/>

Madeira,Marcelo.Vantagens do Vraptor.Acesso em 17 mar. 2012. Disponível em:

<http://celodemelo.wordpress.com/2007/05/12/vantagens-do-vraptor/>

GUJ.COM.BR.Vraptor3+Jquery.Acesso em 19 mar. 2012. Disponível em:

<http://www.guj.com.br/java/214614-vraptor3--jquery>

VRAPTOR.CAELUM.COM.BR.Documentação.Acesso em 28 mar. 2012. Disponível

em: <http://vraptor.caelum.com.br/documentacao/>

HIBERNATE.ORG.Relational Persistence for Java and .NET.Acesso em 20 mar.

2012. Disponível em: <http://www.hibernate.org/>

UFCG,Universidade Federal de Campina Grande .Persistência usando

hibernate.Acesso em 01 mar. 2012. Disponível em:
<http://www.dsc.ufcg.edu.br/~jacques/cursos/daca/html/hibernate/hibernate.htm>

K19.COM.BR.Configurando Hibernate com MySQL.Acesso em 27 fev. 2012.

Disponível em: <http://www.k19.com.br/artigos/configurando-hibernate-com-mysql/>

Biswas,Pahul;Ort,Ed.The Java Persistence API - A Simpler Programming Model for

Entity Persistence.Acesso em 30 mar. 2012. Disponível
em:<http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html>

Sacramento,Miranda Wendell.Introdução à Java Persistence API – JPA.Acesso em

12 mar. 2012. Disponível em: <http://www.devmedia.com.br/introducao-a-java-
persistence-api-jpa/4590>

DOCS.JQUERY.COM.Tutorials:How jQuery Works.Acesso em 03 fev. 2012.

Disponível em:<http://docs.jquery.com/How_jQuery_Works>

API.JQUERY.COM.Perform an asynchronous HTTP (Ajax) request.Acesso em 05

fev. 2012. Disponível em: <http://api.jquery.com/jQuery.ajax/>

W3SCHOOLS.COM.AJAX Tutorial.Acesso em 18 fev. 2012. Disponível em:

<http://www.w3schools.com/ajax/default.asp>

Bastos,Daniel Flores.O que é Model-view-controller (MVC)?.Acesso em 19 mai.

2014. Disponível em:
 58

<http://www.oficinadanet.com.br/artigo/desenvolvimento/o_que_e_model-view-
controller_mvc>

Ferreira, Décio et al. SCRUM:Um Modelo Agil para Gestão de Projetos de

Software.Acesso em 19 mai. 2014. Disponível em:
<http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_19.pdf>

[ABRAHAMSSON et al., 2002] ABRAHAMSSON, P. et al. Agile software

development methods:methods: Review and analysis. VTT Publications 478.
Finlândia. 2002. Disponível em <http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf>.
Acesso em 20/04/2014.

[AMBLER, 2004] AMBLER, Scott W. Lessons in Agility from Internet-Based

Development. IEEE Software. p. 66-73. 2004.

[BECK, 1999a] BECK, K. Embracing Change With Extreme Programming. IEEE

Computer. p. 70–77. 1999.

[BANKI & TANAKA, 2009] BANKI A.; TANAKA S., Metodologias Ágeis: Uma Visão

Prática. Engenharia de Software Magazine, Rio de Janeiro. v. 04. p. 22-29. 2008.

Disponível em <http://www.devmedia.com.br/assgold/listmag.asp?site=48>. Acesso

em 14/04/2014.

[BARNETT, 2006] BARNETT, L. Agile Survey Results: Solid Experience And

Real Results. Agile Journal. 2006.

[SCHWABER, 2004] SCHWABER, K. Agile Project Management with Scrum.

Microsoft Press, 2004.

[SCHWABER & BEEDLE, 2002] SCHWABER, K.; BEEDLE, M. Agile Software

Development With Scrum. Prentice-Hall, Nova Jersey, 2002.

[SCHWABER & SUTHERLAND, 2009] SCHWABER K.; SUTHERLAND J. Scrum

Guide: Developed and sustained. Scrum.org. 2009.

[SZIMANSKI, 2009, apud PLAYFAIR, 2008] SZIMANSKI, F. Extensão Do Scrum

Segundo As Áreas De Processo Do MPS.BR Nível G. 2009. Tese (Mestrado).
Centro de Estudos e Sistemas Avançados do Recife – CESAR, Pernambuco.

[TAKEUCHI & NONAKA, 1986] TAKEUCHI, H.; NONAKA, I. The New Product
Development Game. Harvard Business Review. p. 137-146. 1986.
 59

[HIGHSMITH e COCKBURN, 2001] HIGHSMITH, J.; COCKBURN, A. Agile

Software Development: The Business of Innovation. Computer 34. p. 120-122.
2001.

[SAVOINE et al., 2009] SAVOINE, M.; et al. Análise de Gerenciamento de Projeto

de Software Utilizando Metodologia Ágil XP e Scrum: Um Estudo de Caso
Prático. In: XI Encontro de Estudantes de Informática do Tocantins, 2009, Palmas.
Anais do XI Encontro de Estudantes de Informática do Tocantins. Palmas: Centro
Universitário Luterano de Palmas, 2009. p. 93-102. Disponível em:
<http://pt.scribd.com/doc/51919057/Analise-de-Gerenciamento-de-Projeto-de-
Software-Utilizando-Metodologia-Agil-XP-e-Scrum-Um-Estudo-de-Caso-Pratico>.
Acesso em 01/04/2014.

[BENTZEN, 2009] BENTZEN, Hélio. Avaliação Qualitativa Da Utilização Da

Abordagem Scrum Em Um Ambiente Real Através Do Método Nokia Test. 2003.
68f. Tese (Conclusão de Curso) - Escola Politécnica de Pernambuco da
Universidade de Pernambuco, Pernambuco.