TCC Aporano Play'ed SCRUM'ces

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS
ICEI - Instituto de Ciências Exatas e de Informática
Aporano Alves da Silva Torres
PLAY’ed-SCRUM’ces: UM JOGO EDUCACIONAL PARA AVALIAR E/OU
AUXILIAR O ENSINO-APRENDIZAGEM DE SCRUM
Belo Horizonte - MG
8 de dezembro de 2016

Trabalho de Conclusão do Curso de Graduação em Ci-
ências da Computação, do Instituto de Ciências Exatas e
de Informática - ICEI, Pontifícia Universidade Católica
de Minas Gerais. A ser apresentado como requisito par-
cial para obtenção do título de Bacharel em Ciências da
Computação.
Orientador: Prof. Dr. Carlos Pietrobon
Área de concentração: Engenharia de Software/SCRUM
Belo Horizonte - MG

Trabalho de Conclusão do Curso de Graduação em Ci-
ências da Computação, do Instituto de Ciências Exatas e
de Informática - ICEI, Pontifícia Universidade Católica
de Minas Gerais. A ser apresentado como requisito par-
cial para obtenção do título de Bacharel em Ciências da
Computação.
Orientador: Prof. Dr. Carlos Pietrobon
Área de concentração: Engenharia de Software/SCRUM
Prof. Dr. Carlos Pietrobon - PUC Minas
Prof. Dr. - PUC Minas
Prof. Dr. - PUC Minas
Belo Horizonte - MG

Resumo
A Indústria de Software se tornou uma das maiores e mais influentes nas sociedades
contemporâneas. Como consequência, segue-se a necessidade de uma melhor/maior estru-
turação, planejamento e controle dos processos de desenvolvimento de software, que são
amplamente empregados por esta indústria, para uma melhor qualidade no gerenciamento
de projetos de software. Para tanto a Engenharia de Software se utiliza de determinadas
abordagens das quais podemos citar as Metodologias de Desenvolvimento Ágil devido a
sua maior popularidade atualmente. Sendo o método de desenvolvimento ágil SCRUM,
conhecido por sua grande adaptabilidade e de fácil implantação, um dos maiores respon-
sáveis por esse feito. O que implica em uma melhor qualificação neste método por parte
dos profissionais da área. Atualmente alguns modelos de ensino estão sendo utilizados na
aprendizagem do SCRUM, más que na sua maioria são muito teóricos e/ou manuais. Uma
alternativa cada vez mais explorada são os jogos digitais, capazes de despertar nos joga-
dores/profissionais uma maior motivação/atenção devido à uma maior interação dos mes-
mos com um ambiente mais próximo ao que estes profissionais irão encontrar na prática.
Valendo-se disso o objetivo deste trabalho é desenvolver um jogo educativo digital para
avaliar/auxiliar o ensino-aprendizagem de conceitos sobre a metodologia ágil SCRUM.
Palavras-chave: Engenharia de Software, Gerência de Projetos, Processos, Metodolo-
gias, SCRUM, Ensino-Aprendizagem, Jogos Educativos, Design Instrucional, ADDIE.

Abstract
The Software Industry has become one of the largest and most influential in contempo-
rary societies. As a consequence, there is a need for a better/larger structuring, planning and
control of the software development processes, which are widely used by this industry, for
a better quality in the management of software projects. To this end, Software Engineering
uses certain approaches that we can mention the Agile Development Methodologies due to
their greater popularity nowadays. Being the agile development method SCRUM, known
for its great adaptability and easy deployment, one of the most responsible for this achieve-
ment. What implies in a better qualification in this method on the part of the professionals
of the area. Currently some teaching models are being used in the SCRUM learning, but
mostly they are very theoretical and/or manual. An increasingly explored alternative is the
digital games, which are able to arouse in the players/professionals a greater motivation/at-
tention due to their greater interaction with an environment closer to what these profession-
als will find in practice. The purpose of this paper is to develop a digital educational game
to evaluate/assist the teaching and learning of concepts about the agile SCRUM methodol-
ogy.
Key-words: Software Engineering, Project Management, Processes, Methodologies,
SCRUM, Teaching-Learning, Educational Games, Instructional Design, ADDIE.

Lista de Figuras
1 Etapas da Pesquisa Cientíﬁca . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Camadas da Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . 22
3 Projeto de Fase Única . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Processos para Gerenciamento de Projetos . . . . . . . . . . . . . . . . . . . 27
5 Exemplo de Backlog Priorizado do Produto . . . . . . . . . . . . . . . . . . . 30
6 Exemplo de Backlog do Sprint . . . . . . . . . . . . . . . . . . . . . . . . . 31
7 Exemplo de Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8 Exemplo de Taskboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9 Fluxo de Execução do Scrum para um Projeto . . . . . . . . . . . . . . . . . 33
10 Fundamentação do Framework Scrum . . . . . . . . . . . . . . . . . . . . . . 34
11 Princípios do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12 Processos do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13 Fases do modelo ADDIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
14 Categorias do domínio cognitivo segundo a taxonomia de Bloom (1956) . . . 47
15 Diagrama Entidade Relacionamento - DER . . . . . . . . . . . . . . . . . . . 70
16 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
17 Diagrama de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
18 Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
19 Tela de Boas Vindas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
20 Regras do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
21 Conteúdo de Estudo do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
22 Tela de Início de uma Nova Partida . . . . . . . . . . . . . . . . . . . . . . . 81
23 Botões de Navegação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
24 Primeira e Última Telas do Nível 2 e 3 . . . . . . . . . . . . . . . . . . . . . 83
25 Resultados de uma Partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
26 Tela de uma Partida Pausada . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
27 Tela de uma Partida sendo Parada . . . . . . . . . . . . . . . . . . . . . . . . 87
28 Visualização de uma Partida . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Lista de Tabelas
1 Processos da Fase Iniciar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2 Processos da Fase Planejar e Estimar . . . . . . . . . . . . . . . . . . . . . . 39
3 Processos da Fase Implementar . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Processos da Fase Revisão e Retrospectiva . . . . . . . . . . . . . . . . . . . 40
5 Processos da Fase Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Informações sobre o jogo SimSE . . . . . . . . . . . . . . . . . . . . . . . . 50
7 Informações sobre o jogo X-MED . . . . . . . . . . . . . . . . . . . . . . . . 52
8 Informações sobre o jogo TestEG . . . . . . . . . . . . . . . . . . . . . . . . 53
9 Informações sobre o jogo SCRUM-Scape . . . . . . . . . . . . . . . . . . . . 55
10 Informações sobre o jogo SCRUM’ed . . . . . . . . . . . . . . . . . . . . . . 56
11 Informações sobre o jogo Scrum Game . . . . . . . . . . . . . . . . . . . . . 58
12 Informações sobre o jogo Scrumming . . . . . . . . . . . . . . . . . . . . . . 62
13 Informações sobre o jogo Playing Scrum . . . . . . . . . . . . . . . . . . . . 63

Lista de Abreviaturas e Siglas
EG - Engenharia de Software
GP - Gerência de Projetos
EA - Ensino-Aprendizagem
JE - Jogos-Educacionais/Jogos-Educativos
DI - Design Instrucional
ADDIE - Analyze, Design, Develop, Implement and Evaluate
TS - Time(s) Scrum
DVP - Declaração de Visão do Projeto
BPP - Backlog Priorizado do Produto
EU - Estórias de Usuário
RPS - Reunião de Planejamento do Sprint
PO - Produto Owner/Dono do Produto
RRS - Reunião de Revisão do Sprint
RPS - Reunião de Planejamento do Sprint
BS - Backlog do Sprint
BP - Backlog do Produto/Backlog Priorizado do Produto
BC - Burndown Chart
SM - Scrum Master
EDS - Equipe de Desenvolvimento do Scrum
RPT - Reunião de Planejamento das Tarefas
LT - Lista de Tarefas
RPG - Role Playing Game

Sumário
1 INTRODUÇÃO 11
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Escopo/Limites do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Métodos de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.1 Tipos de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.2 Etapas de uma Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.3 Pesquisa Empregada neste Trabalho . . . . . . . . . . . . . . . . . . . . 18
1.5 Estrutura deste Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 FUNDAMENTAÇÃO TEÓRICA PARA ES/GP/SCRUM 22
2.1 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1 Processo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 Métodos/Práticas da Engenharia de Software . . . . . . . . . . . . . . . 23
2.1.3 Ferramentas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Gerência de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Gerência de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3 Ciclo de Vida do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.4 Processos para Gerenciamento de Projetos . . . . . . . . . . . . . . . . . 26
2.3 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Teoria do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 Principais Componentes do Scrum . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 Visão Geral do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.4 O Framework SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 FUNDAMENTAÇÃO TEÓRICA PARA EA/JE 42
3.1 Ensino-Aprendizagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 Design Instrucional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.2 O Padrão/Modelo ADDIE . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.3 Taxonomia de Bloom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Jogos Educacionais/Jogos “Sérios” . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 ANÁLISE SOBRE JE PARA O EA DE ES/SCRUM 50
4.1 JE para o Ensino-Aprendizagem de ES . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 JE para o Ensino-Aprendizagem de SCRUM . . . . . . . . . . . . . . . . . . . . 54

5 DESENVOLVIMENTO/CRIAÇÃO DO JOGO PLAY’ed-SCRUM’ces 66
5.1 Análise/Projeto Instrucional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.1 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Desenvolvimento Instrucional . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.1 Diagramas do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . . . . . . 69
5.2.2 Regras do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . . . . . . . . 72
5.2.3 Fundamentação teórica sobre a tecnologia Android/Java . . . . . . . . . 74
5.2.4 Dinâmica do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . . . . . . 77
6 CONCLUSÕES E TRABALHOS FUTUROS 90
6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.1.1 Algumas ponderações . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2 Propostas de Possíveis Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . 93
Appendices 101
A Conteúdo Educacional para o Jogo PLAY’ed-SCRUM’ces - Parte Prática 102
B Conteúdo Educacional para o Jogo PLAY’ed-SCRUM’ces - Parte Teórica 124

1 INTRODUÇÃO
A Indústria de Software se tornou uma das maiores e mais influentes nas sociedades
contemporâneas. Modificando, alterando, aumentando etc; a forma como pensamos, agimos e
interagimos nestas sociedades. A influência abrange e provavelmente vai além dos contextos
sociais, políticos e econômicos. Com essa importância segue-se a necessidade, cada vez mais
crescente, de se produzir produtos, bens e serviços em quantidade, qualidade e complexidade
cada vez maiores.
Em conjunto com esse desenvolvimento da Indústria de Software segue-se a necessidade
de uma melhor/maior estruturação, planejamento, construção e controle dos Processos de De-
senvolvimento de Software que são amplamente empregados nesta indústria para uma melhor
qualidade no Gerenciamento de Projetos de Software. Aumentando com isso as responsabili-
dades da Engenharia de Software que é a área dentro desta indústria responsável por planejar,
criar e manter tais processos.
Nos últimos tempos as abordagens de desenvolvimento que vem ganhando populari-
dade, dentro da Engenharia de Software, são àquelas conhecidas como: Metodologias de De-
senvolvimento Ágil. Em particular podemos destacar a utilização/aceitação cada vez mais cres-
cente do método de desenvolvimento e gestão de projetos, SCRUM. Devido a essa maior acei-
tação/utilização do SCRUM os profissionais da área de Engenharia de Software estão se vendo
na exigência de uma melhor qualificação a respeito deste método. No entanto, o mercado de
software ainda carece de tais profissionais qualificados com os conhecimentos necessários para
o emprego desta metodologia.
Atualmente alguns modelos de ensino estão sendo utilizados para a aprendizagem do
SCRUM, mas que na sua maioria são muito teóricos e manuais. Uma alternativa que está se
tornando cada vez mais viável é o emprego de jogos digitais, capazes de despertar nos jogado-
res/profissionais uma maior motivação/atenção devido à uma maior interação dos mesmos com
um ambiente próximo ao que estes profissionais irão encontrar na prática. Possibilitando com
isso, de forma efetiva, auxiliar o ensino-aprendizagem de conceitos e práticas do SCRUM e
consequente capacitação de profissionais nesta metodologia.
Portanto este trabalho objetiva o desenvolvimento de um jogo educativo digital para
dispositivos móveis Android (Smartphone/Tablet), para avaliar/auxiliar o ensino-aprendizagem
de conceitos sobre a metodologia ágil SCRUM. Para o planejamento e desenvolvimento do
jogo será empregada uma metodologia de ensino-aprendizagem, que possibilitará a criação de
um projeto instrucional do qual o jogo será parte integrante, como ferramente instrucional.
1.1 Contextualização
A Indústria de Software movimentou cerca de $140 bilhões em receitas no mundo no
ano 1998, de acordo com a International Data Corp., representando um aumento de 15% sobre
11

as receitas obtidas em 1997 (MORRIS, 2001). Ainda de acordo com (MORRIS, 2001), as receitas
obtidas com vendas de Produtos de Software ao “usuário final” saltarão de $169 bilhões em
1999 para $343 bilhões em 2004. Essas receitas continuaram a apresentar taxas significativas
de crescimento nos anos seguintes até que em 2013, no mundo, elas alcançaram cerca $407,3
bilhões o que corresponde há um aumento de 4,8% sobre o montante em receitas movimentado
em 2012 que foi de $388,5 bilhões (GARTNER INC., 2014).
Em 2014 estes valores chegaram a $418 bilhões, considerando apenas os mercados in-
ternos de cada país - excluindo os valores obtidos com as exportações, segundo a Associação
Brasileira de Empresas de Software - ABES (ABES SOFTWARE, 2015). Para o mercado interno
de Software Brasileiro, o montante obtido com as receitas foi de $11,2 bilhões, em 2014, re-
presentado um aumento de 12,8% em relação ao ano anterior e posicionando-o como a oitava
maior economia do Setor (ABES SOFTWARE, 2015).
Nessa Indústria apesar das cifras com as receitas serem tão volumosas e significativas
também o são àquelas que envolem as perdas. Como constatado em/por (THE STANDISH GROUP
INTERNATIONAL INC., 2013) a respeito de projetos de softwares “gerenciados” pelo mundo em
2012; menos da metade dos projetos de software, cerca de 39%, obtiveram o sucesso esperado, o
que significa que foram entregues dentro do prazo, sem “estourar” o orçamento e apresentando
os requisitos e funcionalidades estimados; 43% tiveram algum tipo de mudança/alteração no
decorrer do projeto, o que significa que tiveram suas entregas atrasadas e/ou ficaram “acima”
do orçamento previsto e/ou apresentaram menos requisitos/funcionalidades do estimado; e 18%
do total simplesmente falharam, seja devido ao seu cancelamento antes do término ou que ainda
foram entregues mas não foram utilizados. O que caracteriza entre outras coisas a presença de
falhas nas metodologias e/ou processos e/ou métodos empregados para o desenvolvimento e
gerência de projetos de softwares.
Considerando ainda que o mercado vem exigindo cada vez mais produtos e serviços
com maior qualidade, quantidade e complexidade e em escalas cada vez crescentes segue-se
a necessidade, segundo (CMS - CENTER FOR MEDICARE & MEDICAID SERVICES, 2005), de uma
melhor/maior estruturação, planejamento, construção e controle dos Processos de Desenvolvi-
mento de Software. Permitindo com isso que se atinja uma melhor qualidade no Gerenciamento
de Projetos de Software.
Segundo (PMI INC., 2013), “Projeto é um esforço temporário empreendido para criar
um produto, serviço ou resultado exclusivo”. Ainda de acordo com (PMI INC., 2013), “Ge-
renciamento de projetos é a aplicação do conhecimento, habilidades, ferramentas e técnicas
às atividades do projeto para atender aos seus requisitos” cuja realização se dará por meio da
execução de grupos de processos tais como: iniciação, planejamento, execução, controle e en-
cerramento. Dentre as razões pelas quais se deve gerenciar um projeto de software podemos
citar a diminuição de custos e riscos bem como o planejamento e execução do projeto de forma
à prevenir maiores surpresas (RITTINGHOUSE, 2004).
Na Indústria de Software a área responsável por definir metodologias para o emprego da
gerência no processo de desenvolvimento é a Engenharia de Software. Para tanto a Engenharia
12

de Software faz uso de determinadas abordagens dentre as quais podemos citar: Modelo de
Ciclo de Vida, Metodologias e Processos (WIKIPEDIA, 2014). Sabendo-se então que a definição
dos processos se dá através do emprego de tais abordagens e que os mesmos podem ser mais
adaptados/adequados ao gerenciamento de determinados projetos, dependendo do nicho/área
em que os mesmos estão inseridos, por isso então a adoção de uma única abordagem não será
viável (WIKIPEDIA, 2014; CMS - CENTER FOR MEDICARE & MEDICAID SERVICES, 2005). Dessa
forma faz-se necessário uma avaliação para se determinar qual abordagem se adapta melhor a
determinados Processos e/ou Projetos de Softwares (CMS - CENTER FOR MEDICARE & MEDICAID
SERVICES, 2005).
Nos últimos tempos uma das abordagens que vem ganhando popularidade são àquelas
de Metodologias de Desenvolvimento Ágil em substituição as mais tradicionais como àquelas
abordagens baseadas no Modelo em Cascata (LARMAN; BASILI, 2003). Essa preferência talvez
seja explicada devido entre outros fatores às metodologias tradicionais serem baseadas em um
conjunto de crenças/valores que não são compatíveis com incertezas inerentes a muitos projetos
de desenvolvimento de software (RUBIN, 2013). Enquanto que as metodologias ágeis se valem
dessas variações e incertezas inerentes ao desenvolvimento para criarem novas soluções (RUBIN,
2013). Também pelo fato destas possuírem um alto grau de adaptação, fácil implantação e a
satisfação do cliente como principal prioridade (MANIFESTO..., 2001).
Dentre as metodologias ágeis podemos destacar a utilização/aceitação cada vez mais
crescente do método de desenvolvimento ágil SCRUM (SCHAEFER, 2015). Atualmente diversas
organizações, de setores e tamanhos variados, na sua grande maioria - 95% das organizações,
adotaram o SCRUM como metodologia para o gerenciamento e desenvolvimento de sistemas
(MATARELLI; WHEATON, 2015).
O Scrum é um framework onde se aplicam vários processos e técnicas para o geren-
ciamento de complexos/adaptativos projetos de desenvolvimento por meio de uma abordagem
iterativa e incremental (SCHWABER; SUTHERLAND, 2013b), e “pode ser aplicado de forma efi-
caz em qualquer indústria, para criar um produto, serviço ou outro resultado” (SATPATHY et
al., 2016). Através da adoção do SCRUM como metodologia de desenvolvimento equipes tem
comprovadamente obtido vários benefícios dos quais se destacam: satisfação do cliente, maior
retorno dos investimentos, diminuição dos custos, resultados rápidos e maior prazer no que fa-
zem (RUBIN, 2013). Para atingir tais benefícios é preciso que antes se consiga o domínio do
SCRUM, que será alcançado a partir de muitas experiências vivenciadas na prática, através da
utilização/aplicação dos valores e princípios definidos pela “filosofia” ágil (SHORE; WARDEN,
2008).
Devido a essa maior aceitação/utilização do SCRUM os profissionais da área de Enge-
nharia de Software estão se vendo na exigência de uma melhor qualificação a respeito deste
método. Mas como citado anteriormente o domínio em SCRUM não será obtido de forma
trivial, e exigirá muita prática/experiência na aplicação dos valores e princípios que dizem res-
peito a esta metodologia. Algumas abordagens podem ser utilizadas para auxiliar neste objetivo.
Atualmente a maioria dos cursos superiores onde as disciplinas como Engenharia de Software
13

e/ou Gerência de Projetos se fazem presentes é bem provável que a metodologia SCRUM estará
sendo apresentada. Tais apresentações do SCRUM são realizadas em sua maior parte de forma
teórica devido ao curto tempo de duração dessas disciplinas, não sendo possível portando uma
abordagem mais ampla/profunda e de forma mais prática e mais próximo ao que acontece de
fato em um ambiente real (BENITTI; MOLLéRI, 2008), Gkritsi (2011).
Outros métodos também utilizados para o ensino de SCRUM são através de cursos pro-
fissionais, como em (SCRUM.ORG, 2016), mas que ainda de conteúdo mais teóricos/manuais
e de curta duração. Essa falta de formação específica/adequada no SCRUM gera como re-
sultados, entre outros, a falta de mão de obra qualificada/especializada conforme constatado
em Navarro (2006), Savi (2011), Gkritsi (2011). Também através de uma consulta rápida em
“sítios” especializados em vagas de TI, como exemplo (LINKEDIN, 2016; CEVIU, 2016), é possí-
vel encontrar um número considerável de vagas em “aberto” cujos conhecimentos/experiências
exigidos, entre outros, estão relacionados à metodologia SCRUM. A adoção de metodologias
menos teóricas/manuais e mais práticas/interativas pode facilitar o aprendizado Neto (2008); e
dessa forma possibilitar que se alcance resultados mais eficazes no aprendizado do SCRUM.
Uma metodologia que está sendo cada vez mais difundida/utilizada como estratégia para
superar/diminuir os desafios encontrados no ensino-aprendizagem de ES/SCRUM é a utilização
de jogos Savi (2011). Os jogos apresentam várias características e potenciais como: capacidade
de divertir, entreter, centrados no jogador/usuário, despertam a atenção, motivam, desafiam, alta
iteratividade etc; e quando determinados conteúdos de ensino são “inseridos” de forma eficaz
nestes ambientes/cenários iterativos e dinâmicos possibilita fazer com que o aprendizado seja
incentivado de forma prazerosa e divertida Savi (2011).
Por meio da utilização de jogos é possível proporcionar condições que aumentem a ca-
pacidade do aprendizado através de iniciativas e ações tomadas pelo próprio jogador durante
sua imersão no contexto do jogo Schneider (2015). Permitindo com que o aprendizado ocorra
através das experiências pessoais e verdades criadas/definidas pelo próprio aluno/jogador Sch-
neider (2015). Ao mesmo tempo que os jogos possibilitam a descoberta de novos desafios
aumentando com isso a satisfação de aprender e podem ainda “apontar/mostrar” dificuldades
do jogador/aluno em relação a determinados assuntos Camargo (2013). Jogos utilizados como
recursos didáticos são conhecidos como Jogos Educacionais e permitem disseminar o conheci-
mento a partir de um modelo didático em que o aluno se torna o “ator” principal, através do qual
será possível seguir explorando e experimentando novas “oportunidades” sem correr “riscos” e
assimilar o conhecimento por meio do fazer e não do ouvir Savi (2011).
Os jogos educacionais podem ser digitais ou não; dentre o digitais pode-se citar os jogos
computacionais, para dispositivos móveis etc; já entre os não-digitais temos os jogos de cartas,
tabuleiro etc; os digitais podem ser classificados com relação a gêneros/categorias como às
de: ação, aventura, RPG, simulação etc (WIKIPEDIA, 2016e). Por meio de uma revisão rápida
da literatura é possível constatar que os jogos estão cada vez mais sendo empregados como
recursos didáticos. Em relação a ES não é diferente e o emprego desses recursos para auxiliar
no processo de ensino aprendizado nesta área é cada vez maior. Especificamente para o emprego
14

do ensino em SCRUM é possível citar:
• Scrumming, Neto (2008), um jogo para simular a execução de um Sprint em um projeto
de desenvolvimento, onde o jogador assumirá o papel do Scrum Master com limitações
em suas atividades já que o mesmo não será o responsável por determinar quais recursos
irão ser alocados para o Sprint;
• Play Scrum, Sousa (2009), um jogo de cartas com o auxílio de tabuleiros onde cada jo-
gador assume o papel do Scrum Master e competem entre si para “ver” quem realiza mais
tarefas sem errar, cujo objetivo é o de gerenciamento de um projeto de desenvolvimento;
• Scrum Simulation with LEGO, (KRIVITSKY, 2009), na execução dos Sprints os jogado-
res constroem “elementos” que compõem uma cidade e estes elementos são construídos
a partir de histórias contadas por usuários;
• SCRUM Game, Gkritsi (2011), um jogo para simular o gerenciamento de projetos no
qual os jogadores assumem o papel do Scrum Master, o qual será o responsável por
gerenciar uma equipe, auxiliando-a nas estimativas e atribuição das tarefas de acordo
com o Sprint;
• SCRUMIA, (WANGENHEIM, 2013), um jogo em que os jogadores devem planejar e exe-
cutar um Sprint na gerência de um projeto hipotético;
• SCRUM-scape, Camargo (2013), um jogo RPG de perguntas e respostas dividido em três
níveis em que o jogador para alcançar o próximo nível deverá responder corretamente as
perguntas ou enfrentar um “inimigo”, este jogo permite ao jogador reafirmar conceitos
básicos previamente adquiridos sobre o SCRUM;
• SCRUM’ed, Schneider (2015), um jogo RPG que permitirá reafirmar conceitos bási-
cos previamente adquiridos sobre SCRUM, sua “narrativa” representa a execução de um
Sprint em que o jogador, que assume o papel Scrum Master, tem como objetivo auxiliar
a equipe de desenvolvimento na execução de suas tarefas como por exemplo na remoção
de eventuais obstáculos enfrentados pela equipe; etc.
Pelo motivos expostos dos quais destacam-se: a importância da Indústria de Software
nas sociedades contemporâneas; melhora dos processos de desenvolvimento com um gerencia-
mento de projetos mais eficaz/adequado conseguido através da aplicação de metodologia ágeis
como o SCRUM; e na adoção dos jogos, devido a sua popularidade, para auxiliar no ensino
aprendizado da ES/SCRUM, possibilitando dessa forma empregar na prática os conceitos de-
monstrados em sala de aula e na obtenção, como comprovado pelas avaliações de trabalhos
relacionados, de resultados promissores. Pretende-se com este trabalho o desenvolvimento de
um jogo educativo digital para dispositivos móveis Android (Smartphone/Tablet), para avali-
ar/auxiliar o ensino-aprendizagem de conceitos sobre a metodologia ágil SCRUM.
15

1.2 Objetivos
1.2.1 Objetivo Geral
Como objetivo geral este trabalho visa à um projeto e desenvolvimento de um jogo edu-
cacional digital, para dispositivos móveis Android (Smartphone/Tablet), para avaliar/auxiliar
o ensino-aprendizagem de conceitos sobre a metodologia ágil SCRUM. Dessa forma disponi-
bilizando para o usuário/jogador, um recurso/ferramenta que o possibilitará avaliar/aprender a
respeito desta metodologia.
1.3 Escopo/Limites do Trabalho
1. Este trabalho se limita ao desenvolvimento de um jogo digital educacional, para disposi-
tivos móveis Android – Smartphone e/ou Tablet. Portanto não sendo possível a utilização
deste jogo/aplicativo em outros dispositivos móveis, baseados em outras plataformas e/ou
sistemas operacionais (ex: Iphone/Apple etc).
2. O propósito do jogo será o de avaliar/auxiliar no ensino-aprendizagem dos conceitos so-
bre a metodologia ágil SCRUM. Portanto não sendo abordadas outras metodologias ágeis
empregadas na Gerência de Projetos.
3. O jogo destina-se à apenas um jogador. Não será possível mais de um jogador simultane-
amente.
4. O jogo não disponibilizará recursos gráficos como cenários etc; comuns em jogos do
gênero RPG. A apresentação do conteúdo do jogo, através da interface com o usuário,
será feita basicamente por “elementos” textuais e figuras.
1.4 Métodos de Pesquisa
Nesta subseção será feita uma breve explanação sobre os possíveis tipos de pesquisas
científicas existentes; as possíveis etapas que compõem uma pesquisa científica; e um detalha-
mento maior sobre a pesquisa empregada neste trabalho bem como das etapas que a compreen-
dem.
1.4.1 Tipos de Pesquisa
a) Quanto à Abordagem
16

a.1 Pesquisa Qualitativa
Para (UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009), “A pesquisa qualita-
tiva não se preocupa com representatividade numérica, mas, sim, com o aprofunda-
mento da compreensão de um grupo social, de uma organização, etc.”
a.2 Pesquisa Quantitativa
Para (FONSECA, 2002), “Diferentemente da pesquisa qualitativa, os resultados da
pesquisa quantitativa podem ser quantificados.”
b) Quanto à Natureza
b.1 Pesquisa Básica
Para (UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009), “Objetiva gerar co-
nhecimentos novos, úteis para o avanço da Ciência, sem aplicação prática prevista”.
b.2 Pesquisa Aplicada
Para (UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009), “Objetiva gerar co-
nhecimentos para aplicação prática, dirigidos à solução de problemas específicos”.
c) Quanto aos Objetivos
c.1 Pesquisa Exploratória; c.2 Pesquisa Descritiva; c.3 Pesquisa Explicativa.
d) Quanto aos Procedimentos
d.1 Pesquisa Experimental; d.2 Pesquisa Bibliográfica; d.3 Pesquisa Documental;
d.4 Pesquisa de Campo; d.5 Pesquisa Ex-Post-Facto; d.6 Pesquisa de Levantamento;
d.7 Pesquisa com Survey; d.8 Estudo de Caso; d.9 Pesquisa Participante;
d.10 Pesquisa-Ação; d.11 Pesquisa Etnográfica; d.12 Pesquisa Etnometodológica.
1.4.2 Etapas de uma Pesquisa
Através da figura 1 é possível identificar as etapas que compõem uma pesquisa cientí-
fica.
17

Figura 1 – Etapas da Pesquisa Científica
Fonte: Quivy; Campenhoudt a
citado e adaptado por
(UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009)
a
Quivy & Campenhoudt, 1995
1.4.3 Pesquisa Empregada neste Trabalho
O método de pesquisa que será utilizado neste trabalho classifica-se como um método de
pesquisa aplicada. O que significa que o desenvolvimento deste trabalho objetiva gerar conhe-
cimento com consequente aplicação prática e direcionado à resolver/minimizar a um problema
específico. Isto porque este trabalho objetiva desenvolver um jogo educacional (o conheci-
mento), para ser jogado por estudantes (a prática), para avaliar/auxiliar o ensino-aprendizagem
de conceitos sobre SCRUM (resolver/solucionar a não aprendizagem total/parcial a respeito de
conceitos de SCRUM).
Este método de pesquisa será composto das seguintes etapas:
Etapa 1 - Fundamentação teórica sobre a literatura para ES/GP/SCRUM (parte da Etapa
2 na Figura 1)
Será feita uma análise teórica de parte da literatura existente para a Engenharia de Soft-
ware, Gerência de Projetos e em especialmente em relação a metodologia ágil SCRUM aplicada
à GP. A seguir as atividades que compõem esta etapa:
Atividade 1.1: Análise teórica de parte da literatura para a área de ES.
Atividade 1.2: Análise teórica de parte da literatura para a área de GP.
Atividade 1.3: Análise teórica de parte da literatura para a área de SCRUM.
18

Etapa 2 - Fundamentação teórica sobre a literatura para o Ensino-Aprendizagem e os
Jogos Educacionais (como parte da Etapa 2 na Figura 1)
Será feita uma análise teórica de parte da literatura existente para algumas das metodo-
logias de Ensino-Aprendizagem bem como de suas aplicações por meio de jogos, conhecidos
como Jogos Educacionais, como recursos didáticos. A seguir as atividades que compõem esta
etapa:
Atividade 2.1: Análise teórica de parte da literatura para a área de EA.
Atividade 2.2: Análise teórica de parte da literatura para a área de JE.
Etapa 3 – Fundamentação teórica sobre a literatura de JE para o ensino-aprendizagem
de ES/SCRUM (como parte da Etapa 2 na Figura 1)
Será feita uma análise sobre os JE existentes na literatura para o ensino-aprendizagem
da ES/SCRUM. A seguir as atividades que compõem esta etapa:
Atividade 3.1: Análise de JE aplicados para ES.
Atividade 3.2: Análise de JE aplicados para o SCRUM.
Etapa 4 – Desenvolvimento do Jogo (compreende a Etapa 3 e a Etapa 4 na Figura 1)
Para o desenvolvimento do jogo será empregada uma metodologia de desenvolvimento
que abranja a criação de jogos educacionais. Esta metodologia deverá contemplar tanto os as-
pectos relacionados a jogos (design de jogos) quanto os aspectos relacionados ao ensino/instru-
ção (design instrucional) Savi (2011), Camargo (2013), Schneider (2015). A seguir as subetapas
que compõem esta etapa:
Etapa 4.1 - Análise/Projeto Instrucional (como parte da Etapa 3 na Figura 1)
Definição/Identificação dos conceitos pedagógicos que definem as instruções/conteúdo
educacional do jogo. A seguir as atividades que compõem esta etapa:
Atividade 4.1.1: Análise Instrucional - Definição de metas instrucionais, análise de con-
textos e de quais serão os objetivos de desempenho.
Atividade 4.1.2: Projeto Instrucional - Definição do conteúdo a ser abordado bem como
se dará a sequência do mesmo durante a dinâmica do jogo e quais serão as estratégias
instrucionais.
Etapa 4.2 - Análise/Projeto do Jogo (como parte da Etapa 3 na Figura 1)
Definição dos requisitos, tabelas, diagramas etc; bem como a identificação/desenvolvi-
mento dos elementos constituintes do jogo, incluindo a dinâmica e as regras do jogo. A seguir
as atividades que compõem esta etapa:
19

Atividade 4.2.1: Identificação/Definição de elementos que compõe o jogo.
Atividade 4.2.2: Identificação/Definição da dinâmica do jogo.
Atividade 4.2.3: Identificação/Definição das regras do jogo.
Atividade 4.2.4: Levantamento dos Requisitos.
Atividade 4.2.5: Modelagem de Dados.
Atividade 4.2.6: Construção dos Diagramas (de classe etc).
Etapa 4.3 – Fundamentação teórica/prática sobre Programação para Dispositivos Móveis
Android (como parte da Etapa 4 na Figura 1)
Pesquisar, levantar material e estudar para compreender as tecnologias utilizadas para
programação de aplicativos voltados para dispositivos móveis Android. A seguir as atividades
que compõem esta etapa:
Atividade 4.3.1: Pesquisar, levantar material e estudar sobre as tecnologias de programa-
ção para dispositivos móveis Android.
Atividade 4.3.2: Ler, fazer/criar exercícios/exemplos e compreender a tecnologia.
Etapa 4.4 - Implementação (como parte da Etapa 4 na Figura 1)
Desenvolver/Codificar a aplicação, testar e implantar/distribuir/instalar/configurar. A
seguir as atividades que compõem esta etapa:
Atividade 4.4.1: Desenvolver/Codificar a aplicação.
Atividade 4.4.2: Realizar testes durante/depois da codificação.
Atividade 4.4.3: Distribuir e/ou implantar, instalar e configurar a aplicação.
1.5 Estrutura deste Trabalho
No capítulo 2 será apresentada uma análise teórica sobre a Engenharia de Software, Ge-
rência de Projetos e em especialmente em relação a metodologia ágil SCRUM aplicada à
GP.
No capítulo 3 será apresentada uma análise da literatura existente para algumas das me-
todologias de Ensino-Aprendizagem existentes, bem como de suas aplicações por meio
de jogos, conhecidos como Jogos Educacionais, como recursos didáticos.
No capítulo 4 será apresentada uma análise sobre os JE existentes na literatura para o
ensino-aprendizagem da ES/SCRUM.
20

No capítulo 5 será apresentado o desenvolvimento do JE que envolverá as etapas a seguir:
• Definição/Identificação dos conceitos pedagógicos que definem as instruções/con-
teúdo educacional do jogo.
• Definição dos requisitos, tabelas, diagramas etc; bem como a identificação/desen-
volvimento das funcionalidades/elementos constituintes do jogo, incluindo a dinâ-
mica e as regras do jogo.
• Pesquisar, levantar material e estudar para compreender as tecnologias utilizadas no
desenvolvimento de aplicações para dispositivos móveis Android.
• Desenvolver/Codificar a aplicação, testar e distribuir/instalar/configurar.
No capítulo 6 será apresentada à conclusão do trabalho, com uma avaliação comparativa
do que se propôs a fazer com o que de fato foi feito/realizado e propostas de possíveis
trabalhos futuros.
21

2 FUNDAMENTAÇÃO TEÓRICA PARA ES/GP/SCRUM
Neste capítulo será apresentada uma análise teórica sobre parte da literatura existente
para a Engenharia de Software, Gerência de Projetos e em especialmente em relação a metodo-
logia ágil SCRUM aplicada à GP.
2.1 Engenharia de Software
Segundo (PRESSMAN, 2011), Engenharia de Software é uma “espécie” de tecnologia
baseada em camadas (Figura 2), cuja fundamentação/base deverá ser/ter o foco na qualidade
quando na definição de processos, métodos/práticas e ferramentas para o apoio da mesma. Com
a aplicação desses recursos, definidos por essas “camadas”, será possível o desenvolvimento
de melhores projetos de software, com a possibilidade de um melhor controle/gerenciamento,
tendo como consequência um produto de software de qualidade, confiável, mais eficiente, en-
tregue dentro do prazo e sem “estourar” o orçamento.
Figura 2 – Camadas da Engenharia de Software
Fonte: (PRESSMAN, 2011)
Ainda segundo (PRESSMAN, 2011), a camada de processos seria a base para a enge-
nharia de software e a responsável por unir as outras camadas. Por meio desta camada está
fundamentada a gerência de projetos de software e a definição de um contexto para aplicação
dos métodos/práticas da engenharia de software. A camada de métodos fornece informações
técnicas e envolvem tarefas como: comunicação, requisitos, modelagem, implementação, testes
e suporte. Já a camada de ferramentas dará o suporte necessário para as outras duas camadas de
forma a automatizar suas respectivas atividades e práticas.
2.1.1 Processo de Software
Definição de Processos de Software para a Engenharia de Software segundo (PRESSMAN,
2011).
Processo é a aplicação de um conjunto de atividades, ações e tarefas que objetivam
produzir um produto como resultado. Uma atividade poderá ser empregada independe do campo
de aplicação, do projeto e de esforços necessários para se chegar ao resultado. Uma ação se
22

constitui a partir da execução de um conjunto de tarefas que resultará, em um contexto de
processo de software, em um artefato de software. Para uma tarefa caberá a responsabilidade
de um objetivo menor mas bem definido que produzirá um resultado concreto.
Para a engenharia de software um processo não é, e não deverá ser, um conjunto de ativi-
dades, ações e tarefas preestabelecidos que deverão serem executadas de forma invariavelmente
para desenvolver um produto de software. Mas sim uma metodologia adaptativa, dependente do
projeto de software etc, por meio da qual será possível a seleção/escolha de um conjunto mais
apropriado de ações e tarefas a serem empregados na realização do trabalho.
Utilizando-se de uma estrutura de processos será possível a identificação/definição de
atividades base, como: comunicação; planejamento; modelagem; construção; e emprego. Es-
sas atividades base podem/devem ser empregadas em qualquer processo/projeto de desenvol-
vimento de software, dos mais simples e menores ao mais complexos e maiores. Essa mesma
estrutura de processos possibilitará/permitirá ainda a “adição” de um grupo de atividades de
“suporte” que complementem as atividades base. Para estas atividades adicionais, são as carac-
terísticas do projeto de software e/ou do processo adotado que definem/determinam a aplicação
ou não das mesmas. O que poderá ocorrer durante a execução do processo/projeto de software.
As atividades de suporte mais comuns são: controle e acompanhamento do projeto; administra-
ção de riscos; garantia da qualidade de software; revisões técnicas; medição; gerenciamento da
configuração de software; gerenciamento de reusabilidade; preparo e produção de artefatos de
software; etc.
2.1.2 Métodos/Práticas da Engenharia de Software
Definição de Métodos/Práticas de Engenharia de Software segundo (PRESSMAN, 2011).
As atividades base e de suporte estabelecem um plano para a efetiva prática da engenha-
ria de software. Mas a execução deste plano por si só não garante o “exercício” da Engenharia
de Software. É preciso que, aliado a execução deste plano, se aplique alguns princípios tais
como:
1. Compreender o problema (envolve as atividades de comunicação e análise)
Algumas questões que deverão serem respondidas:
• Quem são os interessados na solução do problema?
• Quais dados, funções e recursos são necessários para resolver o problema?
• É possível dividir o problema para facilitar a compreensão?
• O problema pode ser representado através de gráficos?
2. Planejar uma solução (envolve as atividades de modelagem e projeto de software)
Questões que deverão serem respondidas:
• Já se deparou com problemas similares?
23

• Existem elementos que podem ser reutilizados?
• Existem soluções aparentes e imediatas?
• É possível criar um modelo de projeto?
3. Executar o plano (geração de código)
• O código-fonte pode ser atribuído ao modelo de projeto?
• As partes componentes da solução estão corretas?
4. Examinar o resultado para ter precisão (teste e garantia da qualidade)
• É possível testar cada parte componente da solução?
• A solução produz resultados que se adequam aos dados, funções e características
necessárias?
2.1.3 Ferramentas de Software
Deﬁnição de Ferramentas de Software empregadas pela/na Engenharia de Software se-
gundo (PRESSMAN, 2001).
A camada de ferramentas possibilitará automatizar as atividades e práticas das camadas
de processos e métodos respectivamente. Permitindo, entre outras coisas, a produção/geração
de “produtos de trabalho” (modelos, documentos, dados, relatórios, formulários, etc.) que se-
rão/poderão serem empregados/utilizados para geração de outro(s) produto(s) em uma outra
etapa/subetapa com o suporte de outra(s) ferramenta(s) de software. A seguir algumas catego-
rias destas ferramentas:
Ferramentas para gerenciamento de processos; Ferramentas para modelagem de proces-
sos; Ferramentas para desenvolvimento de processos ágil; Ferramentas para planeja-
mento de requisitos; Ferramentas para desenvolvimento de casos de uso; Ferramentas
para modelagem de dados; Ferramentas para projeto de arquitetura; Ferramentas para
desenvolvimento de interface com o usuário; Ferramentas para gerenciamento de qua-
lidade; Ferramentas para gerenciamento de testes; Ferramentas para gerenciamento de
projetos; etc.
2.2 Gerência de Projetos
2.2.1 Projeto
De acordo com (PMI INC., 2013), Projeto é:
24

Projeto é um esforço temporário empreendido para criar um produto, serviço
ou resultado exclusivo. A natureza temporária dos projetos indica que eles têm
um início e um término definidos. O término é alcançado quando os objetivos
do projeto são atingidos ou quando o projeto é encerrado porque os seus ob-
jetivos não serão ou não podem ser alcançados, ou quando a necessidade do
projeto deixar de existir. Um projeto também poderá ser encerrado se o cliente
(cliente, patrocinador ou financiador) desejar encerrá-lo.
O resultado de um projeto é único e na maioria das vezes duradouro. O termo temporário
não se aplica ao resultado mas sim ao projeto por meio do qual se alcança este resultado. Cada
projeto, mesmo compartilhando certas características com outros projetos, possui suas próprias
características e portanto apresentam uma natureza exclusiva. Os projetos podem ser empre-
gados em todos os níveis organizacionais, envolver equipes compostas por um único ou vários
membros, envolver uma única/várias unidades organizacionais ou ainda várias organizações.
A execução de um projeto pode ter como resultado um produto, serviço, melhorias ou
a geração de documento. Exemplos de projetos podem envolver o desenvolvimento de pro-
duto/serviço; efetuar alterações na estrutura, processos, pessoal ou modo de uma organização;
Desenvolver, adquirir ou modificar um sistema de hardware e/ou software; Realização e registro
de uma pesquisa; Construção de um prédio, de uma planta ou uma infraestrutura; ou ainda a
implementação, melhorias de processos e procedimentos de negócios.
2.2.2 Gerência de Projeto
De acordo com (PMI INC., 2013), Gerência de Projeto é:
a aplicação do conhecimento, habilidades, ferramentas e técnicas às ativida-
des do projeto para atender aos seus requisitos. O gerenciamento de projetos
é realizado através da aplicação e integração apropriadas dos 47 processos de
gerenciamento de projetos, logicamente agrupados em cinco grupos de proces-
sos. Esses cinco grupos de processos são: iniciação; planejamento; execução;
monitoramento e controle; e encerramento.
O gerenciamento de um determinado projeto inclui: identificação dos requisitos; deter-
minar quais as necessidades das partes interessadas; estabelecimento de comunicação entre as
partes; atender os requisitos do projeto bem como de suas entregas; e equacionar as restrições
de escopo, qualidade, cronograma, orçamento, recursos e riscos inerentes a todo projeto. As
restrições de projeto estão diretamente relacionadas entre si de forma tal que a alteração em
uma delas certamente implicará em mudanças em pelo menos uma outra. Os responsáveis pelo
desenvolvimento/execução do projeto deverão ser capazes de avaliar tais situações e agir de
forma tal que se cumpra a entrega do resultado do projeto de acordo com os requisitos preesta-
belecidos.
25

2.2.3 Ciclo de Vida do Projeto
Definição de Ciclo de Vida de Projeto através da Gerência de Projetos segundo (PMI
INC., 2013).
Ciclos de vida podem ser previsíveis ou adaptativos e fornecem uma estrutura básica
para o gerenciamento de projeto ao longo de suas etapas. Nos ciclos de vidas previsíveis o
resultado/produto e entregas são estabelecidos no início do projeto e portanto eventuais mu-
danças são controladas de forma mais “rigorosa”. Já nos adaptativos o resultado/produto será
alcançado por meio de seguidas iterações cujo escopo só se conhecerá no início das mesmas.
Independentemente de tamanho e complexidade todos os projetos podem ser mapeados para a
estrutura genérica de ciclos de vida definida por: início; organização e preparação; execução; e
encerramento.
O Ciclo de Vida de um projeto são as fases pelas quais este projeto passará até a sua
conclusão. Geralmente ocorrendo de forma sequencial, mas podendo se sobrepor, as fases do
projeto são definidas de acordo com necessidades de gerenciamento organizacional, a natureza e
aplicação do projeto. As fases são delimitadas por intervalos de tempo com um início e término
definidos ou ainda através de um ponto de controle. Um projeto pode ser dividido em qualquer
número de fases sendo que cada uma representa um conjunto de atividades relacionadas de
forma lógica e cuja execução resultará em uma ou mais entregas.
Uma estrutura de fases possibilitará que um projeto seja dividido em subconjuntos lógi-
cos e dessa forma facilitará o gerenciamento. Não há uma estrutura de fases capaz de atender a
todos os projetos embora a execução recorrente de determinadas fases possa permitir o emprego
de uma determinada estrutura em detrimento de outras. A figura 3 representa a execução de um
projeto composto por uma única fase.
Figura 3 – Projeto de Fase Única
Fonte: (PMI INC., 2013)
2.2.4 Processos para Gerenciamento de Projetos
Para (PMI INC., 2013);
Esses processos garantem o fluxo eficaz do projeto ao longo da sua existência.
Abrangem as ferramentas e técnicas envolvidas na aplicação de habilidades e
26

capacidades descritas nas áreas de conhecimento.
Os processos de gerenciamento de projetos apresentam-se como elementos distintos,
mas na prática eles se sobrepõem e interagem entre si. Existe mais de uma forma para se
controlar um projeto, no entanto a utilização de processos representa um guia na aplicação
de conhecimentos e habilidades necessários ao gerenciamento do projeto. Esse emprego de
processos se dará de forma iterativa e quando necessário o processo poderá ser repetido ao
longo do projeto.
A natureza do gerenciamento de projetos exige uma inter-relação e/ou sobreposição dos
processos empregados para essa finalidade. Como demonstrado pela figura 4, os processos de
monitoramento de controle fornecem uma “base” para outros quatro grupos de processos.
Figura 4 – Processos para Gerenciamento de Projetos
Fonte: (PMI INC., 2013)
2.3 SCRUM
De acordo com (SCHWABER; SUTHERLAND, 2013a), SCRUM é:
Um framework dentro do qual pessoas podem tratar e resolver problemas com-
plexos e adaptativos, enquanto produtivamente e criativamente entregam pro-
dutos com o mais alto valor possível. um framework estrutural que está sendo
usado para gerenciar o desenvolvimento de produtos complexos desde o início
de 1990. Scrum não é um processo ou uma técnica para construir produtos; em
vez disso, é um framework dentro do qual você pode empregar vários proces-
sos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenci-
amento e desenvolvimento de produtos, de modo que você possa melhorá-las.
O Scrum adota uma abordagem iterativa e incremental objetivando a melhoria da previsibili-
dade e possibilitando, entre outras coisas, maior controle dos riscos (SCHWABER; SUTHERLAND,
2013a).
27

2.3.1 Teoria do Scrum
Definição das Teorias de fundamentação para a metodologia Scrum segundo (SCHWA-
BER; SUTHERLAND, 2013a).
As teorias empíricas para controle de processo são as teorias utilizadas na fundamenta-
ção do Scrum. O empirismo declara que o conhecimento se constrói a partir de experiências
e que as decisões deverão ser tomadas baseado neste conhecimento. O controle de processo
empíricos é apoiado por três pilares que são:
1. Transparência: Os aspectos mais importantes do processo devem estar acessíveis aos
responsáveis pelos resultados.
2. Inspeção: Muitos dos aspectos de processo devem ser inspecionados com frequência
suficiente para que as variações inaceitáveis no processo possam ser detectadas Leitão
(2010).
3. Adaptação: Quando práticas do processo saem do escopo do projeto, impossibilitando
a aceitação do resultado, os aspectos e/ou processos devem ser adaptados/ajustados o
quanto antes possível para minimizar os desvios.
2.3.2 Principais Componentes do Scrum
O Scrum consiste em time(s) do Scrum que são associados a papéis, eventos/reuniões,
artefatos e regras (SCHWABER; SUTHERLAND, 2013a). Cada componente serve a um propósito
específico e é indispensável para o sucesso do Scrum (SCHWABER; SUTHERLAND, 2013a). As
regras integram os eventos, papéis e artefatos, controlando as relações e interações entre os
mesmos (SCHWABER; SUTHERLAND, 2013a).
2.3.2.1 Time/Papéis do Scrum
Definição dos principais Time(s)/Papéis do Scrum segundo (SCHWABER; SUTHERLAND,
2013a).
Time(s) Scrum são exemplo(s) de grupo(s) auto-organizáveis e multifuncionais. Um
grupo auto-organizável é o responsável por definir a melhor forma para concluir seu trabalho
e portanto não precisa ser gerenciado por alguém fora do grupo. Um grupo multifuncional
são providos de todas as habilidades necessárias para completar seu trabalho e portanto não
dependem de pessoas de fora do grupo. O modelo de time no Scrum foi pensado para melhorar
a flexibilidade, criatividade e produtividade. O Time Scrum está associado aos Papéis do Scrum
que são:
28

• Produto Owner/Dono do Produto: é o responsável, entre outras coisas, por maximizar
o valor do resultado do projeto e do trabalho empregado pela Equipe de Desenvolvimento
Scrum.
• Equipe de Desenvolvimento do Scrum: responsáveis, entre outras coisas, pelo trabalho
que resultará em uma versão/incremento utilizável do “produto” no final de cada ciclo
Sprint.
• Scrum Master: é o responsável, entre outras coisas, por garantir que o entendimento e
aplicabilidade do Scrum.
2.3.2.2 Eventos do Scrum
Definição dos principais Eventos do Scrum segundo (SCHWABER; SUTHERLAND, 2013a).
Os eventos previamente definido pelo Scrum criam uma rotina e evitam a necessidade
de encontros não planejados pelo TS. Qualquer evento definido pelo Scrum possui uma dura-
ção mínima e máxima de tempo (eventos Time-Boxed), de forma tal que depois de iniciados
estes eventos não podem ter seus intervalos alterados. Algumas das principais características
destes eventos é tornar as práticas/processos do Scrum o mais transparentes possível para o TS,
Stakeholders e demais interessados, e possibilitar ao TS realizar inspeções e fazer adaptações
quando necessário. Os principais eventos do Scrum são:
• Sprint: é o evento/ciclo “cerne” do Scrum e um contêiner para outros eventos. É um
time-boxed com duração de um mês ou menos onde uma versão utilizável do produto
será desenvolvida. Assim que um Sprint termina um novo é inciado e o ciclo se repte até
a conclusão do projeto. Além do trabalho de desenvolvimento se dá durante o Sprint ele
também é composto pelas reuniões de Planejamento do Sprint, Reuniões Diárias, Revisão
do Sprint e Retrospectiva do Sprint.
• Reunião de Planejamento do Sprint: reunião onde o TS define o trabalho que será rea-
lizado durante o Sprint. Este evento representa um time-boxed de no máximo oito horas
para um Sprint de um mês e no caso de Sprint’s menores este tempo máximo também
diminui.
• Reunião Diária: Este evento possui um time-boxed de 15 minutos durante o qual a
EDS sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentos e
programa as tarefas para o dia seguinte.
• Revisão do Sprint: Este evento possui um time-boxed de 4 horas para um Sprint de um
mês ou um intervalo menor caso a duração do Sprint seja inferior a um mês. Nesta reu-
nião uma versão/incremento do produto será apresentada, inspecionada, avaliada e caso
29

aprovada liberada para o cliente. Destina-se a, entre outras coisas, promover entre os par-
ticipantes (TS e os Stakeholders) motivação e colaboração, e caso necessário adaptações
no BPP serão realizadas.
• Retrospectiva do Sprint: ocorre depois da RRS e antes da RPS para o próximo Sprint.
Esta é uma oportunidade para o TS inspecionar a se próprio e de planejar melhorias para
serem executadas no próximo Sprint. Possui um time-boxed de três horas para um Sprint
de um mês e intervalos menores caso o Sprint dure menos que um mês.
2.3.2.3 Artefatos do Scrum
Definição dos principais Artefatos do Scrum segundo (SCHWABER; SUTHERLAND, 2013a).
Representam o trabalho e/ou o “valor do negócio” além de permitir mais transparência
e possibilidades para inspeções e adaptações. Os principais artefatos do Scrum são:
• Backlog do Produto/Backlog Priorizado do Produto: uma lista ordenada, de acordo
com valor de negócio, de tudo aquilo que for necessário (funções, requisitos, melhorias
etc) para o desenvolvimento do produto. Esta lista é muito dinâmica, mudando constan-
temente para representar o que o produto necessita. O BPP evolui junto com o produto e
com o “ambiente” Scrum e existirá enquanto o produto existir. A figura 5 representa um
exemplo de BPP.
Figura 5 – Exemplo de Backlog Priorizado do Produto
Fonte: (LARMAN, 2004), citado por (SCHNEIDER, 2015)
• Backlog do Sprint: é um subconjunto de requisitos do BPP escolhidos para fazerem
parte do Sprint em conjunto com o planejamento de entrega do incremento do produto.
O BS é uma seleção e estimativa realizada pelo TS para determinar as funcionalidades
que devem estar presentes na próxima versão do produto e também o trabalho que será
necessário para que seja atingido este objetivo. A figura 6 representa um exemplo de BS.
30

Figura 6 – Exemplo de Backlog do Sprint
Fonte: (LARMAN, 2004), citado por (SCHNEIDER, 2015)
• Incremento/Nova Versão do Produto: é o conjunto de todos os requisitos do BP com-
pletados até o Sprint atual mais todos aqueles que já foram desenvolvidos nos Sprint’s
passados. Este incremento deve dar origem há uma nova versão do produto em condição
de ser utilizada pelo Stakeholders e portanto atendendo a uma definição de “Pronto” sob
o ponto de vista do TS.
• Burndown Chart: de acordo com (RUBIN, 2013), este gráfico é útil para acompanhar
o progresso dos esforços/trabalhos durante o Sprint, demonstrando quanto trabalho falta
para completar o Sprint além de permitir que sejam detectados possíveis desvios. O grá-
fico deve ser atualizado diariamente, durante a Reunião Diária, e a equipe deve monitorar
o andamento do projeto a cada iteração (Schneider, 2015). No BC o eixo vertical repre-
senta uma estimativa do esforço/trabalho restante em horas e o eixo horizontal representa
os dias compreendidos pelo ciclo Scrum atual. A figura 7 representa um exemplo de BC.
Figura 7 – Exemplo de Burndown Chart
Fonte: (RUBIN, 2013)
31

• Taskboard/Scrumboard: de acordo com Camargo (2013), pode ser um “painel/qua-
dro”, software ou outro tipo de “ferramenta”. É utilizado para auxiliar na “visualização”
do progresso/evolução do Sprint, possibilitando o acompanhamento das atividades pla-
nejadas para este Sprint. Deverá está acessível ao TS e como acontece para BC também
deve ser atualizado constantemente durante o Sprint (provavelmente na Reunião Diária).
A figura 8 representa um exemplo de Taskboard.
Figura 8 – Exemplo de Taskboard
Fonte: (KNIBERG, 2007) citado por (CAMARGO, 2013)
2.3.3 Visão Geral do Scrum
Visão geral da metodologia Scrum segundo (SATPATHY et al., 2016).
Para a conclusão de um projeto Scrum é necessário que se faça um esforço considerá-
vel de colaboração, entre os envolvidos, para se alcançar um novo resultado (produto, serviço
etc) que esteja de acordo com o que foi definido na Declaração de Visão de Projeto. Res-
trições de tempo, custo, escopo, qualidade, recursos, capacidade de organização, entre outras,
podem afetar um projeto dificultando seu planejamento, implementação, gerenciamento e como
consequência determinar o fracasso do mesmo. De outra forma quando se obtêm êxito no de-
senvolvimento de um produto, a partir da conclusão de um projeto, os benefícios comercias
podem ser significativos para uma organização. Por isso a importância da escolha e prática de
uma metodologia para gerência de projeto por parte das organizações.
O Scrum se tornou uma das metodologias ágeis mais populares atualmente. Isto porque
apresenta, entre outras características, alto grau de adaptação, iteratividade, rapidez, flexibili-
dade e eficiência. Foi “desenhada” de forma a permitir uma valorização do negócio deste o
início do desenvolvimento do projeto. O Scrum possibilita para as partes envolvidas a transpa-
rência na comunicação desenvolvendo um ambiente de responsabilidade coletiva e de evolução
32

contínua no progresso do projeto. Entre os fatores de maior relevância pode-se destacar o fato
que o(s) “time(s)” do Scrum são multifuncionais, auto-organizados e emponderados, e cujo tra-
balho é dividido em ciclos curtos de tempo bem definidos conhecidos como Sprints. A figura 9
exibe uma visão geral do fluxo de execução Scrum para um determinado projeto.
Figura 9 – Fluxo de Execução do Scrum para um Projeto
Fonte: (SATPATHY et al., 2016) adaptado pelo autor
Um projeto Scrum é iniciado com uma reunião, Reunião da Visão do Projeto, entre
o Time Scrum (Time Central do Scrum) e os Stakeholders (clientes, usuários, patrocinadores
etc); durante a qual é criado um plano com a Declaração de Visão do Projeto. Seguindo o
“fluxo”, o Produto Owner apoiado na DVP desenvolve o artefato Backlog Priorizado do Produto
que lista os requisitos do produto/negócio ordenados de acordo com prioridades (por exemplo
valor de negócio etc) e descritos em forma de Estórias de Usuário. Em seguida a Reunião de
Planejamento das Releases ocorre, em que TS apoiados pelo BPP farão uma revisão das suas
EU para criar o Cronograma de Planejamento da Release e definir a duração dos Sprint’s. A
duração de um Sprint é de uma a quatro semanas e envolve os integrantes do Time Scrum
trabalhando no desenvolvimento de “entregas/incrementos” e/ou em melhorias de produto com
potencial de utilização pelos clientes/usuários.
Agora os ciclos Sprint’s podem ser iniciados, cada Sprint se inicia com a Reunião de
Planejamento do Sprint durante a qual o TS, novamente apoiados no BPP, seleciona as EU de
mais alta prioridade para fazerem parte do Sprint, originando o artefato Backlog do Sprint. No
decorrer do Sprint, Reuniões Diárias de curta duração são realizadas permitindo com que os
integrantes do TS discutam/colaborem sobre o trabalho realizado e/ou dificuldades enfrentadas,
além de programar/planejar o trabalho que será realizado no dia seguinte.
Próximo ao final do Sprint uma Reunião de Revisão do Sprint é realizada, onde a Equipe
Scrum irá demonstrar para o PO e os Stakeholders os estregáveis/incremento. O PO então
avalia e caso os estregáveis atendam aos Critérios de Aceitação pré-definidos ele os aceitará.
Por fim o ciclo do Sprint será finalizado com a realização de uma outra reunião, Reunião de
Retrospectiva do Sprint, onde o TS poderá apresentar possíveis melhorias, tanto no que diz
respeito ao processo em si como também melhorias que podem ser adotadas para um “ganho”
de desempenho, e de outras questões que dizem respeito a TS. E assim novos ciclos Sprint’s se
repetem até a conclusão do projeto.
33

2.3.4 O Framework SCRUM
2.3.4.1 Principais Fundamentos/Bases do Framework Scrum
Os principais fundamentos/bases do Framework Scrum segundo (SATPATHY et al., 2016).
1. Princípios: formam o “alicerce” sobre o qual o Scrum se baseia.
2. Aspectos: devem ser empregados na execução de qualquer projeto Scrum, independente
de tamanho, complexidade etc.
3. Processos: incluem os dezenove processos do Scrum com suas respectivas entradas, fer-
ramentas e saídas.
Os princípios do Scrum não são alteráveis, devem ser seguidos a risca, enquanto que os
aspectos e processos do Scrum podem ser modificados para atender/adequar aos requisitos de
projeto e/ou organizacionais. Os princípios, aspectos e processos do Scrum constituem a base
para esta metodologia e a compreensão de suas relações são de fundamental importância para
entendimento deste framework. A figura 10 representa os “conjuntos de métodos/práticas/re-
gras” que formam a base para framework Scrum bem como das interações entre os mesmos.
Figura 10 – Fundamentação do Framework Scrum
Fonte: (SATPATHY et al., 2016)
2.3.4.1.1 Princípios do SCRUM
Os Princípios do Framework Scrum segundo (SATPATHY et al., 2016).
Os Princípios do Scrum representam os fundamentos inalteráveis/inegociáveis quando
na aplicação do framework, e podem ser utilizados em qualquer projeto de qualquer organiza-
ção. A figura 11 ilustra os seis princípios do Scrum.
34

Figura 11 – Princípios do Scrum
1. Controle de Processos Empíricos: conforme definido na seção 2.3.1, enfatiza a filosofia
central do frameowork Scrum.
2. Auto-organização: em um ambiente organizacional em que os colaboradores são auto-
organizados permite fazer com que o trabalho realizado entregue maior valor. Resultando
em uma maior satisfação, responsabilidades compartilhadas e em um ambiente inovador
e mais propício ao crescimento.
3. Colaboração: foca nas questões base do trabalho colaborativo - consciência, articulação
e apropriação.
4. Priorização Baseada em Valor: destaca um dos propósitos do Scrum que é o de maxi-
mizar a entrega de valor.
5. Time-boxing: demonstra como o tempo é considerado um fator de restrição durante todo
o projeto e como é utilizado para auxiliar a gerência e execução deste projeto.
6. Desenvolvimento Iterativo: define que o trabalho a ser realizado para se alcançar o
produto deverá ocorrer dentro de intervalos de tempo bem definidos e repetitivos e de
forma incremental. Permitindo dessa forma a gerência de eventuais mudanças e como
consequência atender as necessidades dos clientes.
35

2.3.4.1.2 Aspectos do SCRUM
Os Aspectos do Framework Scrum segundo (SATPATHY et al., 2016).
Os aspectos presentes no Scrum precisam ser evidenciados e administrados por todo o
projeto Scrum. A seguir são apresentados estes aspectos.
1. Organização: compreender os papéis e suas responsabilidades dentro de um projeto
Scrum é essencial para se alcançar o sucesso na implantação dessa metodologia. Os
papéis centrais do Scrum são obrigatórios para o desenvolvimento de produto/serviço em
um projeto Scrum e os colaboradores que os representam são os principais responsáveis
pelo sucesso do projeto. Os papéis centrais do Scrum foram definidos na seção 2.3.2.1.
2. Justificativa de Negócio: é importante que uma organização faça uma avaliação do negó-
cio antes de iniciar um projeto. Isso permite o entendimento e necessidade de negócio, e
como consequência a justificativa de viabilidade e continuidade do projeto. A justificativa
de negócio em Scrum se baseia na entrega dirigida a valor, que consiste na disponibiliza-
ção de resultados para os stakeholders o mais rápido possível durante o projeto.
3. Qualidade: no Scrum a qualidade é representada através da capacidade dos resultados
em atingir o valor de negócio esperado pelos stakeholders, e em atender aos critérios
de aceitação que foram definidos previamente. Para garantir que o projeto atenda aos
critérios de qualidade esperados um processo de melhoria contínua é adotado, permitindo
ao TS aprender com a experiência e com a participação dos stakeholders. Essas melhorias
incluem, entre outras coisas, a atualização constante do BPP para atender a eventuais
mudanças que possam ocorrer nos requisitos e na detecção o quanto antes de erros e/ou
defeitos, maximizada através da realização do trabalho realizado em ciclos de tempo
(Sprint’s).
4. Mudanças: qualquer projeto está sujeito à mudanças, e por esta razão os processos no
Scrum são projetados para aceitá-las. Organizações precisam agir de forma a maximi-
zarem os benefícios dessas mudanças e de minimizar os efeitos negativos, empregando
processos que permitam gerenciar tais mudanças e que estejam de acordo com os princí-
pios do Scrum.
5. Riscos: os riscos são definidos no Scrum como um evento ou um conjunto deles capazes
de afetar os objetivos do projeto, contribuindo para seu sucesso ou fracasso. Os riscos
que podem influenciar de forma positiva são definidos como oportunidades, já aqueles
que podem influenciar de forma negativa são identificados como ameaças ao sucesso do
projeto. A gerência dos riscos no Scrum deve iniciar junto com o projeto perdurando
durante todo o seu ciclo de vida, permitindo com que os mesmos sejam identificados,
avaliados e ações sejam tomadas o quanto antes possível.
36

2.3.4.1.3 Processos do SCRUM
Os Processos do Framework Scrum segundo (SATPATHY et al., 2016).
Os Processos do Scrum incluem as atividades/práticas aplicadas durante um projeto
Scrum e a ordem em que as mesmas são empregadas. Ao todo são dezenove processos divididos
em cinco fases conforme apresentado na figura 12.
Figura 12 – Processos do Scrum
As fases descrevem detalhadamente cada processo, destacando entradas, ferramentas/re-
cursos e saídas para cada processo, além de especificar quais destes “critérios” são obrigatórios
e quais são opcionais. A seguir são descritos os processos de cada fase e a especificação de
entradas, ferramentas e saídas obrigatórios para cada um, será realizada ao final destas fases.
• Iniciar
1. Criar a Visão do Projeto: O Caso de Negócio do Projeto é analisado na Reunião
da Visão do Projeto e a Declaração de Visão do Projeto é criada para servir como
orientação durante todo o projeto. Neste processo também se dará a identificação
do Produto Owner.
2. Identificar o Scrum Master e o(s) Stakeholder(s): de acordo com determinados cri-
térios o Scrum Master e o(s) Stakeholder(s) são identificados.
37

3. Formar o Time/Equipe Scrum: os colaboradores da Equipe de Desenvolvimento são
definidos.
4. Desenvolver os Épicos: a DVP é utilizada como base para a criação dos Épicos e
caso necessário serão realizadas reuniões com grupo de usuários.
5. Criar o Backlog Priorizado do Produto: os Épicos são refinados, processados e
priorizados para originar o BPP. Critérios de “Pronto” também são definidos.
6. Conduzir/Definir o Planejamento das Release’s: o TS analisa as Estórias de Usuário
“anexas”/presentes no BPP para criar o Cronograma de Planejamento das Release’s.
A duração do(s) cliclo(s) Sprint também é definida.
A tabela 1 a seguir define as entradas, ferramentas e saídas obrigatórios para cada pro-
cesso na fase Iniciar.
Tabela 1 – Processos da Fase Iniciar
• Planejar e Estimar
1. Criar as Estórias de Usuários: o PO cria as Estórias de Usuário juntamente com os
Critérios de Aceitação para EU. As EU devem ser projetadas de forma a permitir a
transparência e compreensão dos requisitos de cliente, para os Stakeholders. As EU
são incorporadas/”anexadas” ao BPP.
2. Aprovar, Estimar e Comprometer as EU: o PO seleciona as EU para o Sprint e o
SM juntamente com a EDS estimam os esforços para completá-las. Para finalizar a
EDS se compromete a entregar os requisitos sob EU.
3. Criar as Tarefas:as EU aprovadas, estimadas e comprometidas são divididas em
tarefas e agrupas na Lista de Tarefas. Em geral uma Reunião de Planejamento de
Tarefas acontece para este fim.
38

4. Estimar as Tarefas:a EDS na RPT estima os esforços para completar as tarefas da
LT.
5. Criar o Backlog do Sprint:o TS durante a Reunião de Planejamento do Sprint cria o
Backlog do Sprint com as tarefas a serem desenvolvidas no Sprint.
cesso na fase Planejar e Estimar.
Tabela 2 – Processos da Fase Planejar e Estimar
• Implementar
1. Criar os Entregáveis/Incrementos: a EDS desenvolve as tarefas do BS para criar os
Entregáveis. O acompanhamento do progresso dos trabalhos e atividades é realizado
através do Scrumboard/Taskboard.
2. Conduzir a Reunião Diária: momento utilizado pela EDS para informarem-se entre
se sobre suas atividades, progressos e quaisquer impedimentos, além de deﬁnir o
que será realizado no dia seguinte.
3. Reﬁnamento do Backlog Priorizado do Produto: o BPP é constantemente atualizado
e mantido. Uma Reunião de Revisão do BPP pode ser realizada para que eventuais
mudanças e atualizações no BPP possam ser debatidas e se for o caso incorporadas
ao BPP.
cesso na fase Implementar.
39

Tabela 3 – Processos da Fase Implementar
• Revisão e Retrospectiva
1. Convocar o Scrum de Scrums: os TS são convocados para a Reunião do Scrum de
Scrum’s, em intervalos preestabelecidos. Relevante apenas para grandes projetos.
2. Demonstrar e Validar o Sprint:na Reunião de Revisão do Sprint a EDS apresenta,
para PO e para os Stakeholders, os entregáveis/incrementos desenvolvidos durante o
Sprint. O PO então avalia os entregáveis e caso sejam aprovados e/ou aceitos então
uma versão utilizável do produto poderá ser disponibilizada aos Stakholders.
3. Retrospectiva do Sprint: o SM junto com a EDS se reúnem na Reunião de Retros-
pectiva do Sprint para discutir sobre lições aprendidas no Sprint. Estas informações
são documentadas e poderão serem utilizadas nos próximos Sprint’s.
cesso na fase Revisão e Retrospectiva.
Tabela 4 – Processos da Fase Revisão e Retrospectiva
• Release
1. Envio de Entregáveis: os Entregáveis/Incrementos aprovados/aceitos pelo PO são
disponibilizados aos Stakholders e um acordo formal documenta o sucesso do Sprint.
40

2. Retrospectiva do Projeto: os Stakholders e o TS se reúnem para fazer uma retros-
pectiva do projeto e identiﬁcar, documentar e internalizar lições aprendidas.
cesso na fase Release.
Tabela 5 – Processos da Fase Release
41

3 FUNDAMENTAÇÃO TEÓRICA PARA EA/JE
Neste capítulo será apresentada uma análise teórica sobre parte da literatura existente
para a metodologia de Ensino-Aprendizagem bem como de suas aplicações por meio de jogos,
conhecidos como Jogos Educacionais, como recursos didáticos.
3.1 Ensino-Aprendizagem
De forma resumida a aprendizagem pode ser definida como:
- são conhecimentos adquiridos pelos humanos que refletem em mudanças per-
sistentes no desempenho e no potencial dos mesmos e deve surgir como um
resultado da experiência e interação dos aprendizes com o mundo, segundo
(DRISCOLL, 2004) - traduzido.
- é o ato de adquirir, modificar e/ou reforçar novos conhecimentos, comporta-
mentos, habilidades, valores ou preferências e pode envolver a sintetização de
diferentes tipos de informação, segundo (WIKIPEDIA, 2016c) – traduzido.
- tem como finalidade ajudar a desenvolver nos indivíduos as capacidades
que os tornem capazes de estabelecer uma relação pessoal com o meio em
que vivem (físico e humano), servindo-se para este efeito, das suas estrutu-
ras sensório-motoras, cognitivas, afetivas e linguísticas, segundo (QUARESMA,
2016).
O ensino, também de forma resumida, é definido como:
- é uma forma sistemática de transmissão de conhecimentos utilizada pelos hu-
manos para instruir e educar seus semelhantes, segundo (WIKIPEDIA, 2016d).
- Ensinar define-se por obter aprendizagem do aluno e não pela intenção (ou
objetivo) do professor ou por uma descrição do que ele faz em sala de aula.
A relação entre o que o professor faz e a efetiva aprendizagem do aluno é
o que, mais apropriadamente, pode ser chamado de ensinar, segundo (KUBO;
BOTOMé, 2001).
De acordo com Lino (2007), o processo ensino-aprendizagem na educação pode ser
definido pela composição de duas vertentes diferentes mas que se complementam: de um lado
o educador - aquele que detém o conhecimento e o responsável por transmiti-lo; do outro o
aprendiz que está ávido por novos conhecimentos. Ainda segundo Lino (2007), este é um
processo que está em constante transformações assim como a natureza dos componentes base
neste processo.
Segundo (CROSS, 1987), para se alcançar um aprendizado de excelência é necessário
que os instrutores estejam cientes do que eles podem fazer para que o ensino seja transmitido
de tal forma que o conhecimento a ser captado/assimilado possibilite maximar o aprendizado.
O que os instrutores podem fazer para tornar possível/viável este nível de aprendizado, ainda
segundo (CROSS, 1987), é:
42

• Compreender que grande parte dos estudos sobre ensino consideram que os estudantes
aprendem mais/melhor quando os mesmos são/estão envolvidos de forma ativa no pro-
cesso de ensino-aprendizagem; o que se pode conseguir através de abordagens práticas
de ensino.
• Em geral o que o estudante pratica ele aprende; então o tempo/esforço gasto para se ensi-
nar deve ser percebido pelo instrutor como consequência/resultado do seu desejo/vontade
de ensinar.
• Quando os instrutores definem que os objetivos a serem alcançados no processo de ensino-
aprendizagem deve ser elevado, provoca no desempenho dos estudantes, em geral, uma
expectativa no sentido de que os mesmos possam cumprir tais níveis de exigência.
Mas (CROSS, 1987) observa que, apesar de anos de pesquisa confirmarem que os fatores citados
podem contribuir de forma significativa para o aprendizado, outros estudos demonstram que
não existe um sentido comum a respeito da importância/eficácia de tais práticas no processo de
ensino-aprendizagem como um todo.
Para (QUARESMA, 2016), ao longo do tempo o processo de ensino-aprendizagem tem
sido qualificado em diferentes formatos, antes se enfatizava mais o papel do educador como
transmissor do conhecimento, agora os conceitos sobre este processo são concebidos de forma
sistêmica. Onde o ensino-aprendizagem se caracteriza como parte de um todo. Ainda de acordo
com (QUARESMA, 2016), reflexões sobre o atual processo permitem perceber um “movimento
de ideias de diferentes correntes teóricas sobre a profundidade do binômio ensino e aprendi-
zagem”. Dentre os elementos relacionados por tais mudanças destacam-se os estudos da atual
Psicologia sobre este processo, induzindo questões sobre como se dá a prática da educação
atualmente e uma conceitualização do processo ensino-aprendizagem para os tempos atuais
(QUARESMA, 2016).
Segundo (DRISCOLL, 2004), as teorias sobre aprendizagem concentram-se em descrever
como se desenvolve os processos de aprendizagem. Tais definições se caracterizam como um
dos principais objetivos para estas teorias e qualquer conhecimento originado a partir de tais de-
finições e passível de aplicação, são meras descobertas do acaso (DRISCOLL, 2004). Alguns dos
estudos, também responsáveis por esta estruturação dos processos de aprendizagem, refletem
sobre as implicações das teorias de aprendizagem sobre o ensino (DRISCOLL, 2004).
Qualquer evento que objetiva facilitar a aquisição de algum conhecimento, habilidade,
estratégias, atitudes, etc; por parte dos aprendizes, pode ser caracterizado como uma forma de
instruir/ensinar (DRISCOLL, 2004). Os aprendizes podem ser crianças, jovens ou pessoas mais
velhas e o ambiente onde o processo de ensino-aprendizagem se dará, poderá ser um ambiente
formal, escolar, de trabalho ou em público; já os responsáveis por instruir/ensinar poderão ser
professores, instrutores ou designers instrucionais etc; estes últimos sendo responsáveis por
desenvolver projetos instrucionais a partir de um Design Instrucional (DRISCOLL, 2004).
43

3.1.1 Design Instrucional
De acordo com (FILATRO, 2004) citado por (BRAGA, 2015), o Design Instrucional é:
a ação institucional e sistemática de ensino, que envolve o planejamento, o
desenvolvimento e a utilização de métodos, técnicas, atividades, materiais,
eventos e produtos educacionais em situações didáticas específicas, a fim de
facilitar a aprendizagem humana a partir dos princípios de aprendizagem e
instrução conhecidos.
De acordo com (E-LEARNING, 2016b), o Design Instrucional é definido como sendo
um processo sistemático de “tradução” dos princípios/fundamentos do ensino-aprendizagem no
planejamento de “materiais” para aplicação no processo de ensino-aprendizagem. As “raízes”
do DI tiveram origem na ciência da psicologia cognitiva e comportamental, que dizem respeito a
pesquisas educacionais/ensino e as teorias de ensino-aprendizagem para o desenvolvimento/im-
plementação de estratégias/processos de ensino (E-LEARNING, 2016b). Este é um processo em
que se emprega, de forma sistemática, as teorias de ensino-aprendizagem com objetivo de obter
um ensino de qualidade; o que requer a realização de análises das necessidades e objetivos de
aprendizagem, com consequente desenvolvimento e distribuição de “sistemas” adequados a tais
necessidades (E-LEARNING, 2016b).
Segundo (GONçALVES, 1993) citado por Schneider (2015), Unidades Instrucionais po-
dem “ser um curso, um exercício, uma aula, um jogo, um evento onde a aprendizagem é in-
fluenciada pelas interações entre o aluno, o professor e os materiais da aula”. As UI podem
ser, sistematicamente, planejadas, desenvolvidas e avaliadas segundo a descrição/estrutura dos
processos de DI’s, segundo PIAZZA (2012) citado por Schneider (2015).
De acordo com (MOLENDA, 2003) citado por Camargo (2013), o ISD (Instrucional Sys-
tem Development) define um conjunto de modelos baseados no processo de DI e são utilizados
para o desenvolvimento de “plataformas educacionais”. Através de modelos ISD’s o desenvol-
vimento de uma UI é realizado em fases, com a fase de avaliação ocorrendo, simultaneamente,
em cada uma das outras quatro, segundo (MERRIENBOER, 1997) citado por Camargo (2013),
Schneider (2015). Os ISD’s são estruturados de acordo com o padrão ADDIE – Analysis, De-
sign, Development, Implementation and Evaluation – segundo (E-LEARNING, 2016b).
3.1.2 O Padrão/Modelo ADDIE
De acordo com (WIKIPEDIA, 2016a), ADDIE é um framework que define processos ge-
néricos utilizados para o desenvolvimento de projetos instrucionais/ensino, representando guias
descritivos para elaboração de “ferramentas” de apoio e de treinamentos. Segundo (BRAGA,
2015), ADDIE, acrônimo em inglês para Analyze (Analisar), Design (Projetar), Develop (De-
senvolver), Implement (Implementar) and Evaluate (Avaliar), “é um paradigma de desenvolvi-
mento de produtos em geral, mas tem sido muito aplicado para um tipo específico de produto
44

que são os materiais instrucionais”. De acordo com Savi (2011), o ADDIE é uma metodologia
utilizada para definir um público-alvo, “levantar” os “requisitos” para este público, projetar e
desenvolver uma solução e avaliar os resultados coletados a partir da aplicação da solução. A
figura 13, a seguir, exibe as fases do modelo e suas possíveis relações.
Figura 13 – Fases do modelo ADDIE
Fonte: (E-LEARNING, 2016a), citado por (CAMARGO, 2013)
A seguir cada uma das fases do padrão ADDIE serão descritas segundo (CLARK, 1995;
FILATRO, 2008; INTULOGY, 2016) citados por Savi (2011).
Análise
Na fase de análise são identificadas as deficiências educacionais a serem
sanadas no público-alvo, são levantados os requisitos de aprendizagem e conse-
quentemente metas e objetivos de ensino-aprendizagem são definidos. Procura-se
caracterizar o público-alvo através de identificação de conhecimentos, habilidades
e deficiências. Estes levantamentos/pesquisas são realizados por meio de entrevis-
tas e/ou questionários através de e-mail’s, telefone ou presenciais. Como resultado
desta fase é gerado um “documento” com informações dos resultados dos levanta-
mentos/pesquisas realizados e com as metas e objetivos que foram definidos.
Projeto
Na fase de projeto determina-se como ficará o “recurso”/UI depois de pro-
duzido. Será definida sua estrutura, a sequência em que o conteúdo será apresen-
tado, etc; são identificadas as estratégias e atividades de ensino para se alcançar os
objetivos e metas de aprendizagem. Esta fase é composta, basicamente, por três
subetapas que são:
• Planejamento do Projeto Instrucional: define-se como o “material” e/ou con-
teúdo a ser criado e utilizado deverá ser estruturado e sequenciado para a
45

apresentação do mesmo. São definidos métodos e estratégias para a aplicação
do conteúdo e para a avaliação da aprendizagem por parte dos aprendizes.
• Seleção do Formato do Curso: no caso de a UI se tratar de um curso, o for-
mato do mesmo deverá ser definido bem no começo da etapa de projeto, pois
este formato impactará de forma significativa as características presentes no
documento de projeto.
• Documento de Projeto Instrucional: possui uma visão geral do projeto instru-
cional. Com informações de como a UI deverá ser construída, descrevendo a
abordagem de aprendizagem adotada, os recursos de mídias a serem utiliza-
dos, os objetivos, exercícios, atividades e avaliações.
Como resultado desta fase o documento de Projeto Instrucional, citado anterior-
mente, será gerado onde poderão, também, está presentes “script’s” e narrativas.
Desenvolvimento
Na fase de desenvolvimento são criados e organizados os materiais/conteú-
dos. O desenvolvimento do conteúdo deve está de acordo com o que foi especifi-
cado no documento da fase de projeto, e sempre procurando atender as necessidades
e objetivos identificados na fase de análise. No caso de uma UI que representa um
produto de software, por exemplo um Jogo Educacional, será nesta fase que se dará
o processo de desenvolvimento de software.
Implementação
Na fase de implementação ocorre a “execução”/aplicação da UI produzida.
Os aprendizes tem acesso aos recursos produzidos para realizarem as atividades
que foram definidas no projeto instrucional. No caso de UI’s como sendo produtos
de software e/ou hardware, os aprendizes deverão ser orientados/treinados sobre
como utilizar o recurso.
Avaliação
Na fase de avaliação são utilizados questionários, entrevistas etc, para co-
leta de dados que permitirão medir a eficácia da solução educacional. São avaliados
a aprendizagem do público-alvo e o projeto instrucional para determinar se os ob-
jetivos educacionais e necessidades de aprendizagem estão sendo atendidos. Para a
avaliação da aprendizagem pode ser utilizada a Taxonomia de Bloom, que “foi cri-
ada dentro de um contexto acadêmico na década de 1950 com o objetivo de apoiar
os processos de projeto e avaliação educacional” (CHAPMAN, 2009) citado por Savi
(2011). A seguir será feita uma breve introdução a respeito da taxonomia de Bloom.
46

3.1.3 Taxonomia de Bloom
A taxonomia de Bloom foi estruturada de forma a possibilitar sua utilização para o
planejamento, projeto e avaliação do aprendizado e de treinamentos (BLOOM, 1984; CHAPMAN,
2009) citados por Savi (2011). Aborda os domínios cognitivo, psicomotor e afetivo Camargo
(2013), mas é mais difundida/conhecida e aplicada pelos “trabalhos” relacionados ao domínio
cognitivo Savi (2011). No domínio cognitivo a efetivação da aprendizagem (conhecimentos/ha-
bilidades etc) é medida através de níveis de complexidade, que determina que o avanço para o
próximo nível - para se obter o conhecimento relativo ao próximo nível – só será possível se
os requisitos (conhecimentos, habilidades etc) relativos ao nível anterior já foram alcançados
Camargo (2013). A figura 14, a seguir, ilustra a taxonomia de Bloom para o domínio cognitivo.
Figura 14 – Categorias do domínio cognitivo segundo a taxonomia de
Bloom (1956)
Fonte: (CAMARGO, 2013)
3.2 Jogos Educacionais/Jogos “Sérios”
Algumas definições para jogo:
- qualquer competição (jogo) entre os adversários (jogadores) que operam sob
restrições (regras) para um objetivo (vitória ou lucro), segundo (ABT, 1987)
citado por (BATTISTELLA; WANGENHEIM; FERNANDES, 2014).
- uma competição, física ou "mental", jogada de acordo com regras específi-
cas, com um objetivo de diversão ou recompensa aos participantes, segundo
(WIKIPEDIA, 2016e) – traduzido.
Algumas definições para jogos educacionais ou jogos “sérios”:
- jogos que não possuem como principal propósito o entretenimento, o prazer
ou a diversão”, segundo (MICHAEL; CHEN, 2005) citado por (DJAOUTI et al.,
2011).
- uma competição "mental", jogada com o computador, que usa o entreteni-
mento e acontece de acordo com regras específicas que controlam o progresso
(do jogador), podendo simular, por exemplo, um treinamento empresarial, uma
atividade educacional, um treinamento na área da saúde, um treinamento poli-
cial ou a comunicação de objetivos estratégicos, segundo (WIKIPEDIA, 2016b)
– traduzido.
47

- estes jogos possuem um propósito explícito e são cuidadosamente pensa-
dos para ensinar, e não ser jogado simplesmente para diversão, segundo (ABT,
1987) citado por (WANGENHEIM, 2012).
De acordo com (MA; OIKONOMOU; JAIN, 2011), a recente “onda” a respeito de jogos
“sérios” teve como parte de sua origem, os vídeo games, que introduziram o conceito de jogos
projetados para outros propósitos além do entretenimento; e dentre as possíveis áreas de apli-
cação para estes destaca-se a educacional, engenharia, saúde, militar, planejamento de cidades,
produção e “resposta à crises”. Para os jogadores esse tipo de jogo representará uma nova forma
de aprender/aperfeiçoar conhecimentos e habilidades, promover atividades físicas, suporte ao
desenvolvimento social/emocional, e o tratamento de diferentes tipos de doenças psicológicas e
físicas entre outras (MA; OIKONOMOU; JAIN, 2011). Recentes estudos, considerando diferentes
contextos, tem demonstrado os benefícios de se utilizar os jogos com fins além do entreteni-
mento. Vantagens como baratos/acessíveis, amplamente disponíveis e divertidos, combinadas
com abordagens educacionais e treinamentos podem fornecer um poderoso recurso para transfe-
rência/aquisição do conhecimento em quase todos os domínios de aplicação (MA; OIKONOMOU;
JAIN, 2011).
De acordo com (DEMPSEY; RASMUSSEN; LUCASSEN, 1996) citado por (BATTISTELLA;
WANGENHEIM; FERNANDES, 2014), os jogos educacionais são “projetados para ensinar as pes-
soas acerca de um determinado assunto, expandir conceitos, reforçar o desenvolvimento, ou
auxiliá-las exercitando uma habilidade ou buscando uma mudança de atitude enquanto jogam”.
Os jogos utilizados com fins educacionais definem como seu principal resultado a aprendiza-
gem; procurando balancear aspectos relacionados ao assunto/tema de aprendizagem, com os
aspectos relacionados a jogabilidade e com a capacidade do jogador/aprendiz em assimilar os
conceitos sobre este assunto e utilizá-los em situações reais (BATTISTELLA; WANGENHEIM; FER-
NANDES, 2014). Quando o aprendizado é obtido através de jogos ele é adquirido de uma forma
mais ativa, possibilitando ao aprendiz se tornar um agente mais participativo neste processo e
com isso aumentando/melhorando sua capacidade de compreensão a respeito do conteúdo ensi-
nado, segundo (BONWELL; EISON, 1991) citado por (BATTISTELLA; WANGENHEIM; FERNANDES,
2014).
O desenvolvimento de um jogo é uma atividade desafiadora e necessita de métodos cria-
tivos que sejam empregados de forma sistemática. As atividades desenvolvidas por construtores
de jogos envolvem, entre outras, a definição de regras que estimulem/motivem o jogador e que
permitam a progressão do mesmo durante o jogo; e a partir de tais características (regras, moti-
vação e progressão) os construtores ainda precisarão combinar “desafio, competição e interação
para tornar o jogo divertido” de se jogar, segundo (BATTISTELLA; WANGENHEIM; FERNANDES,
2014). Uma maneira de fazer/garantir com que um jogo a ser desenvolvido seja considerado
educativo e portanto passível de utilização como recurso de ensino, é que este seja desenvolvido
a partir de um Design Instrucional (BATTISTELLA; WANGENHEIM; FERNANDES, 2014). As tare-
fas relativas a um processo de DI (ajustadas à realidade de um jogo) são responsáveis por definir
o conteúdo educacional do jogo, enquanto que o “design de jogo” para o jogo, pode ser defi-
nido a partir de um outro processo, considerando-se características específicas de jogabilidade
48

e desenvolvimento do jogo Savi (2011).
Os jogos educacionais podem ser digitais (computador, consoles, dispositivos móveis
etc) ou não digitais (tabuleiro, cartas etc) e podem ser empregados, como recurso educacional,
nos diferentes níveis do processo de ensino-aprendizagem Savi (2011). Ainda segundo Savi
(2011), algumas das vantagens a serem destacadas com a utilização dos JE são:
• possibilidade do aprendizado com base na experiência;
• potencialidade de um aprendizado mais efetivo através de prática;
• desenvolve competências cognitivas;
• estimula e aumenta a capacidade de pensamentos mais complexos;
• permitem um aprendizado mais eﬁcaz e pessoal;
• “jogos são eﬁcazes para reforçar e revisar informações das aulas tradicionais por possibi-
litarem que alunos apliquem na prática o que aprenderam”;
• os jogos possibilitam a diversão, competição, cooperação e disciplina ao mesmo tempo
que se aprende;
• envolve o “trabalho” em equipe e podem aprimorar esta capacidade;
• pode ser uma ferramenta muito útil como meio de avaliação.
No próximo capítulo serão abordados os jogos educacionais voltados para o ensino-
aprendizagem na área de ES/Scrum.
49

4 ANÁLISE SOBRE JE PARA O EA DE ES/SCRUM
Neste capítulo são apresentados alguns exemplos de jogos educacionais, existentes na
literatura, para auxiliar no processo de ensino-aprendizagem de ES/SCRUM. Em especial serão
abordados JE direcionados para ensino/prática da metodologia Scrum.
4.1 JE para o Ensino-Aprendizagem de ES
Nesta seção são abordados os JE voltados para o ensino-aprendisagem de Engenharia
de Software. Foram analisados e “levantadas” informações como: uma descrição resumida do
jogo; objetivos e níveis de aprendizagem; público-alvo; resultados de avaliações etc.
Tabela 6 – Informações sobre o jogo SimSE
Jogo
SimSE
Captura de Tela
Descrição Resumida O jogador assume o papel de gerente de projetos e será responsável por gerenciar uma equipe de desenvolvedores.
Juntos deverão completar com sucesso as tarefas de engenharia de software que foram atribuídas a eles. Dentre as
tarefas pode-se citar: o emprego de um ciclo de vida completo que vai da concepção/início até a entrega de um produto
de software, atividades especíﬁcas (simples/menores) do processo de software (como revisão de código) ou algum
outro aspecto de processo de engenharia de software.
Fonte: (NAVARRO, 2006)
50

Tabela 6 - Informações sobre o jogo SimSE
Jogo
SimSE
Objetivos de
Aprendizagem
Ensinar Processos de Engenharia de Software
Feedback ao Jogador Durante e após o jogo
Nível de Aprendizagem
segundo a Taxonomia de
Bloom
Nível 3 - Aplicação (de acordo com a ﬁgura 14)
Público-Alvo Estudantes de Processos de Engenharia de Software/Gerência de Projetos
Modo de Interação Único Jogador/Individual
Idioma Disponível Inglês
Duração Aproximadamente 2 horas
Resultados de Avaliações Quatro testes foram realizados: teste piloto, teste em classe, teste comparativo e estudo observacional. Sendo que no
teste em classe alguns dos resultados obtidos, com uma nota variando de 1 até 5, foram:
- jogo divertido = 2,5 de média;
- reforça a teoria vista em sala = 3,2 de média;
- grau de diﬁculdade = 3.3 de média;
- ensina novos conhecimentos sobre processos = 2.4 de média;
- de forma geral ensina processos da ES = 3 de média.
Linguagem Java
Tipo de Jogo Digital
Gênero/Categoria do Jogo Simulação
Plataforma Windows e Linux
Referência N/A
Fonte: (NAVARRO, 2006)
51

Tabela 7 – Informações sobre o jogo X-MED
Jogo
X-MED
Captura de Tela
Descrição Resumida O jogador assume o papel de analista de medição e executará tarefas que permitirão sua avaliação e medição. O
jogo possibilita a “criação”/deﬁnição (planejamento e execução) de um programa de medição para aplicação em um
ambiente ﬁctício (uma pequena empresa de software que deseja implantar um programa de medição para auxiliar no
gerenciamento de seus projetos de software).
Objetivos de
Aprendizagem
Ensinar Processos de Medição e Análise de Software
Bloom
Público-Alvo Estudantes de Processos de Medição e Análise de Software
Idioma Disponível Português
Duração Aproximadamente 2 horas
Resultados de Avaliações N/A
Linguagem N/A
Fonte: (LINO, 2007)
52

Tabela 7 - Informações sobre o jogo X-MED
Jogo
X-MED
Plataforma N/A
Referência N/A
Fonte: (LINO, 2007)
Tabela 8 – Informações sobre o jogo TestEG
Jogo
TestEG
Captura de Tela
Descrição Resumida O jogo é composto por dois módulos um de Administrador e o outro de Jogador/Usuário. Ao acessar o sistema a
tela de login é apresentada e o user se identifica, de acordo com seu perfil ele será direcionado para um ou outro
módulo. No módulo de administrador pode-se cadastrar novos administradores, usuários/jogadores e perguntas etc.
No módulo de jogador, o mesmo assume o papel de Gerente de Teste em um ambiente fictício (uma pequena empresa
de desenvolvimento de software), e será o responsável por gerenciar uma equipe de testes. Durante o jogo o gerente
de teste realiza tarefas como solucionar dúvidas (auxiliando nas tarefas de testes), realizar treinamentos e verificar
desempenho dos integrantes da equipe de teste. O gerente de teste poderá ainda se qualificar melhor a respeito das
atividades inerentes a um gerente de testes, através da leitura de conteúdo direcionado para estes propósitos.
Fonte: (OLIVEIRA, 2013)
53

Tabela 8 - Informações sobre o jogo TestEG
Jogo
TestEG
Objetivos de
Aprendizagem
Ensinar Processos de Testes de Software
Bloom
Público-Alvo Estudantes de Processos de Testes de Software
Duração Aproximadamente 10 minutos
Resultados de Avaliações 52 jogadores/avaliadores responderam a avaliação e as conclusões foram as seguintes:
- 40 acharam o design da interface adequado;
- 25 disseram que não houve diﬁculdades para entender o jogo;
- 40 acharam o conteúdo educacional abordado útil;
- 31 responderam que não acham que o jogo possui muitas informações;
- 32 responderam que aprenderam mais com o jogo.
Linguagem Engine de Jogos - Unity3D
Plataforma N/A
Referência N/A
Fonte: (OLIVEIRA, 2013)
4.2 JE para o Ensino-Aprendizagem de SCRUM
A seguir são apresentados alguns exemplos de jogos educacionais para auxiliar no pro-
cesso de ensino-aprendizagem sobre a metodologia ágil Scrum. Foram analisados e “levanta-
das” informações como: uma descrição resumida do jogo, objetivos e níveis de aprendizagem,
público-alvo, resultados de avaliações etc.
54

Tabela 9 – Informações sobre o jogo SCRUM-Scape
Jogo
SCRUM-Scape
Captura de Tela
Descrição Resumida O jogo se “passa” em um prisão contendo 3 repartições e que remete ao período medieval, sendo cada uma dessas
repartições contendo suas respectivas celas. Cada repartição representa um nível de complexidade do jogo e cujo
conteúdo educacional presente representa um dos conceitos básicos do Scrum. Para vencer o jogador precisará passar
por estes 3 níveis do jogo deﬁnidos como missões a serem cumpridas pelo jogador. Na primeira missão será abordados
os papeís do Scrum, na segunda as reuniões do Scrum e na terceira os artefatos do Scrum.
Objetivos de
Aprendizagem
Ensinar conceitos básicos (Papéis, Artefatos e Reuniões) sobre a Metodologia Ágil Scrum
Bloom
Nível 2 - Compreensão (de acordo com a ﬁgura 14)
Público-Alvo Estudantes da Metodologia Ágil Scrum
Pré-requisitos do
Público-alvo
Possuir algum conhecimento básico sobre Gerência de Projetos e Metodologia Ágil Scrum
55

Tabela 9 - Informações sobre o jogo SCRUM-Scape
Jogo
SCRUM-Scape
- com relação a motivação foi constatado resultados positivos em todos os aspectos avaliados, com destaque para
relevância e atenção durante o jogo;
- com relação a experiência obtida com o jogo também foram constados resultados positivos em todas as dimensões
avaliadas, com destaque para diversão e imersão;
- com relação ao aprendizado adquirido com o jogo os avaliadores, de forma geral, também responderam positivamente,
sendo que aproximadamente 70% deles disseram ter aprendido mais com jogo;
- por ﬁm foi avaliado o nível de conhecimento que se atingiu com o aprendizado adquirido e 14 dos 17 participantes
responderam positivamente, indicando que este nível subiu pelo menos 1 ponto.
Linguagem Engine de Jogos - RPG Maker
Gênero/Categoria do Jogo RPG - Role Playing Game
Plataforma N/A
Referência N/A
Tabela 10 – Informações sobre o jogo SCRUM’ed
Jogo
SCRUM’ed
Captura de Tela
Fonte: (SCHNEIDER, 2015)
56

Tabela 10 - Informações sobre o jogo SCRUM’ed
Jogo
SCRUM’ed
Descrição Resumida O jogador assume o papel de Scrum Master e será o responsável por auxiliar a Equipe Scrum em suas atividades durante
o Sprint. Entre as atividades do jogador/Scrum Master etão a de “remover” os impedimentos que são apresentados pelos
membros da Equipe Scrum. O jogo se “passa” em um senário medieval representados por um castelo e um palácio.
No castelo o Time Scrum está reunido e é neste local onde acontecem as reuniões e os artefatos são criados. Quando
solicitados o Time Scrum se desloca até o palácio e chegando lá o jogador precisa remover alguns “impedimentos”
que atrapalham a execução de tarefas por parte da equipe. Quando a equipe termina suas tarefas o time retorna para o
castelo. Caso o jogador consiga remover todos os impedimentos até o final da Sprint (retorno ao castelo), o Produto
Owner aprovará a Sprint e consequentemente o jogador vence o jogo, pois conseguiu completar suas “tarefas” no papel
de Scrum Master durante a Srprint.
Objetivos de
Aprendizagem
Ensinar conceitos básicos (Papéis, Artefatos e Reuniões) sobre a Metodologia Ágil Scrum
Bloom
Público-Alvo Estudantes da Metodologia Ágil Scrum
Pré-requisitos do
Público-alvo
- com relação a motivação foi constatado resultados positivos em todos os aspectos avaliados, com destaque para a ques-
tão que perguntava se o conteúdo educacional do jogo estava de acordo com conceitos já “vistos” pelos participantes,
e 95
- com relação a experiência obtida com o jogo também foram constados resultados positivos e outros nem tanto, com
destaque para a questões como desafiador (boa parte concorda) e cooperação, competição, diversão e interação (boa
parte não concorda);
- com relação ao aprendizado adquirido com o jogo, mais de 50
- por fim foi avaliado o nível de conhecimento que se atingiu com o aprendizado adquirido após o jogo e, no geral, os
participantes responderam que o conhecimento deles melhorou a respeito do assunto abordado, indicando que o nível
subiu pelo menos 1 ponto.
Linguagem Engine de Jogos - Unity
Gênero/Categoria do Jogo RPG - Role Playing Game
Plataforma Windows
57

Tabela 10 - Informações sobre o jogo SCRUM’ed
Jogo
SCRUM’ed
Referência N/A
Tabela 11 – Informações sobre o jogo Scrum Game
Jogo
Scrum Game
Captura de Telas do
Módulo Administrador
Fonte: (GKRITSI, 2011)
58

Tabela 11 - Informações sobre o jogo Scrum Game
Jogo
Scrum Game
Captura de Telas do
Módulo Jogador/User
59

Jogo
Scrum Game
Descrição Resumida O jogo é composto por dois módulos um de Administrador e o outro de Jogador/Usuário. Ao acessar o sistema a tela de
login é apresentada e o user se identifica, de acordo com seu perfil ele será direcionado para um ou outro módulo. No
módulo de administrador pode-se modificar projetos de softwares, criar membros para a equipe scrum, novas tarefas,
possíveis alternativas de respostas para a Daily Scrum etc. No módulo de jogador o mesmo assumirá o papel de Scrum
Master e de início deverá escolher o projeto de software que deseja participar. Em seguida deverá montar a Equipe
Scrum e auxiliá-la em suas atividades, garantido que seus membros executem suas tarefas em acordo com a metodologia
Scrum. Como parte da reunião de planejamento da release, os jogadores são solicitados a estimarem o esforço e duração
de cada tarefa para o projeto que estão participando e registrando esses dados no Produto Backlog. Para o Produto
Backlog a abordagem adotada é similiar. A reunião Daily Scrum é considerada uma das mais importantes para este
jogo, pois será onde o jogador solicitará a equipe scrum 3 questões, irá respondê-las e sua pontuação será armazenada.
A qualquer momento o jogador poderá acessar o Burndown Chart para monitorar o progresso da equipe e estimar
quando o produto final será entregue. Na reunião de Review Meeting o Produto Owner avaliará se a release está de
acordo com o requisitos. Para isso será considerado o perfil dos integrantes da equipe ou seja, quanto mais qualificado
mais será a cobrança por parte do Produto Owner. Caso seja aprovado a release o jogador pode passar para o próximo
sprint do contrário ele deverá repetir o sprint.
Objetivos de
Aprendizagem
Ensinar conceitos/práticas da Metodologia Ágil Scrum com ênfase nas atividades exercidas pelo papel do Scrum Master
Bloom
Público-Alvo Estudantes de Metodologia Ágil Scrum/Gerência de Projetos
Pré-requisitos do
Público-alvo
Idioma Disponível Inglês
Duração Depende de cada Projeto (qtd de sprints, duração de tarefas etc)
60

Jogo
Scrum Game
- 60% acreditam não ser necessário possuir algum conhecimento prévio sobre o jogo para conseguir jogá-lo;
- 86% aﬁrmaram que aprenderam mais sobre o Scrum após jogar o Scrum Game;
- 91% acreditam que este jogo poderia ser usado como material de apoio (prática) a teoria sobre Scrum abordado em
sala de aula;
- 95% acham que aprenderiam melhor/mais, sobre Gerência de Projeto, se este jogo fosse utilizado como recurso de
ensino-aprendizagem para esta disciplina/conteúdo;
- 75% acharam o jogo divertido de se jogar;
- esta versão do sistema recebeu uma nota 8 de média num total de 10, quando avaliado de forma geral (interface,
navegabilidade etc).
Linguagem PHP
Plataforma Computador/Web/Windows
Referência http://users.ecs.soton.ac.uk/ag2006/COMP6029/
61

Tabela 12 – Informações sobre o jogo Scrumming
Jogo
Scrumming
Captura de Tela
Descrição Resumida O jogo é composto por dois módulos um de Administrador e o outro de Jogador/Usuário. Ao acessar o sistema a tela
de login é apresentada e o user se identifica, de acordo com seu perfil ele será direcionado para um ou outro módulo. O
jogo permite a simulação de um sprint em um único hipotético projeto, não é possível salvar o contexto de um jogador e
o jogo/sistema é quem se encarrega de alocar os recursos (estimar) para execução das atividades/tarefas. No módulo de
administrador pode-se adicionar novos membros para a equipe scrum, incluir e excluir novas atividades/tarefas para o
projeto etc. No módulo de jogador o mesmo assumirá o papel de Scrum Master e realizará atividades como: configurar
o projeto a ser simulado (adicionando atividades etc), definir a equipe scrum, monitorar o andamento do sprint através
do taskboard, visualizar o gráfico de burndown, adicionar e remover atividades/tarefas no backlog do produto, definir
o sprint (adicionando atividades ao backlog do sprint etc), visualizar atividades etc.
Objetivos de
Aprendizagem
Ensinar conceitos/práticas de Metodologia Ágil Scrum com ênfase nas atividades exercidas pelo papel do Scrum Master
Bloom
Público-Alvo Estudantes de Metodologia Ágil Scrum/Gerência de Projetos
Pré-requisitos do
Público-alvo
Fonte: (NETO, 2008)
62

Tabela 12 - Informações sobre o jogo Scrumming
Jogo
Scrumming
Duração N/A
Linguagem Java
Plataforma Computador/Windows
Referência N/A
Fonte: (NETO, 2008)
Tabela 13 – Informações sobre o jogo Playing Scrum
Jogo
Playing Scrum
Captura de Telas
do Módulo
Administrador/Cliente
Fonte: (SILLER; BRAGA, 2013)
63

Tabela 13 - Informações sobre o jogo Playing Scrum
Jogo
Playing Scrum
Captura de Telas do
Módulo Jogador/Aluno
Descrição Resumida O jogo é composto por duas “áreas” sendo uma delas contendo as funcionalidades/atividades relacionadas ao Cliente
no Scrum (papel não central), e a outra destinada ao jogador que poderá assumir um dos papeis centrais no Scrum
(Produto Owner, Scrum Master, Equipe de Desenvolvimento). Na área do cliente o usuário poderá propor/formalizar
um projeto a ser desenvolvido, através do cadastro das especiﬁcações para o mesmo, além do cadastro de vídeos e links
de ajuda. Ainda na área cliente, por meio de grupos, será possível vincular diferentes equipes de jogadores a diferentes
projetos com diferente grau de complexidade e a avaliação destas equipes. Na área do jogador será possível a criação
de uma nova equipe ou à associação a uma existente. O jogador poderá assumir o papel de Produto Owner, Scrum
Master ou Equipe de Desenvolvimento, sendo que nos dois primeiros casos isso só será possível se ainda nenhum outro
jogador não tiver assumido estes papeis. O jogador, através de um menu, poderá acessar as telas para execução de suas
tarefas de acordo com o papel de cada um dentro do Scrum. Ou seja, caso o jogador tente acessar uma tela de tarefas
que não é da responsabilidade do papel exercido pelo mesmo, ele será direcionado para um local que o orientará de
tal fato. O jogo é baseado na formação de equipes, por parte dos jogadores, e estas equipes executando projetos de
softwares através de práticas do Scrum. A equipe que obtiver uma pontuação mais alta será considerada a vencedora.
Objetivos de
Aprendizagem
Ensinar conceitos/práticas da Metodologia Ágil Scrum
Bloom
Público-Alvo Estudantes de Engenharia de Software
64

Tabela 13 - Informações sobre o jogo Playing Scrum
Jogo
Playing Scrum
Pré-requisitos do
Público-alvo
N/A
Modo de Interação Multijogador
Duração N/A
Linguagem Java EE
Plataforma Computador/Web
Referência N/A
65

5 DESENVOLVIMENTO/CRIAÇÃO DO JOGO PLAY’ED-SCRUM’CES
Este capítulo apresenta os resultados do processo de desenvolvimento do jogo educa-
cional PLAY’ed-SCRUM’ces, utilizando como referência o modelo ADDIE (as três primeiras
fases – Analise, Projeto, Desenvolvimento) para criação do Design Instrucional para o jogo.
Os resultados incluem a definição/identificação de metas/objetivos instrucionais, contextos or-
ganizacionais e/ou instrucionais (ex: sala de aula onde o jogo poderá ser aplicado), níveis de
aprendizagem a serem atingidos, conteúdo e a sequência em que será abordado, estratégias ins-
trucionais, requisitos/funcionalidades, tabelas, diagramas, tecnologia empregada, elementos do
jogo (regras, dinâmica, cenários, interações, feedback etc).
5.1 Análise/Projeto Instrucional
Nesta subseção serão apresentados os resultados que foram “levantados” para compor o
Design Instrucional do jogo, com base nas fases de análise e projeto do modelo ADDIE.
5.1.1 Análise
Nesta etapa serão definidos o público-alvo, contexto instrucional e metas/objetivos de
aprendizagem.
Público-alvo do PLAY’ed-SCRUM’ces: de uma forma geral este público poderá
ser formado por estudantes da metodologia ágil SCRUM. Dentre os quais pode-
se citar o público formado por estudantes de graduação cujo currículo contemple
o assunto/conteúdo SCRUM. Alguns exemplos destes cursos são aqueles que se
inserem na área de computação como: Ciência da Computação, Sistemas de In-
formação, Engenharia de Software etc. Para os jogadores que já possuam algum
conhecimento teórico/conceitual sobre o Scrum, principalmente a respeito de con-
ceitos básicos como papéis, artefatos e reuniões, espera-se que eles já consigam
jogar sem que seja necessário estudar o conteúdo teórico/educacional do jogo. Mas
não é necessário que os jogadores já apresentem previamente tais conhecimentos,
pois no próprio jogo será possível estudar o conteúdo educacional abordado durante
uma partida do jogo.
Contexto Organizacional/Instrucional: considerando-se o fato de que um dos
possíveis públicos-alvo para este jogo como sendo alunos da área de computa-
ção em geral, permite considerar que as disciplinas destes cursos (cujo currículo
contemple o Scrum) como sendo um dos possíveis contextos instrucionais para
aplicação deste jogo. Aplicação esta que poderá ser realizada em salas de aula,
66

laboratórios ou mesmo em casa como tarefas de extra classe.
Metas/Objetivos de aprendizagem: espera-se que o conteúdo deste jogo possibi-
lite aos jogadores atingir um nível de aprendizagem que contemple aspectos como
os de lembrança e compreensão, definidos de acordo com a taxonomia de Bloom.
Após ter jogado uma “partida” do jogo espera-se que o jogadores tenham desenvol-
vido competências/conhecimentos que os possibilite de:
• Lembrar o nome e definição conceitual de cada um dos papéis, artefatos e
reuniões do Scrum;
• Lembrar/Compreender os objetivos/responsabilidades de cada um dos papéis,
artefatos e reuniões do Scrum;
• Lembrar/Compreender as relações existentes entre cada um dos papéis, arte-
fatos e reuniões do Scrum;
• Lembrar/Compreender nomes, conceitos, objetivos e relações dos conjuntos
de métodos/práticas/regras considerados como os fundamentos para o fra-
mework Scrum, e definidos como sendo os princípios, aspectos e processos
deste frameowork.
5.1.2 Projeto
Nesta etapa serão definidos o conteúdo educacional, a sequência de apresentação para
este conteúdo e as estratégias/atividades de ensino empregadas para se atingir as metas/objetivos
que foram definidos na etapa de análise.
Conteúdo de Ensino: o seguinte conteúdo a respeito da metodologia ágil Scrum
será abordado no jogo:
• Nome e definição conceitual de cada um dos papéis, artefatos e reuniões do
Scrum;
• Objetivos/Responsabilidades de cada um dos papéis, artefatos e reuniões do
Scrum;
• As relações existentes entre cada um dos papéis, artefatos e reuniões do Scrum;
• O nomes, conceitos, objetivos e relações dos conjuntos de métodos/práticas/-
regras considerados como sendo os fundamentos do framework Scrum, e de-
finidos como sendo os princípios, aspectos e processos deste frameowork.
Mais informações sobre o conteúdo educacional do jogo podem ser encontradas
nos Apêndice A e B deste trabalho.
67

Sequência de Apresentação do Conteúdo: o conteúdo do jogo foi agrupado e dis-
tribuído em três partes, sendo que cada parte representará um nível de dificuldade
no jogo. A sequência para o mesmo será a seguinte:
• A primeira parte do jogo apresentará os nomes e conceitos sobre cada um dos
papéis, artefatos e reuniões do Scrum;
• A segunda parte do jogo apresentará os objetivos, responsabilidades e relações
entre cada um dos papéis, artefatos e reuniões dos Scrum;
• A terceira parte do jogo apresentará os nomes, conceitos, objetivos e relações
dos conjuntos de métodos/práticas/regras considerados como sendo os funda-
mentos do framework Scrum, e definidos como sendo os princípios, aspectos
e processos deste frameowork.
Uma segunda forma de apresentação para o conteúdo do jogo é através do me-
nu/funcionalidade “Esdutar”. Através desta funcionalidade será possível a visu-
alização de todo o conteúdo teórico do jogo, estruturado de forma a permitir ao
jogador/estudante estudar/aprender/revisar/consultar todo o conteúdo educacional
do jogo, antes de iniciar uma nova partida. Mais informações sobre a sequência
de apresentação do conteúdo do jogo podem ser encontradas nos Apêndice A e B
deste trabalho.
Estratégias/Atividades de Ensino: algumas possíveis estratégias adotadas (e ou-
tras que poderão ser adotadas) para se atingir/alcançar as metas/objetivos de apren-
dizagem (definidas na subseção 5.1.1) são:
• Projeto/desenvolvimento de uma ferramenta/recurso (o jogo PLAY’ed-SCRUM’ces),
para avaliar e/ou auxiliar/apoiar o processo de ensino-aprendizagem de con-
ceitos sobre o Scrum.
• Estruturação do conteúdo educacional, do jogo PLAY’ed-SCRUM’ces, em
formato de perguntas “fechadas” (perguntas com as opções de respostas) e
uma introdução teórica/conceitual para cada assunto do qual se tratam as per-
guntas.
• Divisão do conteúdo educacional (a parte das perguntas), para o jogo PLAY’ed-
SCRUM’ces, em níveis de dificuldades. Com as perguntas mais fáceis no pri-
meiro nível, as perguntas não tão fáceis e nem tão difíceis no segundo nível e
as perguntas mais difíceis no terceiro nível do jogo.
• Apresentação, em separado, de todo o conteúdo teórico/educacional do jogo
PLAY’ed-SCRUM’ces. Possibilitando ao jogador/estudante se preparar para
o jogo antes de iniciar uma nova partida.
• Algum conteúdo teórico sobre Scrum (ou mesmo o conteúdo teórico do jogo)
poderá ser abordado e discutido em sala de aula antes da aplicação do jogo.
68

• Poderão ser utilizados outros jogos educacionais semelhantes a este (com o
mesmo fim – ex: SCRUM-Scape Camargo (2013) e SCRUM’ed Schneider
(2015)) para ambientar os alunos com este tipo de recurso.
• O jogo poderá ser aplicado em laboratórios utilizados para as aulas “práticas”
do curso/disciplina (que contemple o Scrum) ou como atividade extra classe.
Como o jogo se trata de um aplicativo digital que será desenvolvimento para
ser instalado e executado em dispositivos móveis Android (Smartphone/Ta-
blet), poderá ser “levado/carregado” e utilizado em qualquer lugar/local.
5.2 Desenvolvimento Instrucional
Nesta subseção serão apresentados os resultados que foram “levantados” para compor o
Design Instrucional do jogo, com base na fase de desenvolvimento do modelo ADDIE. Serão
definidos os requisitos/funcionalidades, tabelas, diagramas (caso de uso, DER, classes etc),
os elementos do jogo (regras, dinâmica, cenários, interações, feedback etc), uma descrição
resumida das tecnologias (Android/Java) utilizadas para desenvolver o jogo, e onde se dará a
implementação propriamente dita do jogo/aplicativo.
5.2.1 Diagramas do jogo PLAY’ed-SCRUM’ces
Nesta subseção será apresentada a modelagem do jogo PLAY’ed-SCRUM’ces.
5.2.1.1 Diagrama DER
A modelagem de dados para o jogo PLAY’ed-SCRUM’ces é representada através de
DER – Diagrama Entidade Relacionamento – para representar as tabelas presentes no Banco
de Dados do jogo. Estas tabelas armazenam informações de conteúdo do jogo que permitem o
funcionamento/execução do mesmo. Estes dados são, por exemplo, as perguntas que compõem
o jogo, as possíveis alternativas para cada pergunta, jogadores com suas respectivas pontuações
em cada partida, os possíveis níveis do jogo, os conceitos introdutórios sobre determinados as-
suntos para as questões que dizem respeito ao mesmo etc. A figura 15 exibe o diagrama DER
do jogo PLAY’ed-SCRUM’ces.
69

Figura 15 – Diagrama Entidade Relacionamento - DER
Fonte: Criado pelo autor
5.2.1.2 Diagrama de Caso de Uso
A modelagem das funcionalidades para o jogo PLAY’ed-SCRUM’ces é representada
através de diagrama de Caso de Uso. Dentre as funcionalidades que o jogador/ator poderá exe-
cutar/realizar estão: fazer login; consultar regras do jogo; consultar/estudar o assunto do con-
teúdo educacional; iniciar uma partida; responder as perguntas; pausar/interromper uma partida;
visualizar/consultar pontuações de partidas ﬁnalizadas e/ou interrompidas; reiniciar uma partida
etc. Já o ator/sistema executará/realizará tarefas como: registrar um novo jogador; autenticar
o jogador para que ele tenha acesso ao sistema; calcular a pontuação do jogador durante uma
partida; exibir a pontuação do jogador; registrar a pontuação do jogador; exibir feedback/status
(dicas, regras, níveis etc) durante uma partida etc. A ﬁgura 16 apresenta o diagrama de Caso de
Uso (com alguns Caso de Uso) do jogo PLAY’ed-SCRUM’ces.
70

Figura 16 – Diagrama de Caso de Uso
5.2.1.3 Diagrama de Classes
A modelagem da “implementação” do jogo PLAY’ed-SCRUM’ces é representada atra-
vés de diagrama de Classe. Dentre as classes presentes neste diagrama estão: a classe PlayedS-
crumce como sendo a principal classe do jogo, será a responsável por intermediar/controlar as
ações entre jogador/aplicativo com as outras classes; a classe Player como sendo a classe que
representa o usuário/jogador e responsável por “gerenciar” a partida da qual ele participa, repre-
sentada através da classe GameMatch; a classe Database responsável por intermediar/controlar
todos os acessos a base de dados do aplicativo e ”gerenciar” a classe que representa a conexão
com essa base que é a classe Connection; a classe Level que representa os possíveis níveis de
diﬁculdades do aplicativo/jogo e responsável por ”gerenciar” a classe Concept; a classe Concept
que representa os conceitos/temas introdutórios de que se tratam as próximas questões a serem
respondidas pelo jogador, e a responsável por ”gerenciar” a classe Question; a classe Question
que representa as perguntas do jogo e a responsável por ”gerenciar” a classe que representa as
alternativas de cada questão, a classe Alternative; a classe Help que representa todas as possíveis
“ajudas” que o jogador poderá solicitar antes, durante e depois de uma partida, representadas
através das classes Rules, responsável pelas regras do jogo, e ScrumFramework, responsável
por um conteúdo que o jogador poderá solicitar para realizar estudos sobre o framework Scrum
(mostra uma visão geral do framework Scrum). A ﬁgura 17 apresenta o diagrama de Classes do
jogo PLAY’ed-SCRUM’ces.
71

Figura 17 – Diagrama de Classe
5.2.2 Regras do jogo PLAY’ed-SCRUM’ces
A dinâmica de um jogo é conduzida segundo suas regras que deverão serem conheci-
das pelos jogadores, e desta forma possibilitar com que os mesmos possam/consigam jogar o
jogo. Além de permitir aos jogadores à capacitação para agir (tomar decisões) da melhor forma
possível, quando as circunstâncias exigirem. As regras do jogo PLAY’ed-SCRUM’ces são:
• Regra 1: o jogo só pode ser jogado por um único jogador por vez.
• Regra 2: o jogo terá duração máxima de 120 minutos (equivalente a 2 horas/aula da
disciplina de EG).
• Regra 3: o conteúdo do jogo é composto por um conjunto de perguntas “fechadas” a
serem respondidas pelo jogador.
• Regra 4: dentre as possíveis alternativas, o jogador deverá escolher/selecionar, no má-
ximo, a quantidade deﬁnida em cada questão.
• Regra 5: caso o jogador tente marcar mais opções do que o limite permitido ele será
advertido/orientado do ocorrido. Podendo o mesmo desmarcar uma opção já selecionada
para marcar uma outra.
• Regra 6: as questões estão divididas em 3 níveis de diﬁculdade, o primeiro e segundo
níveis com 15 questões cada e o terceiro com 19 questões.
• Regra 7: para cada questão respondida de forma correta o jogador ganhará 1 ponto no
primeiro nível, 2 pontos no segundo e no terceiro nível, 3 pontos para as questões de 1 a
11 e 2 pontos para as questões de 12 a 19, totalizando 94 pontos.
• Regra 8: o jogador poderá passar para a pergunta seguinte ou retornar para a pergunta
anterior, quando desejar. Ele poderá saltar/pular qualquer questão que, por ventura, não
72

deseja responder. Podendo retorná-la, a qualquer momento, se ainda lhe restar tempo para
isso.
• Regra 9: caso o jogador deseje, ele poderá responder parcialmente uma questão. Esco-
lhendo um número menor de alternativas do que o limite definido pela questão.
• Regra 10: o jogador poderá passar para o nível seguinte ou retornar ao nível anterior a
qualquer momento, se ainda lhe restar tempo para isso.
• Regra 11: para vencer o jogo o jogador precisará fazer uma pontuação equivalente a
63 pontos dos 94 possíveis. O que representa, aproximadamente, a uma porcentagem
equivalente a 80% dos pontos possíveis do primeiro nível (12 pontos), somados a 70%
dos pontos possíveis do segundo nível (21 pontos) e mais 60% dos pontos possíveis do
terceiro nível (aproximadamente 30 pontos).
• Regra 12: ao executar o jogo/aplicativo o usuário/jogador deverá se identificar antes de
poder ter acesso as funcionalidades do jogo/aplicativo.
• Regra 13: o jogador poderá consultar/acessar as regras do jogo a qualquer momento,
estando o mesmo no decorrer de uma partida ou não.
• Regra 14: antes de iniciar ou após o término de uma partida o jogador poderá “estudar”
o conteúdo “cobrado/abordado” nas questões do jogo.
• Regra 15: o jogador poderá pausar uma partida para posteriormente reiniciá-la.
• Regra 16: o jogador poderá parar uma partida.
• Regra 17: ao finalizar/parar uma partida o resultado será exibido ao jogador.
• Regra 18: o jogador poderá visualizar toda a partida que foi finalizada/parada, para veri-
ficar a pontuação conseguida na questão e as alternativas escolhidas.
• Regra 19: o jogador poderá consultar os resultados de partidas anteriores finalizadas/pa-
radas.
• Regra 20: o jogador poderá consultar uma partida “parada” para “recuperá-la” e conti-
nuar a jogar. A partida será reiniciada a partir da questão onde ela foi interrompida.
• Regra 21: o jogador poderá visualizar partidas anteriores finalizadas ou “paradas”.
• Regra 22: se o jogador não conseguir responder todas as questões durante os 120 minu-
tos, será computada a pontuação até a última questão respondida.
73

5.2.3 Fundamentação teórica sobre a tecnologia Android/Java
Foram realizadas pesquisas/buscas, com intuito de identificar material/recursos sobre
a tecnologia utilizada para desenvolvimento de aplicativos para dispositivos móveis que exe-
cutam/rodam sobre o SO/Plataforma Android. O material levantado foi estudado, exemplos
de aplicativos foram criados/codificados e instalados/executados para efeitos de testes. Dessa
forma pode-se compreender a tecnologia que seria empregada no desenvolvimento do jogo
PLAY’ed-SCRUM’ces.
Para o download de recursos/arquivos necessários, preparação/configuração de ambi-
ente de programação, implementação/codificação dos exemplos e do jogo/aplicativo propria-
mente dito, e geração do arquivo *.apk/aplicativo para distribuição/instalação do jogo, foram
realizados os seguintes passos:
1. Identificação e obtenção dos recursos/ferramentas necessários a permitir a codificação,
testes, distribuição, instalação e execução do jogo/aplicação (apk);
• Download do Java SE Software Development Kit (JDK) em:
– http://www.oracle.com/technetwork/java/javase/downloads/index.html, ou em
– http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-
javase7-521261.html#jdk-7u80-oth-JPR
• Download da IDE Eclipse em:
– http://download.eclipse.org/eclipse/downloads/, ou em
– http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2201301310800/, ou em
– http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2-201301310800/download.php?d
SDK-3.8.2-win32.zip
• Download do Android Software Development Kit (SDK) em:
– https://developer.android.com/studio/index.html
– https://dl.google.com/android/installer_r24.4.1-windows.exe
• Download do Android SDK Manager (já vem com o SDK);
• Download do Android Development Tools (ADT) Plugin para Eclipse em:
– https://dl-ssl.google.com/android/eclipse/ a partir do mecanismo de atualização
da IDE Eclipse
• Download do Android Emulator (já vem com o SDK); e
• Download do Android Virtual Device (AVD) Manager (já vem com o SDK).
2. Instalação e configuração dos recursos/ferramentas;
• Instalação e configuração do Java SE Software Development Kit (JDK) segundo
(ORACLE, 2014) em:
74

– http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jdk-installation-
windows.html
• Instalação e configuração do Android Software Development Kit (SDK) de acordo
com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015);
– Clique duplo no instalador (no caso do executável para windows)
– Seguir os passos/orientações do instalador
– Passe para a instalação da IDE Eclipse, e após completado este passo retorne
neste ponto
– Execute a IDE Eclipse
– Selecione o menu Window -> Android SDK Manager
– Desmarque a caixa de seleção Instalados
– Selecione os pacotes listados em Tools
– Selecione os pacotes listados na versão do Android que se deseja instalar. Exem-
plo de uma das versões do Android - Android 4.4.2 (API 19)
– Selecione os pacotes listados em Extras. Geralmente parte dos pacotes listados
aqui são opcionais. Os mais comuns são: Android Support Library ou Android
Support Repository, Google USB Driver e Google Play services.
– Clique no botão Install
• Instalação e configuração da IDE Eclipse de acordo com (DEITEL & ASSOCIATES,
INC., 2015; DEITEL; DEITEL; DEITEL, 2015);
– Descompacte o arquivo zip no local desejado
– Selecione o menu Window->Preferences e selecione Android no lado esquerdo
da tela
– Em SDK Location, no lado direito da tela, certifique/selecione o diretório de
instalação do Android SDK.
– Finalize a IDE.
• Instalação e configuração do Android Development Tools (ADT) Plugin para Eclipse
de acordo com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015);
– Selecione o menu Help -> Install New Software
– Clique no botão Add no lado direito da tela
– Informe o nome em Name, e em Location, entre a url https://dl-ssl.google.com/android/eclip
– Clique OK e aguarde o download do plugin
– Na lista de software disponíveis, quando Developer Tools for exibido marque-o
e clique em Next/Finish.
• Instalação e configuração do Android Virtual Device (AVD) Manager de acordo
com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015);
75

– Selecione o menu Window -> Android Virtual Device Manager. A partir do
AVD Manager será possível criar e configurar emuladores dos dispositivos mó-
veis, para os quais se deseja que a aplicação/apk desenvolvida seja executada/-
testada.
3. Execução e testes da aplicação no ambiente de programação (IDE).
• Caso seja necessário adicionar alguma biblioteca para um determinado projeto siga
os passos a seguir:
– Depois de realizado o download do pacote Android Support Repository, através
do SDK Manager na opção Extras, o arquivo de bibliotecas poderá ser locali-
zado em <sdk>/extras/. Onde <sdk> representa o diretório raiz de instalação
do SDK. Pode-se clicar com o botão direito sobre o projeto e escolher propri-
edades. Na tela que se abre, no lado esquerdo, selecionar Java Build Path e
no lado direito selecionar Libraries. Em seguida deve-se clicar no botão que
representa o tipo de biblioteca de suporte pretende-se adicionar, “navegar” até
onde se encontra o arquivo e selecioná-lo.
– Depois de localizado o arquivo de biblioteca, no Project Explorer do lador es-
querda na IDE, deve-se clicar com o botão direito sobre o arquivo, escolher
Build Path->Configure Build Path.
– Por útimo clicar novamente, com botão direito, sobre o projeto e selecionar
propriedades. Na tela que se abre, no lado esquerdo, selecionar Android, e no
lado direito em Library clicar em Add. Na tela que se abre selecionar a opção
desejada.
• Para executar a aplicação clicar no botão Run apk, na barra de ferramentas da IDE.
A IDE poderá solicitar o AVD no qual se deseja que a aplicação execute.
4. Geração do arquivo *.apk para distribuição/instalação/execução do jogo/aplicativo.
• Execute a IDE Eclipse
– Selecione o menu File -> Export
– Na tela que se abre selecione Android -> Export Android Aplication e clique
no botão Next.
– Na tela que se abre selecione o projeto para o qual se deseja gerar o arquivo
*.apk e clique no botão OK.
– Na tela seguinte selecione uma das seguintes opções: usar chave existente ou
criar uma nova. Em seguida informe a senha e clique no botão OK.
– Na próxima tela clique no botão Next.
– Na tela seguinte informe o destino do arquivo *.apk.
– Transfira e instale o *.apk para o Smartphone ou Tablet e execute o aplicativo.
76

5.2.4 Dinâmica do jogo PLAY’ed-SCRUM’ces
Ao executar/”rodar” o jogo PLAY’ed-SCRUM’ces, em um dispositivo móvel Android
(Smartphone ou Tablet), a tela de login/identificação, representada pela figura 18, será exibida.
Figura 18 – Tela de Login
O usuário/jogador deverá informar o login e senha. Caso ele já tenha sido cadastrado é só cli-
car/”tocar” no botão OK, caso contrário deverá selecionar/marcar a opção Novo Jogador, antes
de clicar/”tocar” no botão OK. O jogador poderá também clicar/”tocar” no botão CANCEL ou
na opção de menu Sair, caso ele não deseje mais prosseguir com a execução do jogo. Ao “logar”
no jogo/aplicativo, uma tela de “boas vindas”, representada pela figura 19, será exibida.
77

Figura 19 – Tela de Boas Vindas
A partir deste momento o jogador tem acesso a todas as funcionalidades do jogo/apli-
cativo. Na tela de boas vindas é exibida uma breve descrição dos objetivos/motivos de cria-
ção/implementação do jogo PLAY’ed-SCRUM’ces. Com os respectivos autor e orientador. O
jogador poderá então executar uma das seguintes ações/funcionalidades de menu: iniciar uma
nova partida, visualizar as regras do jogo, estudar/apreender o conteúdo abordado no jogo ou
sair/interromper o aplicativo/jogo. Outras funcionalidades como pausar e/ou parar/interromper
a partida serão acessíveis após o jogador iniciar uma nova partida.
Após iniciada uma partida não será permitido executar a ação de estudar até que a par-
tida seja finalizada ou paralisada/interrompida. Dependendo da ação/funcionalidade executada
as opções de menu podem mudar para “atender” a tela resultante da ação. Existem também
outras importantes funcionalidades como: visualizar resultados de uma partida e visualizar par-
tida; ambas também sendo exemplificadas mais abaixo de como e quando ocorrem.
Ação – Visualizar as Regras do Jogo
Ao “consultar” as regras do jogo a tela, representada pela figura 20, será exibida. O jo-
gador poderá/deverá “rolar/deslizar” a tela na vertical para conseguir visualizar todas as regras.
78

Figura 20 – Regras do Jogo
Ação – Visualizar o Conteúdo de Estudo do Jogo
Ao acessar o conteúdo de/para estudo/aprendizagem do jogo a tela, representada pela
ﬁgura 21, será exibida. O jogador poderá/deverá “rolar/deslizar” a tela na vertical/horizontal
para conseguir visualizar todo o conteúdo de estudo de cada “página”.
79

Figura 21 – Conteúdo de Estudo do Jogo
80

Ação - Iniciar uma nova Partida
Ao iniciar uma nova partida a tela inicial de nova partida, representada pela ﬁgura 22,
será exibida.
Figura 22 – Tela de Início de uma Nova Partida
No topo desta tela e abaixo das opções de menu, são exibidas informações como: o tempo
restante de jogo (que vai decrescendo a medida que o tempo passa), o nível do jogo em que o
jogador atualmente se encontra (são três níveis ao todo), e a questão que o jogador atualmente
está/irá responder (neste caso a primeira questão do primeiro nível). Logo abaixo, no caso desta
tela, um assunto/conteúdo/conceito introdutório para auxiliar no entendimento/resposta daquela
questão, localizada logo abaixo, e possivelmente de outras questões nas telas seguintes. O que
quer dizer que esta introdução poderá ser referente a apenas à questão atual ou possivelmente a
outras questões seguintes a esta. Isso estará deﬁnido no próprio assunto introdutório. Portanto
haverão telas que terão tal introdução e outras que não.
Logo mais abaixo vem a pergunta da questão, acompanhada de suas possíveis alter-
nativas de respostas. Cada questão informa ao jogador o número máximo de alternativas que
poderá/deverá ser escolhido/marcado. Ao “rolar/deslizar” a tela um pouco para baixo será pos-
sível visualizar o(s) botão(ões) de “navegação” de cada tela (no caso desta tela só existe o botão
para “navegar/passar” para a próxima questão/tela). Através destes botões será possível “nave-
gar/passar” para próxima questão/nível ou voltar/retornar a questão/nível anterior. Na segunda
81

e última questão/tela do primeiro nível, por exemplo, representadas pela figura 23, é possível
visualizar os dois botões de navegação.
Figura 23 – Botões de Navegação
Estes botões, quando clicados/”tocados”, também fazem com que as informações presentes no
topo de cada questão/tela sejam atualizadas. No caso da segunda tela desta figura, ao clicar no
botão de Próximo fará com que a primeira questão/tela (questão 1) do próximo nível (nível 2)
seja exibida.
A seguir, as telas da primeira e última questão dos níveis dois e três são representadas
pela figura 24.
82

Figura 24 – Primeira e Última Telas do Nível 2 e 3
83

Na última questão/tela do nível treis (última tela desta ﬁgura), ao clicar no botão Fim, a tela
com os resultados da partida será exibida.
Ação – Visualizar Resultados da Partida
A tela com os resultados de uma partida será exibida nas seguintes situações: quando o
jogador clicar/tocar no botão FIM DO JOGO (última questão do último nível); quando o tempo
para a partida terminar (decrescendo até chegar em zero); ou quando o jogador optar por pa-
rar/interromper a partida. Um exemplo de tela com os resultados para uma partida pode ser
visto a seguir, representado pela ﬁgura 25.
84

Figura 25 – Resultados de uma Partida
85

Ação – Pausar uma Partida
Depois de iniciada uma partida, ela poderá ser “pausada”, a qualquer momento, quando
o jogador assim desejar. Isto será possível através da opção de menu Pausar. A figura 26 repre-
senta um exemplo de tela com a partida “pausada”.
Figura 26 – Tela de uma Partida Pausada
A partir deste momento não será mais possível interagir com os “controles” da tela (exceto os
controles de opções de menu), até que a partida seja “retomada”/continuada. O que pode ser
feito clicando/”tocando” na opção de menu CONTINUAR.
Ação – Parar/Interromper uma Partida
Depois de iniciada uma partida, ela poderá ser “parada”/interrompida, a qualquer mo-
mento, quando o jogador assim desejar. Isto será possível tanto através da opção de menu
Parar quanto pelo botão de retornar/voltar do dispositivo móvel (Smartphone/Tablet). Utili-
zando a opção de menu Parar o jogador será “advertido” sobre sua decisão, para que o mesmo
possa confirmá-la ou não. A figura 27 representa um exemplo de partida onde o jogador cli-
cou/”tocou” na opção de menu Parar.
86

Figura 27 – Tela de uma Partida sendo Parada
Caso o jogador confirme sua ação, através do botão OK, a tela com os resultados da partida
será exibida. Do contrário continuará a partida normalmente.
Ação – Visualizar Partida
Na tela de resultados, ao “rolar/deslizar” até a “base”, será possível visualizar o botão
VISUALIZAR PARTIDA (ex: última tela da figura 25). Ao clicar/”tocar” neste botão o jogador
poderá “navegar” por toda a partida. Sendo que a cada questão/tela serão exibidas informações
como: a quantidade de pontos que "vale"a questão; a pontuação adquirida pelo jogador na
questão; e as alternativas corretas da questão. Dessa forma o jogador poderá visualizar o assun-
to/conteúdo do qual a questão se refere e pelo resultado obtido, se será necessário um melhor
entendimento (estudar mais) ou não tal conteúdo. Como exemplo, a figura 28, representam
algumas das telas de uma partida finalizada/parada, sendo visualizada pelo jogador.
87

Figura 28 – Visualização de uma Partida
88

Ao clicar no botão FIM DA VISUALIZAÇÃO, última tela desta ﬁgura, a visualização será
encerrada e o jogador poderá iniciar uma nova partida.
89

6 CONCLUSÕES E TRABALHOS FUTUROS
Neste capítulo serão apresentadas as conclusões e propostas de possíveis trabalhos futu-
ros. As conclusões serão apresentadas com uma avaliação comparativa do que se propôs a fazer
com o que de fato foi feito/realizado e com algumas ponderações.
6.1 Conclusões
Como principal objetivo este trabalho visou projetar e desenvolver um jogo educacional
digital, para dispositivos móveis Android (Smartphone/Tablet), para avaliar/auxiliar o ensino-
aprendizagem de conceitos sobre a metodologia ágil SCRUM. Diante deste contexto este tra-
balho foi estruturado em etapas e subetapas, sendo cada uma delas subdividas em atividades
“menores”. A medida que estas atividades iam sendo executadas e seus resultados “somados”,
com aqueles de atividades anteriores, o objetivo maior aos poucos ia sendo alcançado.
Foram previstas quatro etapas, sendo a quarta subdivida e originando outras quatro novas
subetapas, com cada uma, novamente, compostas por suas respectivas atividades. As etapas
de um a três objetivavam basicamente a uma fundamentação/embasamento teórico a respeito
da literatura sobre os respectivos assuntos dos quais se tratavam. Assuntos estes escolhidos
de forma deliberadamente para permitir tanto há um embasamento teórico por parte do autor,
como também, possibilitar ao leitor “comum” (que não fosse da área de Computação) ter uma
visão geral de como pode-se dá um processo de desenvolvimento e gerência de um projeto de
software. E a quarta etapa objetivava ao projeto/desenvolvimento do jogo.
Na primeira etapa se propôs fazer uma análise/revisão/fundamentação da literatura para
Engenharia de Software, Gerência de Projetos e SCRUM. Para a ES os resultados obtidos foram
de acordo com uma das principais referências para a área. Foram apresentadas uma definição e
a “visão” em “camadas” e com foco na qualidade, do autor, para a ES. Para a GP utilizou-se a
principal referência na área para se chegar aos resultados. Foram apresentadas definições e uma
breve apresentação dos principais conceitos (requisitos, fases, processos etc) que devem estar
presentes durante a gerência de um projeto. Já para o SCRUM, cuja fundamentação teórica é
uma das mais importantes deste trabalho, os resultados deveriam ser apresentados de forma a
permitir um entendimento mais aprofundado sobre o assunto. Para tanto foram apresentados
para o Scrum: seus principais conceitos (definição, “teorias” base, os principais componentes
básicos etc) segundo os idealizadores desta metodologia; uma visão geral dos ciclos (Sprint’s)
e uma visão mais aprofundada do framework Scrum, segundo um dos principais “guia” para
Scrum.
Na segunda etapa se propôs fazer uma análise da literatura para Ensino-Aprendizagem
e Jogos-Educacionais. Para o EA os resultados foram alcançados a partir de referências “situ-
adas” em diferentes espaços de tempo, mas que na sua maioria com uma opinião em comum
para o EA (trata-se de um processo fortemente influenciado pela Psicologia ao longo do tempo).
90

Foram apresentadas algumas definições e uma outra fundamentação das mais importantes deste
trabalho, que são o Design Instrucional e mais especificamente a metodologia ADDIE utiliza-
da/empregada neste trabalho para o desenvolvimento do DI/JE. Para os JE os resultados foram a
apresentação de algumas definições e classificações para os tipos de jogos. Nas referências uti-
lizadas é possível perceber a importância que os JE podem exercer no processo de EA, segundo
seu autores. De acordo com o mesmos, os aspectos de jogos (divertidos, desperta interesse etc)
aliados, de forma adequada, aos aspectos de instrução podem formar um recurso poderoso para
auxiliar no processo de EA.
Na terceira etapa se propôs fazer uma revisão dos JE existentes na literatura para o EA de
ES/SCRUM. Os resultados alcançados, tanto para os JE de ES quanto para os de SCRUM, foram
as análises destes jogos e a representação dos dados através de tabelas. Facilitando, dessa forma,
o entendimentos destes dados por parte do leitor. Algumas das informações analisadas foram:
objetivos de aprendizagem, nível de aprendizagem, público-alvo, modo de iteração, resultados
de avaliações, tipo do jogo etc. Com os resultados apresentados nesta etapa e considerando que
alguns dos jogos que foram analisados já existem desde 2007, é possível inferir que os JE estão
ganhando cada vez mais “popularidade”, como recurso de apoio ao processo de EA. E ao que
tudo indica, esse parece ser um caminho sem volta.
A quarta etapa deu origem as seguintes subetapas: Análise/Projeto Instrucional; Análi-
se/Projeto do Jogo; Fundamentação teórica/prática sobre Programação para Dispositivos Mó-
veis Android e Implementação. Sendo todas essas quatro subetapas baseadas nas três primeiras
fases do modelo ADDIE. De forma que a primeira subetapa representando as fases de Aná-
lise e Design do modelo ADDIE, e as outras três representando a fase de Desenvolvimento do
modelo. E os resultados obtidos ao fim destas subetapas/fases vão formando/originando um
Design Instrucional do qual o jogo PLAY’ed-SCRUM’ces é parte integrante.
Na primeira subetapa da etapa quatro se propôs fazer a Análise Instrucional e o Projeto
Instrucional do Design Instrucional, cujo o jogo PLAY’ed-SCRUM’ces será parte integrante.
Os resultados alcançados para a Análise Instrucional foram: a definição de um possível público-
alvo, formado basicamente por estudantes de Scrum; a definição de alguns possíveis contextos
instrucionais para a aplicação do jogo; e a definição das metas e/ou objetivos de aprendizagem
que o jogador deverá atingir após jogar uma partida do jogo. Para o Projeto Instrucional os
resultados alcançados são: a definição do conteúdo educacional para o jogo; a definição da
sequência de apresentação para o conteúdo educacional; e a definição de estratégias de ensino
de forma a garantir que as metas/objetivos educacionais sejam atingidos.
Na segunda subetapa da etapa quatro se propôs fazer a Análise e o Projeto para o jogo.
Os resultados alcançados foram: a modelagem do jogo PLAY’ed-SCRUM’ces, com a criação
do diagrama DER (definição das tabelas/relacionamentos para o banco de dados do jogo), a
criação do diagrama Casos de Uso (algumas das principais funcionalidades do jogo), a criação
do diagrama de Classes (algumas das principais classes do jogo/aplicativo); e a definição de
alguns aspectos de jogos para o jogo PLAY’ed-SCRUM’ces, como a navegabilidade para o
jogo, e a criação e/ou definição das regras do jogo.
91

Na terceira subetapa da etapa quatro se propôs fazer a fundamentação teórica/prática
da literatura para programação de aplicativos para dispositivos móveis Android. Os resultados
alcançados foram: identificação e obtenção dos recursos/ferramentas necessários; instalação e
configuração destes recursos; “criação”/execução/testes de aplicativos de exemplo; e geração
do arquivo *.apk para distribuição.
Na quarta e última subetapa da etapa quatro se propôs fazer a codificação/implementa-
ção do aplicativo/jogo. Os resultados alcançados foram: o aplicativo/jogo foi codificado/imple-
mentado/criado; testes foram feitos/realizados durante e após a codificação; o arquivo *.apk, do
aplicativo, foi gerado, “transferido”/distribuído e instalado/executado.
6.1.1 Algumas ponderações
Por toda a estrutura deste trabalho procurou-se usar o máximo de recursos visuais e de
formatação, de forma a permitir/proporcionar uma melhor apresentação do texto/assunto dos
quais estes tratavam. E como consequência permitir com que tais assuntos fossem assimilados
mais facilmente pelo leitor. Muitos recursos visuais como: figuras, tabelas etc; e de forma-
tação como: capítulos, seções, subseções, parágrafos, endentação/citação, fonte “destacada”,
itemização etc; estão presentes por todo o trabalho desde o primeiro até o último capítulo. Fo-
ram ainda adicionados assuntos “extras”, através de apêndices, para proporcionar ao leitor um
melhor entendimento do conteúdo educacional presente no jogo PLAY’ed-SCRUM’ces.
Durante a realização dos testes do jogo/aplicativo - PLAY’ed-SCRUM’ces, ou simples-
mente durante uma partida pelo simples ato de jogar, ou mesmo ainda utilizando/navegando
por outras funcionalidades no PLAY’ed-SCRUM’ces; foi possível se ter uma “ideia”/”noção”
de quão interessante/estimulante pode ser a experiência de se utilizar/jogar este tipo de aplica-
tivo/jogo em dispositivos móveis como Smartphone e/ou Tablets.
De certa forma essa agradável ”impressão”/experiência é bastante compreensível, pois o
jogador/estudante tem, “ali”, a um simples toque de seus dedos, todo um conteúdo educacional,
que ele poderá “acessar”, caso seja de seu interesse ou por pura necessidade mesmo, a qualquer
hora, em qualquer lugar. Melhor ainda, este conteúdo está em “formato” de um jogo, o que
significa que ele pode aprender “brincando”/divertindo-se.
Acredito que alguns outros fatores, falando especificamente do PLAY’ed-SCRUM’ces,
foram também responsáveis por essa agradável experiência. Dentre os quais pode-se citar: o
conteúdo do jogo; a forma como o conteúdo foi “estruturado” e está sendo apresentado ao joga-
dor; a navegabilidade/dinâmica do jogo; a forma como os resultados estão sendo apresentados;
e as possibilidades/funcionalidades disponibilizadas etc; estão influenciando diretamente e de
forma positiva nesta “impressão” que tive ao testar/utilizar/jogar o jogo/aplicativo PLAY’ed-
SCRUM’ces.
Nas etapas 2 e 3, apesar de utilizadas as principais referências na área e a breve ex-
planação sobre os assuntos, ainda sim, a citação de mais referências poderia “enriquecer” os
92

argumentos apresentados. Na etapa 4 (com suas respectivas subetapas) foi onde se deu a “cria-
ção” do Design Instrucional cujo jogo PLAY’ed-SCRUM’ces é parte integrante.
Estes resultados foram alcançados graças a utilização/emprego de um modelo utilizado
para criação de Design Instrucionais – o modelo ADDIE. Acontece que foram “executadas”
apenas as três primeiras fases deste modelo – Análise, Projeto e Desenvolvimento. De forma
que o DI resultante ficou/está incompleto. Restando ainda acrescentar ao DI resultante, os resul-
tados das fases Implementação/Aplicação e Avaliação. Fases estas responsáveis, basicamente,
pela execução/aplicação e avaliação do DI resultante das três primeiras fases. Dessa forma
pode-se dizer que: o DI desenvolvido não foi testado (colocado à prova), e por isso sua eficácia
ainda não foi comprovada.
Por fim, pode-se dizer também que o jogo, apesar de disponibilizar muitos recursos
gráficos como imagens, não disponibiliza quase ou nenhum recurso gráfico como animações
e/ou “bonecos” etc; o que tinha sido previsto fazer na subetapa 2 da etapa 4.
6.2 Propostas de Possíveis Trabalhos Futuros
• Como mencionado anteriormente, o Design Instrucional (DI) desenvolvido neste traba-
lho, e cujo jogo PLAY’ed-SCRUM’ces é parte integrante, ficou/está “incompleto”. Fal-
tando ainda os resultados das fases Implementação/Aplicação e Avaliação – do modelo
ADDIE. Fases estas responsáveis, basicamente, pela execução/aplicação e avaliação do
DI resultante das três primeiras fases. Portanto uma possível proposta de trabalho a ser
feito/realizado é a execução/aplicação e avaliação de resultados para o DI (jogo/aplica-
tivo) desenvolvido neste trabalho.
• Considerando os seguintes fatos: o jogo PLAY’ed-SCRUM’ces é um jogo educativo, por
isso seu principal objetivo é o de auxiliar o processo de Ensino-Aprendizagem do Scrum;
em um ambiente universitário ou empresarial, onde exista algum curso sobre Scrum,
este jogo pode ser utilizado como recurso de auxílio/apoio etc. Diante desse contexto,
uma outra possível proposta de trabalho futuro é criar um segundo “módulo” para o jogo
PLAY’ed-SCRUM’ces. De forma que, o que já está pronto constituiria o módulo de usuá-
rio/jogador e o novo módulo seria o de administrador. Através do qual, todo o conteúdo
educacional do jogo seria gerenciado. Além disso a base de dados (banco de dados) do
jogo PLAY’ed-SCRUM’ces agora não seria mais “local” (no próprio dispositivo móvel),
mas em um local “remoto” e compartilhada/acessada por todos os módulos clientes (mó-
dulo de usuário/jogador). Gerenciada, também, pelo administrador do módulo adminis-
trador. Este administrador poderia ser um professor de ES, e como tal incluir, visualizar,
alterar, excluir etc o conteúdo educacional do jogo. Além é claro, de poder analisar os
dados de resultados das partidas realizadas por seus alunos. Proporcionando ao professor
uma “poderosa” ferramenta/mecanismo para avaliar o processo de ensino-aprendizagem
do Scrum.
93

• Criar/Desenvolver uma versão do jogo/aplicativo PLAY’ed-SCRUM’ces para “rodar”/executar
em dispositivos móveis da Apple.
94

Referências
ABES SOFTWARE. Mercado brasileiro de software: Panorama e Tendências.
São Paulo, p. 6–9, jun. 2015. Edição 2015 Dados de 2014. Disponível em:
<http://central.abessoftware.com.br/Content/UploadedFiles/Arquivos/DadosAcesso em: 9
mar. 2016.
ABT, Clark C. Serious Games. 2. ed. University Press of America, 1987. Disponí-
vel em: <https://books.google.co.in/books/about/Serious_Games.html?id=axUs9HA-hF8C>.
Acesso em: 11 may 2016.
BATTISTELLA, Paulo E.; WANGENHEIM, Christiane G. von; FERNANDES, João M. Como
jogos educacionais são desenvolvidos?: Uma revisão sistemática da literatura. Florianópolis-
SC, jul. 2014. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/wei/2014/0014.pdf>.
Acesso em: 29 feb. 2016.
BENITTI, Fabiane Barreto Vavassori; MOLLéRI, Jefferson Seide. Utilização de um
rpg no ensino de gerenciamento e processo de desenvolvimento de software. In:
SBC - SOCIEDADE BRASILEIRA DE COMPUTAçÃO, XXVIII., 2008, Pará. Pará:
Sociedade Brasileira de Computação, 2008. p. 443. Ref. 258–267. Disponível em:
<http://www.lbd.dcc.ufmg.br/colecoes/wei/2008/0030.pdf>. Acesso em: 20 mar. 2016.
BLOOM, Benjamin S. Taxonomy of Educational Objectives Book 1: Cogni-
tive Domain. 2. ed. Addison Wesley Publishing Company, 1984. Disponível em:
<https://books.google.co.in/books/about/Taxonomy_of_Educational_Objectives.html?id=hos6AAAAIAAJ
Acesso em: 5 nov. 2016.
BONWELL, Charles C.; EISON, James A. Active learning: Creating excite-
ment in the classroom.: Eric digest. Washington-DC, 1991. Disponível em:
<http://documents.manchester.ac.uk/display.aspx?DocID=19800>. Acesso em: 6 nov.
2016.
BRAGA, Juliana Cristina. Objetos de Aprendizagem: Metodologia de De-
senvolvimento. 1. ed. Santo André - SP: UFABC, 2015. Disponível em:
<http://proec.ufabc.edu.br/uab/metdesOA2/2014-BRAGA-livro-oa.pdf>. Acesso em: 4
mar. 2016.
CAMARGO, André Stangarlin de. Jogo de RPG para Ensinar SCRUM. 2013. 103 f.
Monograﬁa (Bacharel em Ciências da Computação) — Departamento de Informática
e Estatística, Universidade Federal de Santa Catarina, Florianópolis. Disponível em:
<http://www.gqs.ufsc.br/wp-content/uploads/2011/11/TCC-Andre-Camargo-vf.pdf>. Acesso
em: 29 fev. 2016.
CEVIU. 2016. Disponível em: <http://www.ceviu.com.br/buscar/empregos?termoPesquisa=Scrum>.
Acesso em: 29 fev. 2016.
CHAPMAN, Alan. bloom´s taxonomy - learning domains. 2009. Disponível em:
<http://www.businessballs.com/bloomstaxonomyoﬂearningdomains.htm>. Acesso em: 5 nov.
2016.
CLARK, Donald. ADDIE Model. 7 1995. Atualizado em 6 de Setembro de 2015. Disponível
em: <http://nwlink.com/ donclark/history_isd/addie.html>. Acesso em: 5 nov. 2016.
95

CMS - CENTER FOR MEDICARE & MEDICAID SERVICES. Se-
lecting a development approach. Maryland, fev. 2005. Disponível em:
<https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-
Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf>. Acesso em: 28 fev.
2016.
CROSS, K. Patricia. Teaching "for"learning. Carolina do Norte, p. 1–23, feb. 1987. Paper pre-
sented at the North Carolina State University Centennial Year Provost’s Forum. Disponível em:
<http://files.eric.ed.gov/fulltext/ED280537.pdf>. Acesso em: 1 mar. 2016.
DEITEL & ASSOCIATES, INC. Installing ADT Plug-In for Eclipse. 2015. Disponível
em: <http://www.deitel.com/bookresources/AndroidFP2/InstallAndroidSDKandEclipse.pdf>.
Acesso em: 9 oct. 2016.
DEITEL, Paul; DEITEL, Harvey; DEITEL, Abbey. Android How to Program:
with an introduction to java. 2. ed. Pearson Education, Inc, 2015. Disponível em:
<http://www.deitel.com/Books/Android/AndroidHowtoProgram2e/tabid/3654/Default.aspx>.
Acesso em: 19 jul. 2016.
DEMPSEY, CJohn V.; RASMUSSEN, Karen; LUCASSEN, Barbara. The instructional
gaming literature: Implications and 99 sources. 1996. Technical Report 96-1. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2287&rep=rep1&type=pdf>.
DJAOUTI, Damien et al. Origins of Serious Games. [s.n.], 2011. Disponível em:
<http://www.ludoscience.com/EN/diffusion/551-Origins-of-Serious-Games.html>. Acesso
em: 29 may 2016.
DRISCOLL, Marcy P. Psychology of learning for instruction. In: .
3. ed. Florida: Pearson, 2004. cap. 1, p. 1–28. Disponível em:
<http://ocw.metu.edu.tr/pluginfile.php/8344/mod_resource/content/1/Dris_2005.pdf>. Acesso
em: 17 may 2016.
E-LEARNING. ADDIE Instructional Design Model. 2016. Disponível em:
<http://www.about-elearning.com/addie-instructional-design-model.html>. Acesso em:
10 mar. 2016.
E-LEARNING. Instructional Design Principles and Foundations. 2016. Disponível em:
<http://www.about-elearning.com/instructional-design.html>. Acesso em: 10 mar. 2016.
FILATRO, Andrea Cristina. Design instrucional contextualizado: educa-
ção e tecnologia. 3. ed. São Paulo: Senac São Paulo, 2004. Disponível em:
<http://www.editorasenacsp.com.br/portal/produto.do?appAction=vwProdutoDetalhe&idProduto=20142>
Acesso em: 4 mar. 2016.
FILATRO, Andrea Cristina. Design Instrucional na Prática. 1. ed. Pearson Education
do Brasil, 2008. Disponível em: <http://loja.pearson.com.br/design-instrucional-na-pratica-
9788576051886/p>. Acesso em: 5 nov. 2016.
FONSECA, João José Saraiva da. Metodologia da Pesquisa Científica. Ceará,
2002. 127 p. Disponível em: <http://www.ia.ufrrj.br/ppgea/conteudo/conteudo-2012-
1/1SF/Sandra/apostilaMetodologia.pdf>. Acesso em: 25 mar. 2016.
96

GARTNER INC. Gartner says worldwide software market grew 4.8 percent in 2013. Stamford/-
Connecticut, mar. 2014. Disponível em: <http://www.gartner.com/newsroom/id/2696317>.
GKRITSI, Aikaterini. Scrum Game: An Agile Software Management Game. 2011. 96 p.
Tese (MSc Software Engineering) — School of Electronics and Computer Science Faculty of
Engineering, Science and Mathematics University of Southampton, Southampton. Disponível
em: <http://eprints.soton.ac.uk/272775/1.hasCoversheetVersion/MSc_Final.pdf>. Acesso em:
29 fev. 2016.
GONçALVES, Susana. Teorias da aprendizagem. Coimbra: Mcgraw Hill, 1993.
INTULOGY. The ADDIE Process. 2016. Disponível em: <http://intulogy.com/addie/>.
KNIBERG, Henrik. Scrum and XP from the Trenches: How we do Scrum. [S.l.]: InfoQ,
2007.
KRIVITSKY, Alexey. Scrum Simulation with LEGO Bricks. 2009. Disponível em:
<http://kiev2016.agileee.org/wp-content/uploads/2011/12/Scrum-Simulation-with-LEGO-
Bricks-v2.0.pdf>. Acesso em: 23 mar. 2016.
KUBO, Olga Mitsue; BOTOMé, Sílvio Paulo. Ensino-aprendizagem: Uma intera-
ção entre dois processos comportamentais. Florianópolis, p. 1–19, 2001. Departa-
mento de Psicologia da Universidade Federal de Santa Catarina. Disponível em:
<http://revistas.ufpr.br/psicologia/article/view/3321/2665>. Acesso em: 18 may 2016.
LARMAN, Craig. Agile and Iterative Development: A Manager’s
Guide. 2. ed. Boston/MA: Pearson Education, Inc., 2004. Disponível
em: <https://books.google.com.br/books?id=76rnV5Exs50C&pg=PR5&hl=pt-
BR&source=gbs_selected_pages&cad=2#v=onepage&q&f=false>. Acesso em: 2 mar.
2016.
LARMAN, Craig; BASILI, Victor R. Iterative and incremental development: A Brief His-
tory. jun. 2003. Disponível em: <http://www.craiglarman.com/wiki/downloads/misc/history-
of-iterative-larman-and-basili-ieee-computer.pdf>. Acesso em: 2 mar. 2016.
LEITãO, Michele de Vasconcelos. Aplicação de Scrum em Ambiente de Desenvolvimento
de Software Educativo. 2010. 72 f. Monografia (Bacharel em Engenharia da Computação)
— Escola Politécnica de Pernambuco – Universidade de Pernambuco, Recife. Disponível em:
<http://tcc.ecomp.poli.br/20101/TCC_final_Michele.pdf>. Acesso em: 9 mar. 2016.
LINKEDIN. 2016. Disponível em: <https://www.linkedin.com/jobs/scrum-
jobs?trk=jserp_search_button_execute>. Acesso em: 29 fev. 2016.
LINO, Juliana Izabel. Proposta de um Jogo Edcucacional para a Área de Medição e Aná-
lise de Software. 2007. 243 f. Monografia (Bacharel em Sistemas de Informação) — Univer-
sidade Federal de Santa Catarina, Florianópolis. Disponível em: <http://www.gqs.ufsc.br/wp-
content/uploads/2011/11/2007_Juliana_Izabel_Lino.pdf>. Acesso em: 18 may 2016.
MA, Minhua; OIKONOMOU, Andreas; JAIN, Lakhmi C. Serious Ga-
mes and Edutainment Applications. Springer-Verlag, 2011. Disponível em:
<http://radar.gsa.ac.uk/2068/4/SpringerSGEdutainmentBookFront-matter.pdf>. Acesso
em: 29 may 2016.
97

MANIFESTO Ágial: Princípios por trás do Manifesto Ágil. 2001. Disponível em:
<http://www.manifestoagil.com.br/principios.html>. Acesso em: 12 mar. 2016.
MATARELLI, Maria; WHEATON, Harvey. 2015 State of Scrum Report. 2015. Disponível
em: <https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/FilesAcesso em: 16
mar. 2016.
MERRIENBOER, Jeroen J. G. Van. Training Complex Cogni-
tive Skills: A four-component instructional design model for tech-
nical training. Educational Technology Pubns, 1997. Disponível em:
<https://books.google.com.br/books/about/Training_Complex_Cognitive_Skills.html?id=o0I3IXLfXuAC&
MICHAEL, David; CHEN, Sande. Serious Games: Games That Educate,
Train, and Inform. 1. ed. Cengage Learning PTR, 2005. Disponível em:
<http://uap.unnes.ac.id/ebook/ebookpalace/Course.Technology.PTR.Serious.Games.Games.That.Educate.T
DDU/Course.Technology.PTR.Serious.Games.Games.That.Educate.Train.and.Inform.Sep.2005.eBook-
DDU.pdf>. Acesso em: 6 nov. 2016.
MOLENDA, Michael. In search of the elusive addie model. Indiana, jun. 2003. Pu-
blished in slightly amended form in Performance Improvement, May/June 2003. Disponível
em: <http://www.comp.dit.ie/dgordon/Courses/ILT/ILT0004/InSearchofElusiveADDIE.pdf>.
MORRIS, Joseph M. Software industry accounting. In: . Wiley e Book. 2.
ed. New York: John Wiley & Sons, Inc., 2001. cap. 1, p. 1–4. Disponível em:
<https://books.google.com.br/books?id=fPyXeuK3DVEC>. Acesso em: 10 mar. 2016.
NAVARRO, Emily. SimSE: A Software Engineering Simulation Environment for
Software Process Education. 2006. 321 p. Tese (Doctor of Philosophy in Information
and Computer Science) — University of California, Irvine, California. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.5381&rep=rep1&type=pdf>.
NETO, Erasmo Isotton. Scrumming: Ferramenta Educacional para Ensino de Práticas do
SCRUM. 2008. 80 f. Monografia (Bacharelado em Sistemas de Informação) — Faculdade de
Informática, Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre. Disponí-
vel em: <xps-project.googlecode.com/svn/trunk/scrum/Scrumming.pdf>. Acesso em: 4 mar.
2016.
OLIVEIRA, BRUNO CÉSAR DE. TestEG - UM SOFTWARE EDUCACIONAL
PARA O ENSINO DE TESTE DE SOFTWARE. 2013. 92 f. Monografia (Bacha-
rel em Ciência da Computação) — Universidade Federal de Lavras, LAVRAS. Dis-
ponível em: <http://www.bcc.ufla.br/wp-content/uploads/2013/09/TestEG-UM-SOFTWARE-
EDUCACIONAL-PARA-O-ENSINO-DE-TESTE-DE-SOFTWARE-.pdf>. Acesso em: 27
feb. 2016.
ORACLE. JDK Installation for Microsoft Windows. 2014. Disponível em:
<https://www.oracle.com/index.html>. Acesso em: 9 oct. 2016.
PIAZZA, ALEXIS. Melhoria de uma Unidade Instrucional para Planejamento de
Custos de Projetos de Software. 2012. 102 f. Monografia (Bacharel em Sistemas
de Informação) — Universidade Federal de Santa Catarina, Florianópolis. Disponí-
vel em: <http://www.gqs.ufsc.br/wp-content/uploads/2013/02/TCC_AlexisPiazza_vf.pdf>.
98

PMI INC. Guia PMBOK: Um Guia do Conhecimento em Gerenciamento de Proje-
tos. 5. ed. Pennsylvania: Project Management Institute, Inc., 2013. Disponível em:
<https://andreysmith.files.wordpress.com/2015/03/pmbok-5c2aa-edic3a7c3a3o.pdf>. Acesso
em: 12 mar. 2016.
PRESSMAN, Roger S. Software engineering: a practitioner’s approach. In: . 5. ed. New
York: McGraw-Hill, 2001. cap. 31, p. 829–833. Acesso em: 12 apr. 2016.
PRESSMAN, Roger S. Engenharia de software - uma abordagem profissional. In: .
7. ed. Porto Alegre: AMGH Editora Ltda, 2011. cap. 1, p. 38–45. Disponível em:
<http://www.resource.mitfiles.com/IT/IIAcesso em: 11 apr. 2016.
QUARESMA, Leandro. Processo ensino-aprendizagem: do conceito à análise do atual
processo. 2016. Disponível em: <http://www.academia.edu/4936831/Processo_Ensino-
Aprendizagem_do_Conceito_Acesso em: 17 may 2016.
RITTINGHOUSE, John W. Managing Software Deliverables: A Software Deve-
lopment Management Methodology. Massachusetts: Elsevier, 2004. Disponível em:
<https://books.google.com.br/books?id=t5VPlbBtMVIC>. Acesso em: 15 mar. 2016.
RUBIN, Kenneth S. Essential SCRUM: A Practical Guide to the Most Po-
pular Agile Process. 1. ed. Michigan: Addison-Wesley, 2013. Disponível em:
<http://deca.cuc.edu.cn/Community/media/p/17439.aspx>. Acesso em: 12 mar. 2016.
SATPATHY, Tridibesh et al. Guia SBOK: Um Guia para o Conhecimento
em Scrum. Edição 2016. Arizona: SCRUMstudy, 2016. Disponível em:
<http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2013-Portuguese.pdf>.
SAVI, Rafael. Avaliação de Jogos Voltados para a Disseminação do Conhecimento.
2011. 236 p. Tese (Doutor em Engenharia e Gestão do Conhecimento) — Uni-
versidade Federal de Santa Catarina, Programa de Pós-Graduação em Engenharia e
Gestão do Conhecimento, Santa Catarina. Disponível em: <http://btd.egc.ufsc.br/wp-
content/uploads/2011/12/RafaelSavi.pdf>. Acesso em: 12 mar. 2016.
SCHAEFER, Ben. The Latest Statistics, Surveys and Studies: Into the SCRUM.
2015. Disponível em: <https://www.pmi.org/ /media/PDF/Publications/state-of-scrum-by-the-
numbers.ashx>. Acesso em: 16 mar. 2016.
SCHNEIDER, Marcelo Frantz. SCRUM’ed: um jogo de RPG para ensinar Scrum. 2015.
98 f. Monografia (Bacharel em Sistemas de Informação) — Departamento de Informá-
tica e Estatística, Universidade Federal de Santa Catarina, Florianópolis/SC. Disponível em:
<http://www.gqs.ufsc.br/wpcontent/uploads/2011/11/TCCfinal_SCRUMed.pdf>. Acesso em:
27 fev. 2016.
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do scrum: Um guia de-
finitivo para o Scrum: As regras do jogo. Jul. 2013. Disponível em:
<http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf>.
SCHWABER, Ken; SUTHERLAND, Jeff. The scrum guide: The Defini-
tive Guide to Scrum: The Rules of the Game. Jul. 2013. Disponível em:
<http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf>. Acesso em: 26
fev. 2016.
99

SCRUM.ORG. 2016. Disponível em: <https://www.scrum.org/Courses>. Acesso em: 16 mar.
2016.
SHORE, James; WARDEN, Shane. The art of agile deve-
lopment. Mary O’Brien, San Francisco, 2008. Disponível em:
<https://poetiosity.files.wordpress.com/2011/04/art_of_agile_development.pdf>. Acesso
em: 16 mar. 2016.
SILLER, Felipe; BRAGA, Juliana Cristina. Software educacional para prá-
tica do scrum. Santo André – SP, may 2013. Disponível em: <www.br-
ie.org/pub/index.php/wcbie/article/download/2664/2318>. Acesso em: 8 jun. 2016.
SOUSA, Sónia Marlene Pereira de. Play Scrum: Um Jogo para a
Aprendizagem do Método Ágil Scrum. 2009. 84 f. Tese (Mestrado
em Informática) — Universidade do Minho, Braga. Disponível em:
<http://mei.di.uminho.pt/sites/default/files/dissertacoes/eeum_di_dissertacao_pg10919.pdf>.
THE STANDISH GROUP INTERNATIONAL INC. Chaos manifesto 2013:
Think Big, Act Small. 2013. Edição 2013 Dados de 2012. Disponível em:
<https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf>. Acesso em:
29 fev. 2016.
UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS. Métodos de Pesquisa: Curso
de Graduação Tecnológica - Planejamento e Gestão para o Desenvolvimento Rural. Rio
Grande do Sul, 2009. 120 p. (EAD, Série Educação a Distância). Disponível em:
<http://www.ufrgs.br/cursopgdr/downloadsSerie/derad005.pdf>. Acesso em: 25 mar. 2016.
WANGENHEIM, Christiane Gresse von. learning game-based. jul. 2012. Dis-
ponível em: <http://www.inf.ufsc.br/ c.wangenheim/download/CSBC2012-
ComoEnsinarComJogos_Wangenheim_vf.pdf>. Acesso em: 23 mar. 2016.
WANGENHEIM, Christiane Gresse von. SCRUMIA: An Educational Game for Tea-
ching SCRUM in Computing Courses. 2013. Disponível em: <http://www.gqs.ufsc.br/wp-
content/uploads/2013/06/SCRUMIA-Description-vE20-2013.pdf>. Acesso em: 23 mar. 2016.
WIKIPEDIA. Software development. ago. 2014. Disponível em:
<https://en.wikipedia.org/wiki/Software_development>. Acesso em: 28 fev. 2016.
WIKIPEDIA. ADDIE Model. 2016. Disponível em: <https://en.wikipedia.org/wiki/ADDIE_Model>.
WIKIPEDIA. Educational game. 2016. Disponível em:
<https://en.wikipedia.org/wiki/Educational_game>. Acesso em: 9 mar. 2016.
WIKIPEDIA. Educational technology. 2016. Disponível em:
<https://en.wikipedia.org/wiki/Educational_technology>. Acesso em: 9 mar. 2016.
WIKIPEDIA. Ensino. 2016. Disponível em: <https://pt.wikipedia.org/wiki/Ensino>. Acesso
em: 11 may 2016.
WIKIPEDIA. Game. 2016. Disponível em: <https://en.wikipedia.org/wiki/Game>. Acesso
em: 9 mar. 2016.
100

A CONTEÚDO EDUCACIONAL PARA O JOGO PLAY’ED-SCRUM’CES - PARTE
PRÁTICA
Esta parte do conteúdo educacional para o jogo PLAY’ed-SCRUM’ces é composta por pergun-
tas/questões “fechadas”, distribuídas entre 3 “níveis” de dificuldade. Com as perguntas do nível
1 apresentando o menor grau de dificuldade, as perguntas do nível 2 com um grau de dificul-
dade maior que aquelas do primeiro, e no terceiro e último nível as perguntas de mais alto grau
de dificuldade. As perguntas “fechadas” possuem um número de alternativas/opções variando
de 5 até 8, sendo que os níveis 1 e 2 são compostos por 15 perguntas cada e o terceiro nível é
composto por 19 perguntas.
Peguntas do nível 1
Dentre as práticas fundamentais para a adoção/implantação da metodologia do framework Scrum
destacam-se os Eventos do Scrum, os Artefatos do Scrum e os Papéis do Scrum.
Os eventos Scrum são “fechados” (time-boxed) com uma duração mínima e máxima previa-
mente estabelecidos, e objetivam, entre outras coisas, a definição de uma rotina/ciclo evitando
a necessidade de eventuais encontros não planejados. Além disso, uma outra principal carac-
terística destes eventos é tornar as práticas/processos do Scrum o mais transparentes possível
para todas as partes integrantes/interessadas. Considerando estas ponderações e o conhecimento
adquirido sobre tais conceitos do Scrum, escolha a alternativa que melhor define cada um dos
eventos do Scrum nas questões que se seguem.
1. O evento Reunião Diária é?
a) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá o
trabalho a ser realizado durante o ciclo e que possui um time-boxed de no máximo 8
horas.
b) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao final
de um ciclo, participam o Time Scrum e Stakeholders e onde uma versão do produto será
apresentada para avaliação e disponibilização ao cliente.
c) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-
mento sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentos
e programa as tarefas para o dia seguinte.
d) Um evento considerado como o principal do Scrum, representando um ciclo completo
do Scrum e um “contêiner” para outros eventos, possui um time-boxed com duração de
no máximo um mês e durante o qual uma versão utilizável do produto será desenvolvida.
e) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui um
time-boxed de no máximo 3 horas de duração e representa uma oportunidade para rever o
trabalho que foi realizado durante um ciclo. Dessa forma possibilitando ao Time Scrum
identificar e adotar práticas, que serão implementadas no próximo ciclo, para melhorar o
trabalho/desempenho do mesmo.
2. O evento Retrospectiva do Ciclo Scrum é?
102

a) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui um
b) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-
c) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá o
horas.
d) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao final
e) Um evento considerado como o principal do Scrum, representando um ciclo completo
3. O evento Revisão do Ciclo Scrum é?
a) Um evento considerado como o principal do Scrum, representando um ciclo completo
b) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui um
c) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao final
d) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá o
horas.
e) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-
4. O evento Sprint é?
a) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui um
103

b) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao final
c) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-
d) Um evento considerado como o principal do Scrum, representando um ciclo completo
e) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá o
horas.
5. O evento Reunião de Planejamento do Ciclo é?
a) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-
b) Um evento considerado como o principal do Scrum, representando um ciclo completo
c) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá o
horas.
d) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao final
e) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui um
Os Artefatos do Scrum representam o trabalho e/ou o “valor do negócio”, e permitem mais
transparência e oportunidades para inspeções e adaptações. Considerando estas ponderações
e o conhecimento adquirido sobre tais conceitos do Scrum, escolha a alternativa que melhor
define cada um dos Artefatos do Scrum nas questões que se seguem.
6. O Artefato Taskboard é?
a) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-
vidades planejadas para o Sprint, possibilitando o acompanhamento das mesmas. Este
recurso deverá está acessível a todos os colaboradores e ser atualizado constantemente.
104

b) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-
cionados de um lista maior. Os itens presentes nesta lista determinam as funcionalidades
que devem estar presentes na próxima versão do produto e possuem uma estimativa do
trabalho que será necessário para que o objetivo seja atingido.
c) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-
sibilita a detecção de possíveis desvios e deve ser atualizado diariamente. Neste gráfico
o eixo vertical representa uma estimativa do esforço/trabalho restante em horas e o eixo
horizontal representa os dias que compreendem o Sprint atual.
d) Representa o conjunto de todos os requisitos/funcionalidades completados até o Sprint
atual, somados com todos aqueles que já foram desenvolvidos nos Sprint’s passados,
resultando em uma nova versão utilizável do produto.
e) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário
(funções, requisitos, melhorias etc) para ao desenvolvimento do produto ou serviço. Esta
lista é muito dinâmica, mudando constantemente para representar o que o produto neces-
sita e existirá enquanto este existir. Os itens presentes nesta lista possuem os atributos de
descrição, ordem, estimativa e valor.
7. O Artefato Incremento do Produto é?
a) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-
b) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário
c) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-
e) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-
8. O Artefato Backlog do Sprint é?
a) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário
105

b) Um gráﬁco que representa o progresso dos trabalhos/esforços durante um Sprint, pos-
c) Representa o conjunto de todos os requisitos/funcionalidades completados até o Sprint
d) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-
e) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-
9. O Artefato Burndown Chart é?
a) Um gráﬁco que representa o progresso dos trabalhos/esforços durante um Sprint, pos-
b) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-
c) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário
e) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-
10. O Artefato Backlog Priorizado do Produto é?
a) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-
b) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário
106

c) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-
d) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-
e) Representa o conjunto de todos os requisitos/funcionalidades completados até o Sprint
atual, somados com todos aqueles que já foram desenvolvidos nos Sprint’s passados, re-
sultando em uma nova versão utilizável do produto.
Os Papéis do Scrum são/estão associados ao Time Scrum, que representa grupo(s) auto-organizáveis
e multifuncionais. Um grupo auto-organizável é o responsável por definir a melhor forma para
concluir seu trabalho e portanto não precisa ser gerenciado por alguém fora do grupo. Em um
grupo multifuncional os membros são providos de todas as habilidades necessárias para com-
pletar seu trabalho e portanto não dependem de pessoas de fora do grupo. O modelo de time no
Scrum foi pensado para melhorar a flexibilidade, criatividade e produtividade de seus integran-
tes. Além dos Papéis-Centrais do Scrum existem também os Papéis Não-Essenciais no Scrum,
considerados como sendo não obrigatórios para um projeto Scrum e/ou por não estarem con-
tinuamente/diretamente envolvidos no processo Scrum. Considerando estas ponderações e o
conhecimento adquirido sobre tais conceitos do Scrum, escolha a alternativa que melhor define
cada um dos Papéis do Scrum nas questões que se seguem.
11. O Papel Scrum Master é?
a) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-
petências essenciais da organização do projeto.
b) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-
preensão e criação da Visão do Projeto. Colaboram com o Time Scrum na definição/iden-
tificação dos requisitos de funcionalidades que deverão estar presentes na versão final do
produto. Esperam que suas necessidades sejam “traduzidas” para o produto final de tal
forma que este poça proporcionar o maior valor possível para o seu negócio.
c) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade do
Scrum. Trabalha para que as teorias, práticas e regras do Scrum sejam compreendidas e
executadas por todos, tanto por parte dos integrantes do Time Scrum quanto por aqueles
de fora do Time. Atua como um facilitador para o Time Scrum na realização de suas
atividades.
d) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-
cremento utilizável do “produto” no final de cada ciclo Sprint. São auto-organizados e
multifuncionais, são eles próprios os responsáveis por organizar e gerenciar seu próprio
trabalho. Deve ser composto por um grupo com um mínimo de 3 e máximo de 9 colabo-
radores.
107

e) O responsável, entre outras coisas, por maximizar o valor do negócio para o projeto,
mantendo sua justiﬁcativa de negócio e garantindo que o Time Scrum entregue valor
para o negócio do cliente. Representa a voz do cliente e portanto é o articulador das
necessidades e prioridades deste para com o Time Scrum. É também o único responsável
por gerenciar o Backlog do Produto.
12. O Papel Stakeholders é?
a) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-
b) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade do
atividades.
c) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-
radores.
d) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-
13. O Papel Fornecedores é?
a) O responsável, entre outras coisas, por maximizar o valor do negócio para o projeto,
b) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-
c) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-
108

d) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade do
atividades.
e) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-
radores.
14. O Papel Equipe de Desenvolvimento é?
a) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-
b) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-
radores.
c) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade do
atividades.
d) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-
15. O Papel Produto Owner é?
a) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-
radores.
b) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-
109

c) O responsável, entre outras coisas, por maximizar o valor do negócio para o projeto,
d) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade do
atividades.
e) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-
Como dito anteriormente dentre as práticas fundamentais para a adoção/implantação da meto-
dologia do framework Scrum destacam-se os Eventos do Scrum, os Artefatos do Scrum e os
Paipéis do Scrum.
Considerando as relações/interações entre as práticas Eventos do Scrum com os Artefatos do
Scrum bem como de suas implicações, responda as questões que se seguem.
Obs – Deverão ser marcadas o máximo de alternativas possíveis.
1. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao ﬁnal do evento Retrospectiva
do Sprint?
a) Burndown Chart.
b) Backlog do Sprint.
c) Taskboard.
d) Backlog do Produto.
e) Incremento do Produto.
2. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao ﬁnal do evento Reunião Diá-
ria?
a) Taskboard.
b) Incremento do Produto.
c) Burndown Chart.
110

d) Backlog do Sprint.
e) Backlog do Produto.
3. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Sprint?
a) Incremento do Produto.
c) Backlog do Produto.
d) Taskboard.
e) Burndown Chart.
4. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Revisão do
Sprint?
a) Taskboard.
b) Backlog do Produto.
c) Burndown Chart.
d) Incremento do Produto.
e) Backlog do Sprint.
5. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Reunião de
Planejamento do Sprint?
a) Backlog do Sprint.
b) Taskboard.
d) Incremento do Produto.
e) Burndown Chart.
Considerando agora as relações/interações entre as práticas Eventos do Scrum com os Papéis
do Scrum bem como de suas implicações, responda as questões que se seguem.
6. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Retros-
pectiva do Sprint?
a) Stakeholders.
111

b) Scrum Master.
c) Fornecedores.
d) Produto Owner.
e) Equipe de Desenvolvimento.
7. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Reunião
Diária?
a) Fornecedores.
b) Stakeholders.
c) Scrum Master.
d) Equipe de Desenvolvimento.
e) Produto Owner.
8. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Revisão
do Sprint?
a) Produto Owner.
b) Scrum Master.
c) Equipe de Desenvolvimento.
d) Stakeholders.
e) Fornecedores.
9. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Reunião
de Planejamento do Sprint?
a) Equipe de Desenvolvimento.
b) Stakeholders.
c) Produto Owner.
d) Fornecedores.
e) Scrum Master.
10. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Sprint?
a) Scrum Master.
b) Produto Owner.
c) Stakeholders.
112

d) Fornecedores.
e) Equipe de Desenvolvimento.
Considerando agora as relações/interações entre as práticas Artefatos do Scrum com os Papéis
do Scrum bem como de suas implicações, responda as questões que se seguem.
11. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Stakeholders?
a) Backlog do Produto.
c) Taskboard.
d) Nenhum arterfato.
e) Backlog do Sprint.
f) Burndown Chart.
12. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Equipe de Desenvolvimento?
a) Taskboard.
b) Burndown Chart.
d) Backlog do Sprint.
e) Incremento do Produto.
f) Nenhum arterfato.
13. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Produto Owner?
a) Backlog do Sprint.
c) Burndown Chart.
d) Nenhum arterfato.
e) Taskboard.
f) Backlog do Produto.
14. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Fornecedores?
113

a) Backlog do Produto.
c) Incremento do Produto.
d) Burndown Chart.
e) Nenhum arterfato.
f) Taskboard.
15. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Scrum Master?
a) Nenhum arterfato.
b) Burndown Chart.
c) Incremento do Produto.
d) Backlog do Produto.
e) Taskboard.
f) Backlog do Sprint.
O Framework Scrum é formado por três “conjuntos de métodos/práticas” que constituem os
fundamentos para esta metodologia. Este “conjuntos” são:
• Os Princípios do Framework Scrum;
• Os Aspectos do Framework Scrum; e
• Os Processos do Framework Scrum.
Os princípios do Scrum são imutáveis, devem ser seguidos a risca, enquanto que os aspectos
e processos do Scrum podem ser modiﬁcados para atender/adequar aos requisitos de projeto
e/ou organizacionais. A compreensão das relações entre estes “conjuntos” são de fundamental
importância para o entendimento do framework Scrum.
Considerando estas ponderações e o conhecimento adquirido sobre tais conceitos do Scrum,
escolha a alternativa que melhor se aplica a cada um destes “conjuntos de métodos/práticas” do
Framework Scrum nas questões que se seguem.
1. Quais são os Princípios do Framework Scrum?
a) Transparência; Inspeção; Adaptação.
b) Criar o Backlog Priorizado do Produto; Criar o Backlog do Sprint; Criar os Entregá-
veis; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.
114

c) Iniciar; Planejar e Estimar; Implementar; Revisão e Retrospectiva; Release.
d) Controle de Processos Empíricos; Auto-organização; Colaboração; Priorização Base-
ada em Valor; Time-boxing; Desenvolvimento Iterativo.
e) Organização; Justificativa de Negócio; Qualidade; Mudanças; Riscos.
2. Quais são os Aspéctos do Framework Scrum?
a) Iniciar; Planejar e Estimar; Implementar; Revisão e Retrospectiva; Release.
b) Controle de Processos Empíricos; Auto-organização; Colaboração; Priorização Base-
c) Transparência; Inspeção; Adaptação.
d) Organização; Justificativa de Negócio; Qualidade; Mudanças; Riscos.
e) Criar o Backlog Priorizado do Produto; Criar o Backlog do Sprint; Criar os Entregá-
Os Processos do Framework Scrum incluem as atividades/práticas aplicadas durante um projeto
Scrum e a ordem em que as mesmas são empregadas. Ao todo são dezenove processos dividi-
dos/agrupados em fases.
Considerando mais estas ponderações e o conhecimento adquirido sobre tais conceitos do
Scrum, escolha uma alternativa na questão a seguir.
3. Quais são as fases em que os Processos do Framework Scrum estão agrupados?
a) Organização; Justificativa de Negócio; Qualidade; Mudanças; Riscos.
b) Iniciar; Planejar e Estimar; Implementar; Revisão e Retrospectiva; Release.
c) Transparência; Inspeção; Adaptação.
d) Controle de Processos Empíricos; Auto-organização; Colaboração; Priorização Base-
e) Criar o Backlog Priorizado do Produto; Criar o Backlog do Sprint; Criar os Entregá-
Como dito anteriormente dentre as práticas fundamentais para a adoção/implantação da me-
todologia do framework Scrum destacam-se os eventos, artefatos e papéis. Estas práticas são
parte integrante dos princípios, aspectos e processos do framework Scrum e portanto definidas
por estes “conjuntos” de métodos/práticas. Os eventos são definidos pelos princípios do fra-
mework, os artefatos são definidos pelos processos do framework, e os papéis pelos aspectos
do framework Scrum.
115

Considerando tais ponderações e o conhecimento adquirido sobre tais conceitos do Scrum, es-
colha uma alternativa nas questões que se seguem.
4. Qual dos Princípios do Framework Scrum define os Eventos?
a) Controle de Processos Empíricos.
b) Auto-organização.
c) Colaboração.
d) Priorização Baseada em Valor.
e) Time-boxing.
f) Desenvolvimento Iterativo.
5. Qual dos Aspectos do Framework Scrum define os Papéis?
a) Organização.
b) Justificativa de Negócio.
c) Qualidade.
d) Mudanças.
e) Riscos.
As teorias empíricas utilizadas para controle de processos, são as teorias aplicadas na funda-
mentação do framework Scrum. O empirismo declara que o conhecimento se constrói a partir
de experiências e que as decisões deverão ser tomadas baseado neste conhecimento. O controle
de processos empíricos é apoiado por três pilares que são:
• Transparência;
• Inspeção; e
• Adaptação.
No framework Scrum estes pilares fazem parte do princípio Controle de Processos Empíricos.
Considerando tais ponderações e o conhecimento adquirido sobre tais conceitos do Scrum, es-
colha uma alternativa na questão que se segue.
6. Quais são as práticas do Framework Scrum em que os pilares do empirismo melhor se
aplicam?
a) Eventos.
b) Artefatos.
116

c) Papeis.
d) Eventos e Artefatos.
f) Eventos e Papéis.
g) Artefatos e Papéis.
Como dito anteriormente os Processos do Scrum incluem as atividades/práticas aplicadas du-
rante um projeto Scrum e a ordem em que as mesmas são empregadas. Ao todo são dezenove
processos divididos/agrupados em fases. As fases em que estes processos estão agrupados são:
1. Iniciar;
2. Planejar e Estimar;
3. Implementar;
4. Revisão e Retrospectiva; e
5. Release.
escolha uma alternativa nas questões que se seguem.
7. Quais são os processos do Framework Scrum agrupados na fase Iniciar?
a) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizado
do Produto.
b) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.
c) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar o
Time Scrum; Desenvolver os Épicos; Criar o Backlog Priorizado do Produto; Conduzir o
Planejamento da Release.
d) Enviar os Entregáveis; Retrospectiva do Projeto.
e) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;
Criar as Tarefas; Estimar as Tarefas; Criar o Backlog do Sprint.
8. Quais são os processos do Framework Scrum agrupados na fase Planejar e Estimar?
a) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.
b) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizado
do Produto.
c) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;
d) Enviar os Entregáveis; Retrospectiva do Projeto.
117

e) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar o
9. Quais são os processos do Framework Scrum agrupados na fase Implementar?
a) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;
b) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizado
do Produto.
c) Enviar os Entregáveis; Retrospectiva do Projeto.
d) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar o
e) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.
10. Quais são os processos do Framework Scrum agrupados na fase Revisão e Retrospectiva?
a) Enviar os Entregáveis; Retrospectiva do Projeto.
b) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;
c) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.
d) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizado
do Produto.
e) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar o
11. Quais são os processos do Framework Scrum agrupados na fase Release?
a) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar o
b) Enviar os Entregáveis; Retrospectiva do Projeto.
c) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;
d) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.
e) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizado
do Produto.
Para cada um dos dezenove processos do framework Scrum existem as entradas, ferramentas e
saídas. Sendo que:
118

entradas - representam os pré-requisitos para originar o produto/resultado do processo;
ferramentas - representam os recursos necessários; e
saídas - representam os produtos/resultados do processo.
responda as questões que se seguem.
12. Considere as entradas, ferramentas e saídas a seguir:
Entradas Ferramentas Saídas
-Time Central do Scrum -Expertise do Time -Entregável/Incremento do
Sprint
-Backlog do Sprint -Scrumboard/Taskboard Atuali-
zado
-Scrumboard/Taskboard -Registro de Impedimentos Atu-
alizado
-Registro de Impedimentos
Dentre as opções de processos a seguir, selecione aquele cujas entradas, ferramentas e
saídas, citadas acima, o representam ?
a) Criar a Visão do Projeto.
b) Identiﬁcar o Scrum Master e o(s) Stakeholder(s).
c) Criar o Backlog Priorizado do Produto.
d) Criar o Backlog do Sprint.
e) Criar os Entregáveis/Incrementos.
f) Conduzir a Reunião Diária.
g) Demonstrar e Validar o Sprint.
h) Retrospectiva do Sprint.
-Time Central do Scrum -Reunião de Revisão do Sprint -Entregáveis Aprovados e Acei-
tos
-Entregáveis do Sprint
-Backlog do Sprint
-Critério de Pronto
-Critérios de Aceitação da Estó-
ria de Usuário 119

-Time Central do Scrum -Reunião de Planejamento do
Sprint
-Backlog do Sprint
-Lista de Tarefas de Esforço Es-
timado
-Gráﬁco Burndown do Sprint
-Duração do Sprint
120

-Scrum Master -Reunião de Retrospectiva do
Sprint
-Pontos de Melhorias Acorda-
dos
-Equipe de Desenvolvimento do
Scrum
-“Saídas/Meios” de Demonstrar
e Validar o Sprint
-Declaração da Visão do Projeto -Critérios de Seleção -Scrum Master é Identiﬁcado
-Produto Owner -Stakeholder(s) é(são) Identiﬁ-
cados
121

-Equipe de Desenvolvimento do
Scrum
-Reunião Diária -Gráfico Burndown do Sprint
Atualizado
-Scrum Master -Três Perguntas Diárias -Registro de Impedimentos Atu-
alizado
-Gráfico Burndown do Sprint
-Registro de Impedimentos
-Caso de Negócios do Projeto -Reunião da Visão do Projeto -Declaração da Visão do Projeto
-Produto Owner é Identificado
122

-Time Central do Scrum -Métodos de Priorização de Es-
tórias de Usuário
-Backlog Priorizado do Produto
-Épicos -Critério(s) de Pronto
-Personas
123

B CONTEÚDO EDUCACIONAL PARA O JOGO PLAY’ED-SCRUM’CES - PARTE
TEÓRICA
Esta parte do conteúdo educacional para o jogo PLAY’ed-SCRUM’ces é composta por toda a
subseção 2.3 do capítulo 2 deste trabalho. E foi estruturada, para ser exibida no jogo, com a
mesma sequência apresentada por esta subseção.
124

TCC Aporano Play'ed SCRUM'ces

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a TCC Aporano Play'ed SCRUM'ces (20)

Último (20)

TCC Aporano Play'ed SCRUM'ces