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”/definição (planejamento e execução) de um programa de medição para aplicação em um
ambiente fictí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
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 figura 14)
Público-Alvo Estudantes de Processos de Medição e Análise de Software
Modo de Interação Único Jogador/Individual
Idioma Disponível Português
Duração Aproximadamente 2 horas
Resultados de Avaliações N/A
Linguagem N/A
Tipo de Jogo Digital
Gênero/Categoria do Jogo Simulação
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

TCC Aporano Play'ed SCRUM'ces

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a TCC Aporano Play'ed SCRUM'ces

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

Último

Último (20)

TCC Aporano Play'ed SCRUM'ces