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/OUAUXILIAR O ENSINO-APRENDIZAGEM DE SCRUM

Belo Horizonte - MG8 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




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


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ífica . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Camadas da Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . 223 Projeto de Fase Única . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Processos para Gerenciamento de Projetos . . . . . . . . . . . . . . . . . . . 275 Exemplo de Backlog Priorizado do Produto . . . . . . . . . . . . . . . . . . . 306 Exemplo de Backlog do Sprint . . . . . . . . . . . . . . . . . . . . . . . . . 317 Exemplo de Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Exemplo de Taskboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Fluxo de Execução do Scrum para um Projeto . . . . . . . . . . . . . . . . . 3310 Fundamentação do Framework Scrum . . . . . . . . . . . . . . . . . . . . . . 3411 Princípios do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3512 Processos do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3713 Fases do modelo ADDIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4514 Categorias do domínio cognitivo segundo a taxonomia de Bloom (1956) . . . 4715 Diagrama Entidade Relacionamento - DER . . . . . . . . . . . . . . . . . . . 7016 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7117 Diagrama de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7218 Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7719 Tela de Boas Vindas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7820 Regras do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7921 Conteúdo de Estudo do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 8022 Tela de Início de uma Nova Partida . . . . . . . . . . . . . . . . . . . . . . . 8123 Botões de Navegação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8224 Primeira e Última Telas do Nível 2 e 3 . . . . . . . . . . . . . . . . . . . . . 8325 Resultados de uma Partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8526 Tela de uma Partida Pausada . . . . . . . . . . . . . . . . . . . . . . . . . . . 8627 Tela de uma Partida sendo Parada . . . . . . . . . . . . . . . . . . . . . . . . 8728 Visualização de uma Partida . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Lista de Tabelas

1 Processos da Fase Iniciar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Processos da Fase Planejar e Estimar . . . . . . . . . . . . . . . . . . . . . . 393 Processos da Fase Implementar . . . . . . . . . . . . . . . . . . . . . . . . . 404 Processos da Fase Revisão e Retrospectiva . . . . . . . . . . . . . . . . . . . 405 Processos da Fase Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Informações sobre o jogo SimSE . . . . . . . . . . . . . . . . . . . . . . . . 507 Informações sobre o jogo X-MED . . . . . . . . . . . . . . . . . . . . . . . . 528 Informações sobre o jogo TestEG . . . . . . . . . . . . . . . . . . . . . . . . 539 Informações sobre o jogo SCRUM-Scape . . . . . . . . . . . . . . . . . . . . 5510 Informações sobre o jogo SCRUM’ed . . . . . . . . . . . . . . . . . . . . . . 5611 Informações sobre o jogo Scrum Game . . . . . . . . . . . . . . . . . . . . . 5812 Informações sobre o jogo Scrumming . . . . . . . . . . . . . . . . . . . . . . 6213 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 111.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 Escopo/Limites do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Métodos de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.1 Tipos de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.2 Etapas de uma Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.3 Pesquisa Empregada neste Trabalho . . . . . . . . . . . . . . . . . . . . 18

1.5 Estrutura deste Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 FUNDAMENTAÇÃO TEÓRICA PARA ES/GP/SCRUM 222.1 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.1 Processo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.2 Métodos/Práticas da Engenharia de Software . . . . . . . . . . . . . . . 232.1.3 Ferramentas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Gerência de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.2 Gerência de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.3 Ciclo de Vida do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.4 Processos para Gerenciamento de Projetos . . . . . . . . . . . . . . . . . 26

2.3 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.1 Teoria do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.2 Principais Componentes do Scrum . . . . . . . . . . . . . . . . . . . . . 282.3.3 Visão Geral do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.4 O Framework SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 FUNDAMENTAÇÃO TEÓRICA PARA EA/JE 423.1 Ensino-Aprendizagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.1 Design Instrucional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.1.2 O Padrão/Modelo ADDIE . . . . . . . . . . . . . . . . . . . . . . . . . 443.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 504.1 JE para o Ensino-Aprendizagem de ES . . . . . . . . . . . . . . . . . . . . . . . 504.2 JE para o Ensino-Aprendizagem de SCRUM . . . . . . . . . . . . . . . . . . . . 54

5 DESENVOLVIMENTO/CRIAÇÃO DO JOGO PLAY’ed-SCRUM’ces 665.1 Análise/Projeto Instrucional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.1.1 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.1.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Desenvolvimento Instrucional . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.2.1 Diagramas do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . . . . . . 695.2.2 Regras do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . . . . . . . . 725.2.3 Fundamentação teórica sobre a tecnologia Android/Java . . . . . . . . . 745.2.4 Dinâmica do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . . . . . . 77

6 CONCLUSÕES E TRABALHOS FUTUROS 906.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.1.1 Algumas ponderações . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.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 sociedadescontemporâneas. Modificando, alterando, aumentando etc; a forma como pensamos, agimos einteragimos nestas sociedades. A influência abrange e provavelmente vai além dos contextossociais, políticos e econômicos. Com essa importância segue-se a necessidade, cada vez maiscrescente, de se produzir produtos, bens e serviços em quantidade, qualidade e complexidadecada vez maiores.

Em conjunto com esse desenvolvimento da Indústria de Software segue-se a necessidadede 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 melhorqualidade 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 vendona exigência de uma melhor qualificação a respeito deste método. No entanto, o mercado desoftware ainda carece de tais profissionais qualificados com os conhecimentos necessários parao emprego desta metodologia.

Atualmente alguns modelos de ensino estão sendo utilizados para a aprendizagem doSCRUM, mas que na sua maioria são muito teóricos e manuais. Uma alternativa que está setornando 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 comum ambiente próximo ao que estes profissionais irão encontrar na prática. Possibilitando comisso, de forma efetiva, auxiliar o ensino-aprendizagem de conceitos e práticas do SCRUM econsequente capacitação de profissionais nesta metodologia.

Portanto este trabalho objetiva o desenvolvimento de um jogo educativo digital paradispositivos móveis Android (Smartphone/Tablet), para avaliar/auxiliar o ensino-aprendizagemde conceitos sobre a metodologia ágil SCRUM. Para o planejamento e desenvolvimento dojogo será empregada uma metodologia de ensino-aprendizagem, que possibilitará a criação deum 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 noano 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 receitasobtidas com vendas de Produtos de Software ao “usuário final” saltarão de $169 bilhões em1999 para $343 bilhões em 2004. Essas receitas continuaram a apresentar taxas significativasde crescimento nos anos seguintes até que em 2013, no mundo, elas alcançaram cerca $407,3bilhões o que corresponde há um aumento de 4,8% sobre o montante em receitas movimentadoem 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çãoBrasileira de Empresas de Software - ABES (ABES SOFTWARE, 2015). Para o mercado internode 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 oitavamaior economia do Setor (ABES SOFTWARE, 2015).

Nessa Indústria apesar das cifras com as receitas serem tão volumosas e significativastambé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 em2012; menos da metade dos projetos de software, cerca de 39%, obtiveram o sucesso esperado, oque significa que foram entregues dentro do prazo, sem “estourar” o orçamento e apresentandoos requisitos e funcionalidades estimados; 43% tiveram algum tipo de mudança/alteração nodecorrer 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 aindaforam entregues mas não foram utilizados. O que caracteriza entre outras coisas a presença defalhas nas metodologias e/ou processos e/ou métodos empregados para o desenvolvimento egerência de projetos de softwares.

Considerando ainda que o mercado vem exigindo cada vez mais produtos e serviçoscom maior qualidade, quantidade e complexidade e em escalas cada vez crescentes segue-sea necessidade, segundo (CMS - CENTER FOR MEDICARE & MEDICAID SERVICES, 2005), de umamelhor/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 Gerenciamentode Projetos de Software.

Segundo (PMI INC., 2013), “Projeto é um esforço temporário empreendido para criarum 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 daexecuçã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 podemoscitar 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 dagerê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 deCiclo de Vida, Metodologias e Processos (WIKIPEDIA, 2014). Sabendo-se então que a definiçãodos processos se dá através do emprego de tais abordagens e que os mesmos podem ser maisadaptados/adequados ao gerenciamento de determinados projetos, dependendo do nicho/áreaem 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). Dessaforma faz-se necessário uma avaliação para se determinar qual abordagem se adapta melhor adeterminados 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 àquelasabordagens baseadas no Modelo em Cascata (LARMAN; BASILI, 2003). Essa preferência talvezseja explicada devido entre outros fatores às metodologias tradicionais serem baseadas em umconjunto de crenças/valores que não são compatíveis com incertezas inerentes a muitos projetosde desenvolvimento de software (RUBIN, 2013). Enquanto que as metodologias ágeis se valemdessas 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 asatisfação do cliente como principal prioridade (MANIFESTO. . . , 2001).

Dentre as metodologias ágeis podemos destacar a utilização/aceitação cada vez maiscrescente do método de desenvolvimento ágil SCRUM (SCHAEFER, 2015). Atualmente diversasorganizaçõ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 abordagemiterativa 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 temcomprovadamente obtido vários benefícios dos quais se destacam: satisfação do cliente, maiorretorno 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 doSCRUM, que será alcançado a partir de muitas experiências vivenciadas na prática, através dautilizaçã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 destemétodo. Mas como citado anteriormente o domínio em SCRUM não será obtido de formatrivial, 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 formateórica devido ao curto tempo de duração dessas disciplinas, não sendo possível portando umaabordagem mais ampla/profunda e de forma mais prática e mais próximo ao que acontece defato 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/manuaise 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 constatadoem 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ênciasexigidos, entre outros, estão relacionados à metodologia SCRUM. A adoção de metodologiasmenos teóricas/manuais e mais práticas/interativas pode facilitar o aprendizado Neto (2008); edessa 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 parasuperar/diminuir os desafios encontrados no ensino-aprendizagem de ES/SCRUM é a utilizaçãode jogos Savi (2011). Os jogos apresentam várias características e potenciais como: capacidadede divertir, entreter, centrados no jogador/usuário, despertam a atenção, motivam, desafiam, altaiteratividade etc; e quando determinados conteúdos de ensino são “inseridos” de forma eficaznestes ambientes/cenários iterativos e dinâmicos possibilita fazer com que o aprendizado sejaincentivado 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 durantesua imersão no contexto do jogo Schneider (2015). Permitindo com que o aprendizado ocorraatravé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 desafiosaumentando com isso a satisfação de aprender e podem ainda “apontar/mostrar” dificuldadesdo jogador/aluno em relação a determinados assuntos Camargo (2013). Jogos utilizados comorecursos 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 qualserá possível seguir explorando e experimentando novas “oportunidades” sem correr “riscos” eassimilar 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 jogoscomputacionais, 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 àsde: ação, aventura, RPG, simulação etc (WIKIPEDIA, 2016e). Por meio de uma revisão rápidada literatura é possível constatar que os jogos estão cada vez mais sendo empregados comorecursos didáticos. Em relação a ES não é diferente e o emprego desses recursos para auxiliarno 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 projetode desenvolvimento, onde o jogador assumirá o papel do Scrum Master com limitaçõesem suas atividades já que o mesmo não será o responsável por determinar quais recursosirã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 maistarefas 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ídosa partir de histórias contadas por usuários;

• SCRUM Game, Gkritsi (2011), um jogo para simular o gerenciamento de projetos noqual os jogadores assumem o papel do Scrum Master, o qual será o responsável porgerenciar uma equipe, auxiliando-a nas estimativas e atribuição das tarefas de acordocom 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êsníveis em que o jogador para alcançar o próximo nível deverá responder corretamente asperguntas ou enfrentar um “inimigo”, este jogo permite ao jogador reafirmar conceitosbá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 umSprint em que o jogador, que assume o papel Scrum Master, tem como objetivo auxiliara equipe de desenvolvimento na execução de suas tarefas como por exemplo na remoçãode eventuais obstáculos enfrentados pela equipe; etc.

Pelo motivos expostos dos quais destacam-se: a importância da Indústria de Softwarenas 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 ágeiscomo o SCRUM; e na adoção dos jogos, devido a sua popularidade, para auxiliar no ensinoaprendizado 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 trabalhosrelacionados, de resultados promissores. Pretende-se com este trabalho o desenvolvimento deum 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/auxiliaro 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 arespeito 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çãodeste jogo/aplicativo em outros dispositivos móveis, baseados em outras plataformas e/ousistemas 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 ágeisempregadas 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 dogê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 pesquisascientí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 dapesquisa 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)

aQuivy & 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 depesquisa 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 problemaespecí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-aprendizagemde conceitos sobre SCRUM (resolver/solucionar a não aprendizagem total/parcial a respeito deconceitos 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 Etapa2 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 osJogos 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, conhecidoscomo Jogos Educacionais, como recursos didáticos. A seguir as atividades que compõem estaetapa:

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-aprendizagemde ES/SCRUM (como parte da Etapa 2 na Figura 1)

Será feita uma análise sobre os JE existentes na literatura para o ensino-aprendizagemda 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 subetapasque 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 comose dará a sequência do mesmo durante a dinâmica do jogo e quais serão as estratégiasinstrucionais.

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 seguiras 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óveisAndroid (como parte da Etapa 4 na Figura 1)

Pesquisar, levantar material e estudar para compreender as tecnologias utilizadas paraprogramação de aplicativos voltados para dispositivos móveis Android. A seguir as atividadesque 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 meiode 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 oensino-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 nodesenvolvimento 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 comparativado que se propôs a fazer com o que de fato foi feito/realizado e propostas de possíveistrabalhos 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 existentepara 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 tecnologiabaseada em camadas (Figura 2), cuja fundamentação/base deverá ser/ter o foco na qualidadequando na definição de processos, métodos/práticas e ferramentas para o apoio da mesma. Coma aplicação desses recursos, definidos por essas “camadas”, será possível o desenvolvimentode 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çãodos métodos/práticas da engenharia de software. A camada de métodos fornece informaçõestécnicas e envolvem tarefas como: comunicação, requisitos, modelagem, implementação, testese suporte. Já a camada de ferramentas dará o suporte necessário para as outras duas camadas deforma 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 objetivamproduzir um produto como resultado. Uma atividade poderá ser empregada independe do campode 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 deprocesso de software, em um artefato de software. Para uma tarefa caberá a responsabilidadede 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 invariavelmentepara desenvolver um produto de software. Mas sim uma metodologia adaptativa, dependente doprojeto de software etc, por meio da qual será possível a seleção/escolha de um conjunto maisapropriado 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 deatividades 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 mesmaestrutura 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çãoou 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 daconfiguração de software; gerenciamento de reusabilidade; preparo e produção de artefatos desoftware; 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 Engenhariade Software. É preciso que, aliado a execução deste plano, se aplique alguns princípios taiscomo:

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)Questões que deverão serem respondidas:

• 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)Questões que deverão serem respondidas:

• É possível testar cada parte componente da solução?

• A solução produz resultados que se adequam aos dados, funções e característicasnecessárias?

2.1.3 Ferramentas de Software

Definiçã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 camadasde processos e métodos respectivamente. Permitindo, entre outras coisas, a produção/geraçãode “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 outraetapa/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çoou resultado exclusivo. A natureza temporária dos projetos indica que eles têmum início e um término definidos. O término é alcançado quando os objetivosdo 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 doprojeto 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árionão se aplica ao resultado mas sim ao projeto por meio do qual se alcança este resultado. Cadaprojeto, mesmo compartilhando certas características com outros projetos, possui suas própriascaracterí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áriosmembros, 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 oua 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 registrode uma pesquisa; Construção de um prédio, de uma planta ou uma infraestrutura; ou ainda aimplementaçã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 degerenciamento 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 aspartes; atender os requisitos do projeto bem como de suas entregas; e equacionar as restriçõesde escopo, qualidade, cronograma, orçamento, recursos e riscos inerentes a todo projeto. Asrestrições de projeto estão diretamente relacionadas entre si de forma tal que a alteração emuma delas certamente implicará em mudanças em pelo menos uma outra. Os responsáveis pelodesenvolvimento/execução do projeto deverão ser capazes de avaliar tais situações e agir deforma 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 oresultado/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 aestrutura genérica de ciclos de vida definida por: início; organização e preparação; execução; eencerramento.

O Ciclo de Vida de um projeto são as fases pelas quais este projeto passará até a suaconclusão. Geralmente ocorrendo de forma sequencial, mas podendo se sobrepor, as fases doprojeto são definidas de acordo com necessidades de gerenciamento organizacional, a natureza eaplicação do projeto. As fases são delimitadas por intervalos de tempo com um início e términodefinidos ou ainda através de um ponto de controle. Um projeto pode ser dividido em qualquernúmero de fases sendo que cada uma representa um conjunto de atividades relacionadas deforma 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 atodos os projetos embora a execução recorrente de determinadas fases possa permitir o empregode uma determinada estrutura em detrimento de outras. A figura 3 representa a execução de umprojeto 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 secontrolar um projeto, no entanto a utilização de processos representa um guia na aplicaçãode conhecimentos e habilidades necessários ao gerenciamento do projeto. Esse emprego deprocessos se dará de forma iterativa e quando necessário o processo poderá ser repetido aolongo do projeto.

A natureza do gerenciamento de projetos exige uma inter-relação e/ou sobreposição dosprocessos empregados para essa finalidade. Como demonstrado pela figura 4, os processos demonitoramento 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á sendousado para gerenciar o desenvolvimento de produtos complexos desde o iníciode 1990. Scrum não é um processo ou uma técnica para construir produtos; emvez 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ênciase que as decisões deverão ser tomadas baseado neste conhecimento. O controle de processoempíricos é apoiado por três pilares que são:

1. Transparência: Os aspectos mais importantes do processo devem estar acessíveis aosresponsáveis pelos resultados.

2. Inspeção: Muitos dos aspectos de processo devem ser inspecionados com frequênciasuficiente 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, impossibilitandoa aceitação do resultado, os aspectos e/ou processos devem ser adaptados/ajustados oquanto 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ósitoespecífico e é indispensável para o sucesso do Scrum (SCHWABER; SUTHERLAND, 2013a). Asregras integram os eventos, papéis e artefatos, controlando as relações e interações entre osmesmos (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. Umgrupo auto-organizável é o responsável por definir a melhor forma para concluir seu trabalhoe portanto não precisa ser gerenciado por alguém fora do grupo. Um grupo multifuncionalsão providos de todas as habilidades necessárias para completar seu trabalho e portanto nãodependem de pessoas de fora do grupo. O modelo de time no Scrum foi pensado para melhorara flexibilidade, criatividade e produtividade. O Time Scrum está associado aos Papéis do Scrumque são:

28

• Produto Owner/Dono do Produto: é o responsável, entre outras coisas, por maximizaro valor do resultado do projeto e do trabalho empregado pela Equipe de DesenvolvimentoScrum.

• Equipe de Desenvolvimento do Scrum: responsáveis, entre outras coisas, pelo trabalhoque resultará em uma versão/incremento utilizável do “produto” no final de cada cicloSprint.

• Scrum Master: é o responsável, entre outras coisas, por garantir que o entendimento eaplicabilidade 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 iniciadosestes eventos não podem ter seus intervalos alterados. Algumas das principais característicasdestes 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çõesquando necessário. Os principais eventos do Scrum são:

• Sprint: é o evento/ciclo “cerne” do Scrum e um contêiner para outros eventos. É umtime-boxed com duração de um mês ou menos onde uma versão utilizável do produtoserá 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 eletambém é composto pelas reuniões de Planejamento do Sprint, Reuniões Diárias, Revisãodo 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 horaspara um Sprint de um mês e no caso de Sprint’s menores este tempo máximo tambémdiminui.

• Reunião Diária: Este evento possui um time-boxed de 15 minutos durante o qual aEDS sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentos eprograma as tarefas para o dia seguinte.

• Revisão do Sprint: Este evento possui um time-boxed de 4 horas para um Sprint de ummê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çõesno 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 paraserem executadas no próximo Sprint. Possui um time-boxed de três horas para um Sprintde 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 acordocom valor de negócio, de tudo aquilo que for necessário (funções, requisitos, melhoriasetc) 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 ecom o “ambiente” Scrum e existirá enquanto o produto existir. A figura 5 representa umexemplo 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 fazeremparte 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 funcionalidadesque 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’spassados. Este incremento deve dar origem há uma nova versão do produto em condiçãode ser utilizada pelo Stakeholders e portanto atendendo a uma definição de “Pronto” sobo ponto de vista do TS.

• Burndown Chart: de acordo com (RUBIN, 2013), este gráfico é útil para acompanharo progresso dos esforços/trabalhos durante o Sprint, demonstrando quanto trabalho faltapara 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 monitoraro 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 representaos 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émdeve 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çoetc) 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 comoconsequê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 comerciaspodem ser significativos para uma organização. Por isso a importância da escolha e prática deuma metodologia para gerência de projeto por parte das organizações.

O Scrum se tornou uma das metodologias ágeis mais populares atualmente. Isto porqueapresenta, 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 oiní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 fatoque 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 9exibe 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, entreo Time Scrum (Time Central do Scrum) e os Stakeholders (clientes, usuários, patrocinadoresetc); 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 Produtoque lista os requisitos do produto/negócio ordenados de acordo com prioridades (por exemplovalor de negócio etc) e descritos em forma de Estórias de Usuário. Em seguida a Reunião dePlanejamento das Releases ocorre, em que TS apoiados pelo BPP farão uma revisão das suasEU para criar o Cronograma de Planejamento da Release e definir a duração dos Sprint’s. Aduração de um Sprint é de uma a quatro semanas e envolve os integrantes do Time Scrumtrabalhando no desenvolvimento de “entregas/incrementos” e/ou em melhorias de produto compotencial de utilização pelos clientes/usuários.

Agora os ciclos Sprint’s podem ser iniciados, cada Sprint se inicia com a Reunião dePlanejamento do Sprint durante a qual o TS, novamente apoiados no BPP, seleciona as EU demais alta prioridade para fazerem parte do Sprint, originando o artefato Backlog do Sprint. Nodecorrer do Sprint, Reuniões Diárias de curta duração são realizadas permitindo com que osintegrantes 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 EquipeScrum irá demonstrar para o PO e os Stakeholders os estregáveis/incremento. O PO entãoavalia 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 deRetrospectiva do Sprint, onde o TS poderá apresentar possíveis melhorias, tanto no que dizrespeito 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 serepetem 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, independentede 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 osaspectos e processos do Scrum podem ser modificados para atender/adequar aos requisitos deprojeto e/ou organizacionais. Os princípios, aspectos e processos do Scrum constituem a basepara esta metodologia e a compreensão de suas relações são de fundamental importância paraentendimento 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 filosofiacentral 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. Resultandoem uma maior satisfação, responsabilidades compartilhadas e em um ambiente inovadore mais propício ao crescimento.

3. Colaboração: foca nas questões base do trabalho colaborativo - consciência, articulaçãoe 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 todoo 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 oproduto deverá ocorrer dentro de intervalos de tempo bem definidos e repetitivos e deforma incremental. Permitindo dessa forma a gerência de eventuais mudanças e comoconsequê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 projetoScrum é essencial para se alcançar o sucesso na implantação dessa metodologia. Ospapéis centrais do Scrum são obrigatórios para o desenvolvimento de produto/serviço emum projeto Scrum e os colaboradores que os representam são os principais responsáveispelo 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, ecomo consequência a justificativa de viabilidade e continuidade do projeto. A justificativade 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 resultadosem atingir o valor de negócio esperado pelos stakeholders, e em atender aos critériosde aceitação que foram definidos previamente. Para garantir que o projeto atenda aoscritérios de qualidade esperados um processo de melhoria contínua é adotado, permitindoao TS aprender com a experiência e com a participação dos stakeholders. Essas melhoriasincluem, entre outras coisas, a atualização constante do BPP para atender a eventuaismudanças que possam ocorrer nos requisitos e na detecção o quanto antes de erros e/oudefeitos, 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 noScrum 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, empregandoprocessos 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 capazesde afetar os objetivos do projeto, contribuindo para seu sucesso ou fracasso. Os riscosque podem influenciar de forma positiva são definidos como oportunidades, já aquelesque podem influenciar de forma negativa são identificados como ameaças ao sucesso doprojeto. A gerência dos riscos no Scrum deve iniciar junto com o projeto perdurandodurante 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 divididosem 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óriose quais são opcionais. A seguir são descritos os processos de cada fase e a especificação deentradas, 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ãoda Visão do Projeto e a Declaração de Visão do Projeto é criada para servir comoorientação durante todo o projeto. Neste processo também se dará a identificaçãodo 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ãodefinidos.

4. Desenvolver os Épicos: a DVP é utilizada como base para a criação dos Épicos ecaso 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 epriorizados 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 osCritérios de Aceitação para EU. As EU devem ser projetadas de forma a permitir atransparência e compreensão dos requisitos de cliente, para os Stakeholders. As EUsão incorporadas/”anexadas” ao BPP.

2. Aprovar, Estimar e Comprometer as EU: o PO seleciona as EU para o Sprint e oSM juntamente com a EDS estimam os esforços para completá-las. Para finalizar aEDS se compromete a entregar os requisitos sob EU.

3. Criar as Tarefas:as EU aprovadas, estimadas e comprometidas são divididas emtarefas e agrupas na Lista de Tarefas. Em geral uma Reunião de Planejamento deTarefas acontece para este fim.

38

4. Estimar as Tarefas:a EDS na RPT estima os esforços para completar as tarefas daLT.

5. Criar o Backlog do Sprint:o TS durante a Reunião de Planejamento do Sprint cria oBacklog do Sprint com as tarefas a serem desenvolvidas no Sprint.

A tabela 2 a seguir define as entradas, ferramentas e saídas obrigatórios para cada pro-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 osEntregáveis. O acompanhamento do progresso dos trabalhos e atividades é realizadoatravés do Scrumboard/Taskboard.

2. Conduzir a Reunião Diária: momento utilizado pela EDS para informarem-se entrese sobre suas atividades, progressos e quaisquer impedimentos, além de definir oque será realizado no dia seguinte.

3. Refinamento do Backlog Priorizado do Produto: o BPP é constantemente atualizadoe mantido. Uma Reunião de Revisão do BPP pode ser realizada para que eventuaismudanças e atualizações no BPP possam ser debatidas e se for o caso incorporadasao BPP.

A tabela 3 a seguir define as entradas, ferramentas e saídas obrigatórios para cada pro-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 deScrum’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 oSprint. O PO então avalia os entregáveis e caso sejam aprovados e/ou aceitos entãouma 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çõessão documentadas e poderão serem utilizadas nos próximos Sprint’s.

A tabela 4 a seguir define as entradas, ferramentas e saídas obrigatórios para cada pro-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ãodisponibilizados 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 identificar, documentar e internalizar lições aprendidas.

A tabela 5 a seguir define as entradas, ferramentas e saídas obrigatórios para cada pro-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 existentepara 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 umresultado 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 dediferentes tipos de informação, segundo (WIKIPEDIA, 2016c) – traduzido.

- tem como finalidade ajudar a desenvolver nos indivíduos as capacidadesque os tornem capazes de estabelecer uma relação pessoal com o meio emque 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 (ouobjetivo) 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 serdefinido pela composição de duas vertentes diferentes mas que se complementam: de um ladoo educador - aquele que detém o conhecimento e o responsável por transmiti-lo; do outro oaprendiz que está ávido por novos conhecimentos. Ainda segundo Lino (2007), este é umprocesso que está em constante transformações assim como a natureza dos componentes baseneste processo.

Segundo (CROSS, 1987), para se alcançar um aprendizado de excelência é necessárioque os instrutores estejam cientes do que eles podem fazer para que o ensino seja transmitidode 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, aindasegundo (CROSS, 1987), é:

42

• Compreender que grande parte dos estudos sobre ensino consideram que os estudantesaprendem 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áticasde 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/vontadede 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, umaexpectativa 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 citadospodem contribuir de forma significativa para o aprendizado, outros estudos demonstram quenão existe um sentido comum a respeito da importância/eficácia de tais práticas no processo deensino-aprendizagem como um todo.

Para (QUARESMA, 2016), ao longo do tempo o processo de ensino-aprendizagem temsido qualificado em diferentes formatos, antes se enfatizava mais o papel do educador comotransmissor do conhecimento, agora os conceitos sobre este processo são concebidos de formasistêmica. Onde o ensino-aprendizagem se caracteriza como parte de um todo. Ainda de acordocom (QUARESMA, 2016), reflexões sobre o atual processo permitem perceber um “movimentode 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 atualPsicologia sobre este processo, induzindo questões sobre como se dá a prática da educaçãoatualmente e uma conceitualização do processo ensino-aprendizagem para os tempos atuais(QUARESMA, 2016).

Segundo (DRISCOLL, 2004), as teorias sobre aprendizagem concentram-se em descrevercomo se desenvolve os processos de aprendizagem. Tais definições se caracterizam como umdos 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 dosestudos, também responsáveis por esta estruturação dos processos de aprendizagem, refletemsobre 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 deinstruir/ensinar (DRISCOLL, 2004). Os aprendizes podem ser crianças, jovens ou pessoas maisvelhas e o ambiente onde o processo de ensino-aprendizagem se dará, poderá ser um ambienteformal, escolar, de trabalho ou em público; já os responsáveis por instruir/ensinar poderão serprofessores, instrutores ou designers instrucionais etc; estes últimos sendo responsáveis pordesenvolver 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, odesenvolvimento e a utilização de métodos, técnicas, atividades, materiais,eventos e produtos educacionais em situações didáticas específicas, a fim defacilitar a aprendizagem humana a partir dos princípios de aprendizagem einstrução conhecidos.

De acordo com (E-LEARNING, 2016b), o Design Instrucional é definido como sendoum processo sistemático de “tradução” dos princípios/fundamentos do ensino-aprendizagem noplanejamento 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 apesquisas 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 emque se emprega, de forma sistemática, as teorias de ensino-aprendizagem com objetivo de obterum ensino de qualidade; o que requer a realização de análises das necessidades e objetivos deaprendizagem, com consequente desenvolvimento e distribuição de “sistemas” adequados a taisnecessidades (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 podemser, sistematicamente, planejadas, desenvolvidas e avaliadas segundo a descrição/estrutura dosprocessos 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 utilizadospara 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 guiasdescritivos 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 metodologiautilizada para definir um público-alvo, “levantar” os “requisitos” para este público, projetar edesenvolver uma solução e avaliar os resultados coletados a partir da aplicação da solução. Afigura 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 seremsanadas no público-alvo, são levantados os requisitos de aprendizagem e conse-quentemente metas e objetivos de ensino-aprendizagem são definidos. Procura-secaracterizar o público-alvo através de identificação de conhecimentos, habilidadese 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 resultadodesta 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 osobjetivos e metas de aprendizagem. Esta fase é composta, basicamente, por trêssubetapas 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çãodo 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, poiseste formato impactará de forma significativa as características presentes nodocumento 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 aabordagem 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 necessidadese objetivos identificados na fase de análise. No caso de uma UI que representa umproduto 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 atividadesque foram definidas no projeto instrucional. No caso de UI’s como sendo produtosde software e/ou hardware, os aprendizes deverão ser orientados/treinados sobrecomo 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 avaliadosa 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 aavaliaçã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 apoiaros 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 oplanejamento, 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íniocognitivo 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 opróximo nível - para se obter o conhecimento relativo ao próximo nível – só será possível seos requisitos (conhecimentos, habilidades etc) relativos ao nível anterior já foram alcançadosCamargo (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 deBloom (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 sobrestriçõ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 prazerou 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, umaatividade 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 jogosprojetados 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 formade aprender/aperfeiçoar conhecimentos e habilidades, promover atividades físicas, suporte aodesenvolvimento social/emocional, e o tratamento de diferentes tipos de doenças psicológicas efísicas entre outras (MA; OIKONOMOU; JAIN, 2011). Recentes estudos, considerando diferentescontextos, 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, combinadascom 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, ouauxiliá-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 osaspectos relacionados a jogabilidade e com a capacidade do jogador/aprendiz em assimilar osconceitos 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 formamais ativa, possibilitando ao aprendiz se tornar um agente mais participativo neste processo ecom 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 construtoresde jogos envolvem, entre outras, a definição de regras que estimulem/motivem o jogador e quepermitam 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çãopara 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 consideradoeducativo e portanto passível de utilização como recurso de ensino, é que este seja desenvolvidoa 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 definiro 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 eficaz e pessoal;

• “jogos são eficazes 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 tempoque 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 naliteratura, para auxiliar no processo de ensino-aprendizagem de ES/SCRUM. Em especial serãoabordados 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 Engenhariade Software. Foram analisados e “levantadas” informações como: uma descrição resumida dojogo; 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íficas (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 figura 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 noteste 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 dificuldade = 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




Bloom


Público-Alvo Estudantes de Processos de Medição e Análise de Software


Idioma Disponível Português

Duração Aproximadamente 2 horas

Resultados de Avaliações N/A

Linguagem N/A



Fonte: (LINO, 2007)

52

Tabela 7 - Informações sobre o jogo X-MED

Jogo

X-MED

Plataforma N/A

Referência N/A

Fonte: (LINO, 2007)

Tabela 8 – Informações sobre o jogo TestEG

Jogo

TestEG

Captura de Tela

Descrição Resumida O jogo é composto por dois módulos um de Administrador e o outro de Jogador/Usuário. Ao acessar o sistema a

tela de login é apresentada e o user se identifica, de acordo com seu perfil ele será direcionado para um ou outro

módulo. No módulo de administrador pode-se cadastrar novos administradores, usuários/jogadores e perguntas etc.

No módulo de jogador, o mesmo assume o papel de Gerente de Teste em um ambiente fictício (uma pequena empresa

de desenvolvimento de software), e será o responsável por gerenciar uma equipe de testes. Durante o jogo o gerente

de teste realiza tarefas como solucionar dúvidas (auxiliando nas tarefas de testes), realizar treinamentos e verificar

desempenho dos integrantes da equipe de teste. O gerente de teste poderá ainda se qualificar melhor a respeito das

atividades inerentes a um gerente de testes, através da leitura de conteúdo direcionado para estes propósitos.

Fonte: (OLIVEIRA, 2013)

53

Tabela 8 - Informações sobre o jogo TestEG

Jogo

TestEG

Objetivos de

Aprendizagem

Ensinar Processos de Testes de Software




Bloom


Público-Alvo Estudantes de Processos de Testes de Software



Duração Aproximadamente 10 minutos

Resultados de Avaliações 52 jogadores/avaliadores responderam a avaliação e as conclusões foram as seguintes:- 40 acharam o design da interface adequado;- 25 disseram que não houve dificuldades para entender o jogo;- 40 acharam o conteúdo educacional abordado útil;- 31 responderam que não acham que o jogo possui muitas informações;

- 32 responderam que aprenderam mais com o jogo.

Linguagem Engine de Jogos - Unity3D



Plataforma N/A

Referência N/A

Fonte: (OLIVEIRA, 2013)

4.2 JE para o Ensino-Aprendizagem de SCRUM

A seguir são apresentados alguns exemplos de jogos educacionais para auxiliar no pro-cesso de ensino-aprendizagem sobre a metodologia ágil Scrum. Foram analisados e “levanta-das” informações como: uma descrição resumida do jogo, objetivos e níveis de aprendizagem,público-alvo, resultados de avaliações etc.

54

Tabela 9 – Informações sobre o jogo SCRUM-Scape

Jogo

SCRUM-Scape

Captura de Tela

Descrição Resumida O jogo se “passa” em um prisão contendo 3 repartições e que remete ao período medieval, sendo cada uma dessas

repartições contendo suas respectivas celas. Cada repartição representa um nível de complexidade do jogo e cujo

conteúdo educacional presente representa um dos conceitos básicos do Scrum. Para vencer o jogador precisará passar

por estes 3 níveis do jogo definidos como missões a serem cumpridas pelo jogador. Na primeira missão será abordados

os papeís do Scrum, na segunda as reuniões do Scrum e na terceira os artefatos do Scrum.

Objetivos de

Aprendizagem

Ensinar conceitos básicos (Papéis, Artefatos e Reuniões) sobre a Metodologia Ágil Scrum




Bloom

Nível 2 - Compreensão (de acordo com a figura 14)

Público-Alvo Estudantes da Metodologia Ágil Scrum

Pré-requisitos do

Público-alvo

Possuir algum conhecimento básico sobre Gerência de Projetos e Metodologia Ágil Scrum




55

Tabela 9 - Informações sobre o jogo SCRUM-Scape

Jogo

SCRUM-Scape


Resultados de Avaliações 17 jogadores/avaliadores responderam a avaliação e as conclusões foram as seguintes:- com relação a motivação foi constatado resultados positivos em todos os aspectos avaliados, com destaque pararelevância e atenção durante o jogo;- com relação a experiência obtida com o jogo também foram constados resultados positivos em todas as dimensõesavaliadas, com destaque para diversão e imersão;- com relação ao aprendizado adquirido com o jogo os avaliadores, de forma geral, também responderam positivamente,sendo que aproximadamente 70% deles disseram ter aprendido mais com jogo;

- por fim foi avaliado o nível de conhecimento que se atingiu com o aprendizado adquirido e 14 dos 17 participantes

responderam positivamente, indicando que este nível subiu pelo menos 1 ponto.

Linguagem Engine de Jogos - RPG Maker


Gênero/Categoria do Jogo RPG - Role Playing Game

Plataforma N/A

Referência N/A


Tabela 10 – Informações sobre o jogo SCRUM’ed

Jogo

SCRUM’ed

Captura de Tela

Fonte: (SCHNEIDER, 2015)

56

Tabela 10 - Informações sobre o jogo SCRUM’ed

Jogo

SCRUM’ed

Descrição Resumida O jogador assume o papel de Scrum Master e será o responsável por auxiliar a Equipe Scrum em suas atividades durante

o Sprint. Entre as atividades do jogador/Scrum Master etão a de “remover” os impedimentos que são apresentados pelos

membros da Equipe Scrum. O jogo se “passa” em um senário medieval representados por um castelo e um palácio.

No castelo o Time Scrum está reunido e é neste local onde acontecem as reuniões e os artefatos são criados. Quando

solicitados o Time Scrum se desloca até o palácio e chegando lá o jogador precisa remover alguns “impedimentos”

que atrapalham a execução de tarefas por parte da equipe. Quando a equipe termina suas tarefas o time retorna para o

castelo. Caso o jogador consiga remover todos os impedimentos até o final da Sprint (retorno ao castelo), o Produto

Owner aprovará a Sprint e consequentemente o jogador vence o jogo, pois conseguiu completar suas “tarefas” no papel

de Scrum Master durante a Srprint.

Objetivos de

Aprendizagem

Ensinar conceitos básicos (Papéis, Artefatos e Reuniões) sobre a Metodologia Ágil Scrum




Bloom


Público-Alvo Estudantes da Metodologia Ágil Scrum

Pré-requisitos do

Público-alvo





Resultados de Avaliações 23 jogadores/avaliadores responderam a avaliação e as conclusões foram as seguintes:- com relação a motivação foi constatado resultados positivos em todos os aspectos avaliados, com destaque para a ques-tão que perguntava se o conteúdo educacional do jogo estava de acordo com conceitos já “vistos” pelos participantes,e 95- com relação a experiência obtida com o jogo também foram constados resultados positivos e outros nem tanto, comdestaque para a questões como desafiador (boa parte concorda) e cooperação, competição, diversão e interação (boaparte não concorda);- com relação ao aprendizado adquirido com o jogo, mais de 50

- por fim foi avaliado o nível de conhecimento que se atingiu com o aprendizado adquirido após o jogo e, no geral, os

participantes responderam que o conhecimento deles melhorou a respeito do assunto abordado, indicando que o nível

subiu pelo menos 1 ponto.

Linguagem Engine de Jogos - Unity


Gênero/Categoria do Jogo RPG - Role Playing Game

Plataforma Windows


57

Tabela 10 - Informações sobre o jogo SCRUM’ed

Jogo

SCRUM’ed

Referência N/A


Tabela 11 – Informações sobre o jogo Scrum Game

Jogo

Scrum Game

Captura de Telas doMódulo Administrador

Fonte: (GKRITSI, 2011)

58

Tabela 11 - Informações sobre o jogo Scrum Game

Jogo

Scrum Game

Captura de Telas doMódulo Jogador/User


59


Jogo

Scrum Game

Descrição Resumida O jogo é composto por dois módulos um de Administrador e o outro de Jogador/Usuário. Ao acessar o sistema a tela de

login é apresentada e o user se identifica, de acordo com seu perfil ele será direcionado para um ou outro módulo. No

módulo de administrador pode-se modificar projetos de softwares, criar membros para a equipe scrum, novas tarefas,

possíveis alternativas de respostas para a Daily Scrum etc. No módulo de jogador o mesmo assumirá o papel de Scrum

Master e de início deverá escolher o projeto de software que deseja participar. Em seguida deverá montar a Equipe

Scrum e auxiliá-la em suas atividades, garantido que seus membros executem suas tarefas em acordo com a metodologia

Scrum. Como parte da reunião de planejamento da release, os jogadores são solicitados a estimarem o esforço e duração

de cada tarefa para o projeto que estão participando e registrando esses dados no Produto Backlog. Para o Produto

Backlog a abordagem adotada é similiar. A reunião Daily Scrum é considerada uma das mais importantes para este

jogo, pois será onde o jogador solicitará a equipe scrum 3 questões, irá respondê-las e sua pontuação será armazenada.

A qualquer momento o jogador poderá acessar o Burndown Chart para monitorar o progresso da equipe e estimar

quando o produto final será entregue. Na reunião de Review Meeting o Produto Owner avaliará se a release está de

acordo com o requisitos. Para isso será considerado o perfil dos integrantes da equipe ou seja, quanto mais qualificado

mais será a cobrança por parte do Produto Owner. Caso seja aprovado a release o jogador pode passar para o próximo

sprint do contrário ele deverá repetir o sprint.

Objetivos de

Aprendizagem

Ensinar conceitos/práticas da Metodologia Ágil Scrum com ênfase nas atividades exercidas pelo papel do Scrum Master




Bloom


Público-Alvo Estudantes de Metodologia Ágil Scrum/Gerência de Projetos

Pré-requisitos do

Público-alvo



Idioma Disponível Inglês

Duração Depende de cada Projeto (qtd de sprints, duração de tarefas etc)


60


Jogo

Scrum Game

Resultados de Avaliações 22 jogadores/avaliadores responderam a avaliação e as conclusões foram as seguintes:- 60% acreditam não ser necessário possuir algum conhecimento prévio sobre o jogo para conseguir jogá-lo;- 86% afirmaram que aprenderam mais sobre o Scrum após jogar o Scrum Game;- 91% acreditam que este jogo poderia ser usado como material de apoio (prática) a teoria sobre Scrum abordado emsala de aula;- 95% acham que aprenderiam melhor/mais, sobre Gerência de Projeto, se este jogo fosse utilizado como recurso deensino-aprendizagem para esta disciplina/conteúdo;- 75% acharam o jogo divertido de se jogar;

- esta versão do sistema recebeu uma nota 8 de média num total de 10, quando avaliado de forma geral (interface,

navegabilidade etc).

Linguagem PHP



Plataforma Computador/Web/Windows

Referência http://users.ecs.soton.ac.uk/ag2006/COMP6029/


61

Tabela 12 – Informações sobre o jogo Scrumming

Jogo

Scrumming

Captura de Tela

Descrição Resumida O jogo é composto por dois módulos um de Administrador e o outro de Jogador/Usuário. Ao acessar o sistema a tela

de login é apresentada e o user se identifica, de acordo com seu perfil ele será direcionado para um ou outro módulo. O

jogo permite a simulação de um sprint em um único hipotético projeto, não é possível salvar o contexto de um jogador e

o jogo/sistema é quem se encarrega de alocar os recursos (estimar) para execução das atividades/tarefas. No módulo de

administrador pode-se adicionar novos membros para a equipe scrum, incluir e excluir novas atividades/tarefas para o

projeto etc. No módulo de jogador o mesmo assumirá o papel de Scrum Master e realizará atividades como: configurar

o projeto a ser simulado (adicionando atividades etc), definir a equipe scrum, monitorar o andamento do sprint através

do taskboard, visualizar o gráfico de burndown, adicionar e remover atividades/tarefas no backlog do produto, definir

o sprint (adicionando atividades ao backlog do sprint etc), visualizar atividades etc.

Objetivos de

Aprendizagem

Ensinar conceitos/práticas de Metodologia Ágil Scrum com ênfase nas atividades exercidas pelo papel do Scrum Master




Bloom


Público-Alvo Estudantes de Metodologia Ágil Scrum/Gerência de Projetos

Pré-requisitos do

Público-alvo


Fonte: (NETO, 2008)

62

Tabela 12 - Informações sobre o jogo Scrumming

Jogo

Scrumming



Duração N/A


Linguagem Java



Plataforma Computador/Windows

Referência N/A

Fonte: (NETO, 2008)

Tabela 13 – Informações sobre o jogo Playing Scrum

Jogo

Playing Scrum

Captura de Telasdo MóduloAdministrador/Cliente

Fonte: (SILLER; BRAGA, 2013)

63

Tabela 13 - Informações sobre o jogo Playing Scrum

Jogo

Playing Scrum

Captura de Telas doMódulo Jogador/Aluno

Descrição Resumida O jogo é composto por duas “áreas” sendo uma delas contendo as funcionalidades/atividades relacionadas ao Cliente

no Scrum (papel não central), e a outra destinada ao jogador que poderá assumir um dos papeis centrais no Scrum

(Produto Owner, Scrum Master, Equipe de Desenvolvimento). Na área do cliente o usuário poderá propor/formalizar

um projeto a ser desenvolvido, através do cadastro das especificações para o mesmo, além do cadastro de vídeos e links

de ajuda. Ainda na área cliente, por meio de grupos, será possível vincular diferentes equipes de jogadores a diferentes

projetos com diferente grau de complexidade e a avaliação destas equipes. Na área do jogador será possível a criação

de uma nova equipe ou à associação a uma existente. O jogador poderá assumir o papel de Produto Owner, Scrum

Master ou Equipe de Desenvolvimento, sendo que nos dois primeiros casos isso só será possível se ainda nenhum outro

jogador não tiver assumido estes papeis. O jogador, através de um menu, poderá acessar as telas para execução de suas

tarefas de acordo com o papel de cada um dentro do Scrum. Ou seja, caso o jogador tente acessar uma tela de tarefas

que não é da responsabilidade do papel exercido pelo mesmo, ele será direcionado para um local que o orientará de

tal fato. O jogo é baseado na formação de equipes, por parte dos jogadores, e estas equipes executando projetos de

softwares através de práticas do Scrum. A equipe que obtiver uma pontuação mais alta será considerada a vencedora.

Objetivos de

Aprendizagem

Ensinar conceitos/práticas da Metodologia Ágil Scrum




Bloom


Público-Alvo Estudantes de Engenharia de Software


64

Tabela 13 - Informações sobre o jogo Playing Scrum

Jogo

Playing Scrum

Pré-requisitos do

Público-alvo

N/A

Modo de Interação Multijogador


Duração N/A


Linguagem Java EE



Plataforma Computador/Web

Referência N/A


65

5 DESENVOLVIMENTO/CRIAÇÃO DO JOGO PLAY’ED-SCRUM’CES

Este capítulo apresenta os resultados do processo de desenvolvimento do jogo educa-cional PLAY’ed-SCRUM’ces, utilizando como referência o modelo ADDIE (as três primeirasfases – Analise, Projeto, Desenvolvimento) para criação do Design Instrucional para o jogo.Os resultados incluem a definição/identificação de metas/objetivos instrucionais, contextos or-ganizacionais e/ou instrucionais (ex: sala de aula onde o jogo poderá ser aplicado), níveis deaprendizagem a serem atingidos, conteúdo e a sequência em que será abordado, estratégias ins-trucionais, requisitos/funcionalidades, tabelas, diagramas, tecnologia empregada, elementos dojogo (regras, dinâmica, cenários, interações, feedback etc).

5.1 Análise/Projeto Instrucional

Nesta subseção serão apresentados os resultados que foram “levantados” para compor oDesign Instrucional do jogo, com base nas fases de análise e projeto do modelo ADDIE.

5.1.1 Análise

Nesta etapa serão definidos o público-alvo, contexto instrucional e metas/objetivos deaprendizagem.

Público-alvo do PLAY’ed-SCRUM’ces: de uma forma geral este público poderáser formado por estudantes da metodologia ágil SCRUM. Dentre os quais pode-se citar o público formado por estudantes de graduação cujo currículo contempleo assunto/conteúdo SCRUM. Alguns exemplos destes cursos são aqueles que seinserem na área de computação como: Ciência da Computação, Sistemas de In-formação, Engenharia de Software etc. Para os jogadores que já possuam algumconhecimento teórico/conceitual sobre o Scrum, principalmente a respeito de con-ceitos básicos como papéis, artefatos e reuniões, espera-se que eles já consigamjogar sem que seja necessário estudar o conteúdo teórico/educacional do jogo. Masnão é necessário que os jogadores já apresentem previamente tais conhecimentos,pois no próprio jogo será possível estudar o conteúdo educacional abordado duranteuma partida do jogo.

Contexto Organizacional/Instrucional: considerando-se o fato de que um dospossíveis públicos-alvo para este jogo como sendo alunos da área de computa-ção em geral, permite considerar que as disciplinas destes cursos (cujo currículocontemple o Scrum) como sendo um dos possíveis contextos instrucionais paraaplicação deste jogo. Aplicação esta que poderá ser realizada em salas de aula,

66

laboratórios ou mesmo em casa como tarefas de extra classe.

Metas/Objetivos de aprendizagem: espera-se que o conteúdo deste jogo possibi-lite aos jogadores atingir um nível de aprendizagem que contemple aspectos comoos de lembrança e compreensão, definidos de acordo com a taxonomia de Bloom.Após ter jogado uma “partida” do jogo espera-se que o jogadores tenham desenvol-vido competências/conhecimentos que os possibilite de:

• Lembrar o nome e definição conceitual de cada um dos papéis, artefatos ereuniões do Scrum;

• Lembrar/Compreender os objetivos/responsabilidades de cada um dos papéis,artefatos e reuniões do Scrum;

• Lembrar/Compreender as relações existentes entre cada um dos papéis, arte-fatos e reuniões do Scrum;

• Lembrar/Compreender nomes, conceitos, objetivos e relações dos conjuntosde métodos/práticas/regras considerados como os fundamentos para o fra-mework Scrum, e definidos como sendo os princípios, aspectos e processosdeste frameowork.

5.1.2 Projeto

Nesta etapa serão definidos o conteúdo educacional, a sequência de apresentação paraeste conteúdo e as estratégias/atividades de ensino empregadas para se atingir as metas/objetivosque foram definidos na etapa de análise.

Conteúdo de Ensino: o seguinte conteúdo a respeito da metodologia ágil Scrumserá abordado no jogo:

• Nome e definição conceitual de cada um dos papéis, artefatos e reuniões doScrum;

• Objetivos/Responsabilidades de cada um dos papéis, artefatos e reuniões doScrum;

• As relações existentes entre cada um dos papéis, artefatos e reuniões do Scrum;

• O nomes, conceitos, objetivos e relações dos conjuntos de métodos/práticas/-regras considerados como sendo os fundamentos do framework Scrum, e de-finidos como sendo os princípios, aspectos e processos deste frameowork.

Mais informações sobre o conteúdo educacional do jogo podem ser encontradasnos Apêndice A e B deste trabalho.

67

Sequência de Apresentação do Conteúdo: o conteúdo do jogo foi agrupado e dis-tribuído em três partes, sendo que cada parte representará um nível de dificuldadeno jogo. A sequência para o mesmo será a seguinte:

• A primeira parte do jogo apresentará os nomes e conceitos sobre cada um dospapéis, artefatos e reuniões do Scrum;

• A segunda parte do jogo apresentará os objetivos, responsabilidades e relaçõesentre cada um dos papéis, artefatos e reuniões dos Scrum;

• A terceira parte do jogo apresentará os nomes, conceitos, objetivos e relaçõesdos conjuntos de métodos/práticas/regras considerados como sendo os funda-mentos do framework Scrum, e definidos como sendo os princípios, aspectose processos deste frameowork.

Uma segunda forma de apresentação para o conteúdo do jogo é através do me-nu/funcionalidade “Esdutar”. Através desta funcionalidade será possível a visu-alização de todo o conteúdo teórico do jogo, estruturado de forma a permitir aojogador/estudante estudar/aprender/revisar/consultar todo o conteúdo educacionaldo jogo, antes de iniciar uma nova partida. Mais informações sobre a sequênciade apresentação do conteúdo do jogo podem ser encontradas nos Apêndice A e Bdeste trabalho.

Estratégias/Atividades de Ensino: algumas possíveis estratégias adotadas (e ou-tras que poderão ser adotadas) para se atingir/alcançar as metas/objetivos de apren-dizagem (definidas na subseção 5.1.1) são:

• Projeto/desenvolvimento de uma ferramenta/recurso (o jogo PLAY’ed-SCRUM’ces),para avaliar e/ou auxiliar/apoiar o processo de ensino-aprendizagem de con-ceitos sobre o Scrum.

• Estruturação do conteúdo educacional, do jogo PLAY’ed-SCRUM’ces, emformato de perguntas “fechadas” (perguntas com as opções de respostas) euma introdução teórica/conceitual para cada assunto do qual se tratam as per-guntas.

• Divisão do conteúdo educacional (a parte das perguntas), para o jogo PLAY’ed-SCRUM’ces, em níveis de dificuldades. Com as perguntas mais fáceis no pri-meiro nível, as perguntas não tão fáceis e nem tão difíceis no segundo nível eas perguntas mais difíceis no terceiro nível do jogo.

• Apresentação, em separado, de todo o conteúdo teórico/educacional do jogoPLAY’ed-SCRUM’ces. Possibilitando ao jogador/estudante se preparar parao jogo antes de iniciar uma nova partida.

• Algum conteúdo teórico sobre Scrum (ou mesmo o conteúdo teórico do jogo)poderá ser abordado e discutido em sala de aula antes da aplicação do jogo.

68

• Poderão ser utilizados outros jogos educacionais semelhantes a este (com omesmo fim – ex: SCRUM-Scape Camargo (2013) e SCRUM’ed Schneider(2015)) para ambientar os alunos com este tipo de recurso.

• O jogo poderá ser aplicado em laboratórios utilizados para as aulas “práticas”do curso/disciplina (que contemple o Scrum) ou como atividade extra classe.Como o jogo se trata de um aplicativo digital que será desenvolvimento paraser instalado e executado em dispositivos móveis Android (Smartphone/Ta-blet), poderá ser “levado/carregado” e utilizado em qualquer lugar/local.

5.2 Desenvolvimento Instrucional

Nesta subseção serão apresentados os resultados que foram “levantados” para compor oDesign Instrucional do jogo, com base na fase de desenvolvimento do modelo ADDIE. Serãodefinidos os requisitos/funcionalidades, tabelas, diagramas (caso de uso, DER, classes etc),os elementos do jogo (regras, dinâmica, cenários, interações, feedback etc), uma descriçãoresumida das tecnologias (Android/Java) utilizadas para desenvolver o jogo, e onde se dará aimplementação propriamente dita do jogo/aplicativo.

5.2.1 Diagramas do jogo PLAY’ed-SCRUM’ces

Nesta subseção será apresentada a modelagem do jogo PLAY’ed-SCRUM’ces.

5.2.1.1 Diagrama DER

A modelagem de dados para o jogo PLAY’ed-SCRUM’ces é representada através deDER – Diagrama Entidade Relacionamento – para representar as tabelas presentes no Bancode Dados do jogo. Estas tabelas armazenam informações de conteúdo do jogo que permitem ofuncionamento/execução do mesmo. Estes dados são, por exemplo, as perguntas que compõemo jogo, as possíveis alternativas para cada pergunta, jogadores com suas respectivas pontuaçõesem cada partida, os possíveis níveis do jogo, os conceitos introdutórios sobre determinados as-suntos para as questões que dizem respeito ao mesmo etc. A figura 15 exibe o diagrama DERdo jogo PLAY’ed-SCRUM’ces.

69

Figura 15 – Diagrama Entidade Relacionamento - DER

Fonte: Criado pelo autor

5.2.1.2 Diagrama de Caso de Uso

A modelagem das funcionalidades para o jogo PLAY’ed-SCRUM’ces é representadaatravés de diagrama de Caso de Uso. Dentre as funcionalidades que o jogador/ator poderá exe-cutar/realizar estão: fazer login; consultar regras do jogo; consultar/estudar o assunto do con-teúdo educacional; iniciar uma partida; responder as perguntas; pausar/interromper uma partida;visualizar/consultar pontuações de partidas finalizadas e/ou interrompidas; reiniciar uma partidaetc. Já o ator/sistema executará/realizará tarefas como: registrar um novo jogador; autenticaro jogador para que ele tenha acesso ao sistema; calcular a pontuação do jogador durante umapartida; exibir a pontuação do jogador; registrar a pontuação do jogador; exibir feedback/status(dicas, regras, níveis etc) durante uma partida etc. A figura 16 apresenta o diagrama de Caso deUso (com alguns Caso de Uso) do jogo PLAY’ed-SCRUM’ces.

70

Figura 16 – Diagrama de Caso de Uso


5.2.1.3 Diagrama de Classes

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

71

Figura 17 – Diagrama de Classe


5.2.2 Regras do jogo PLAY’ed-SCRUM’ces

A dinâmica de um jogo é conduzida segundo suas regras que deverão serem conheci-das pelos jogadores, e desta forma possibilitar com que os mesmos possam/consigam jogar ojogo. Além de permitir aos jogadores à capacitação para agir (tomar decisões) da melhor formapossível, quando as circunstâncias exigirem. As regras do jogo PLAY’ed-SCRUM’ces são:

• Regra 1: o jogo só pode ser jogado por um único jogador por vez.

• Regra 2: o jogo terá duração máxima de 120 minutos (equivalente a 2 horas/aula dadisciplina de EG).

• Regra 3: o conteúdo do jogo é composto por um conjunto de perguntas “fechadas” aserem respondidas pelo jogador.

• Regra 4: dentre as possíveis alternativas, o jogador deverá escolher/selecionar, no má-ximo, a quantidade definida em cada questão.

• Regra 5: caso o jogador tente marcar mais opções do que o limite permitido ele seráadvertido/orientado do ocorrido. Podendo o mesmo desmarcar uma opção já selecionadapara marcar uma outra.

• Regra 6: as questões estão divididas em 3 níveis de dificuldade, o primeiro e segundoníveis com 15 questões cada e o terceiro com 19 questões.

• Regra 7: para cada questão respondida de forma correta o jogador ganhará 1 ponto noprimeiro nível, 2 pontos no segundo e no terceiro nível, 3 pontos para as questões de 1 a11 e 2 pontos para as questões de 12 a 19, totalizando 94 pontos.

• Regra 8: o jogador poderá passar para a pergunta seguinte ou retornar para a perguntaanterior, quando desejar. Ele poderá saltar/pular qualquer questão que, por ventura, não

72

deseja responder. Podendo retorná-la, a qualquer momento, se ainda lhe restar tempo paraisso.

• Regra 9: caso o jogador deseje, ele poderá responder parcialmente uma questão. Esco-lhendo um número menor de alternativas do que o limite definido pela questão.

• Regra 10: o jogador poderá passar para o nível seguinte ou retornar ao nível anterior aqualquer momento, se ainda lhe restar tempo para isso.

• Regra 11: para vencer o jogo o jogador precisará fazer uma pontuação equivalente a63 pontos dos 94 possíveis. O que representa, aproximadamente, a uma porcentagemequivalente a 80% dos pontos possíveis do primeiro nível (12 pontos), somados a 70%dos pontos possíveis do segundo nível (21 pontos) e mais 60% dos pontos possíveis doterceiro nível (aproximadamente 30 pontos).

• Regra 12: ao executar o jogo/aplicativo o usuário/jogador deverá se identificar antes depoder ter acesso as funcionalidades do jogo/aplicativo.

• Regra 13: o jogador poderá consultar/acessar as regras do jogo a qualquer momento,estando o mesmo no decorrer de uma partida ou não.

• Regra 14: antes de iniciar ou após o término de uma partida o jogador poderá “estudar”o conteúdo “cobrado/abordado” nas questões do jogo.

• Regra 15: o jogador poderá pausar uma partida para posteriormente reiniciá-la.

• Regra 16: o jogador poderá parar uma partida.

• Regra 17: ao finalizar/parar uma partida o resultado será exibido ao jogador.

• Regra 18: o jogador poderá visualizar toda a partida que foi finalizada/parada, para veri-ficar a pontuação conseguida na questão e as alternativas escolhidas.

• Regra 19: o jogador poderá consultar os resultados de partidas anteriores finalizadas/pa-radas.

• Regra 20: o jogador poderá consultar uma partida “parada” para “recuperá-la” e conti-nuar a jogar. A partida será reiniciada a partir da questão onde ela foi interrompida.

• Regra 21: o jogador poderá visualizar partidas anteriores finalizadas ou “paradas”.

• Regra 22: se o jogador não conseguir responder todas as questões durante os 120 minu-tos, será computada a pontuação até a última questão respondida.

73

5.2.3 Fundamentação teórica sobre a tecnologia Android/Java

Foram realizadas pesquisas/buscas, com intuito de identificar material/recursos sobrea tecnologia utilizada para desenvolvimento de aplicativos para dispositivos móveis que exe-cutam/rodam sobre o SO/Plataforma Android. O material levantado foi estudado, exemplosde aplicativos foram criados/codificados e instalados/executados para efeitos de testes. Dessaforma pode-se compreender a tecnologia que seria empregada no desenvolvimento do jogoPLAY’ed-SCRUM’ces.

Para o download de recursos/arquivos necessários, preparação/configuração de ambi-ente de programação, implementação/codificação dos exemplos e do jogo/aplicativo propria-mente dito, e geração do arquivo *.apk/aplicativo para distribuição/instalação do jogo, foramrealizados os seguintes passos:

1. Identificação e obtenção dos recursos/ferramentas necessários a permitir a codificação,testes, distribuição, instalação e execução do jogo/aplicação (apk);

• Download do Java SE Software Development Kit (JDK) em:

– http://www.oracle.com/technetwork/java/javase/downloads/index.html, ou em

– http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#jdk-7u80-oth-JPR

• Download da IDE Eclipse em:

– http://download.eclipse.org/eclipse/downloads/, ou em

– http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2201301310800/, ou em

– http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2-201301310800/download.php?dropFile=eclipse-SDK-3.8.2-win32.zip

• Download do Android Software Development Kit (SDK) em:

– https://developer.android.com/studio/index.html

– https://dl.google.com/android/installer_r24.4.1-windows.exe

• Download do Android SDK Manager (já vem com o SDK);

• Download do Android Development Tools (ADT) Plugin para Eclipse em:

– https://dl-ssl.google.com/android/eclipse/ a partir do mecanismo de atualizaçãoda IDE Eclipse

• Download do Android Emulator (já vem com o SDK); e

• Download do Android Virtual Device (AVD) Manager (já vem com o SDK).

2. Instalação e configuração dos recursos/ferramentas;

• Instalação e configuração do Java SE Software Development Kit (JDK) segundo(ORACLE, 2014) em:

74

– http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jdk-installation-windows.html

• Instalação e configuração do Android Software Development Kit (SDK) de acordocom (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015);

– Clique duplo no instalador (no caso do executável para windows)

– Seguir os passos/orientações do instalador

– Passe para a instalação da IDE Eclipse, e após completado este passo retorneneste ponto

– Execute a IDE Eclipse

– Selecione o menu Window -> Android SDK Manager

– Desmarque a caixa de seleção Instalados

– Selecione os pacotes listados em Tools

– Selecione os pacotes listados na versão do Android que se deseja instalar. Exem-plo de uma das versões do Android - Android 4.4.2 (API 19)

– Selecione os pacotes listados em Extras. Geralmente parte dos pacotes listadosaqui são opcionais. Os mais comuns são: Android Support Library ou AndroidSupport Repository, Google USB Driver e Google Play services.

– Clique no botão Install

• Instalação e configuração da IDE Eclipse de acordo com (DEITEL & ASSOCIATES,

INC., 2015; DEITEL; DEITEL; DEITEL, 2015);

– Descompacte o arquivo zip no local desejado


– Selecione o menu Window->Preferences e selecione Android no lado esquerdoda tela

– Em SDK Location, no lado direito da tela, certifique/selecione o diretório deinstalação do Android SDK.

– Finalize a IDE.

• Instalação e configuração do Android Development Tools (ADT) Plugin para Eclipsede acordo com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015);

– Selecione o menu Help -> Install New Software

– Clique no botão Add no lado direito da tela

– Informe o nome em Name, e em Location, entre a url https://dl-ssl.google.com/android/eclipse/

– Clique OK e aguarde o download do plugin

– Na lista de software disponíveis, quando Developer Tools for exibido marque-oe clique em Next/Finish.

• Instalação e configuração do Android Virtual Device (AVD) Manager de acordocom (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015);

75


– Selecione o menu Window -> Android Virtual Device Manager. A partir doAVD Manager será possível criar e configurar emuladores dos dispositivos mó-veis, para os quais se deseja que a aplicação/apk desenvolvida seja executada/-testada.

3. Execução e testes da aplicação no ambiente de programação (IDE).

• Caso seja necessário adicionar alguma biblioteca para um determinado projeto sigaos passos a seguir:

– Depois de realizado o download do pacote Android Support Repository, atravésdo SDK Manager na opção Extras, o arquivo de bibliotecas poderá ser locali-zado em <sdk>/extras/. Onde <sdk> representa o diretório raiz de instalaçãodo SDK. Pode-se clicar com o botão direito sobre o projeto e escolher propri-edades. Na tela que se abre, no lado esquerdo, selecionar Java Build Path eno lado direito selecionar Libraries. Em seguida deve-se clicar no botão querepresenta o tipo de biblioteca de suporte pretende-se adicionar, “navegar” atéonde se encontra o arquivo e selecioná-lo.

– Depois de localizado o arquivo de biblioteca, no Project Explorer do lador es-querda na IDE, deve-se clicar com o botão direito sobre o arquivo, escolherBuild Path->Configure Build Path.

– Por útimo clicar novamente, com botão direito, sobre o projeto e selecionarpropriedades. Na tela que se abre, no lado esquerdo, selecionar Android, e nolado direito em Library clicar em Add. Na tela que se abre selecionar a opçãodesejada.

• Para executar a aplicação clicar no botão Run apk, na barra de ferramentas da IDE.A IDE poderá solicitar o AVD no qual se deseja que a aplicação execute.

4. Geração do arquivo *.apk para distribuição/instalação/execução do jogo/aplicativo.

• Execute a IDE Eclipse

– Selecione o menu File -> Export

– Na tela que se abre selecione Android -> Export Android Aplication e cliqueno botão Next.

– Na tela que se abre selecione o projeto para o qual se deseja gerar o arquivo*.apk e clique no botão OK.

– Na tela seguinte selecione uma das seguintes opções: usar chave existente oucriar uma nova. Em seguida informe a senha e clique no botão OK.

– Na próxima tela clique no botão Next.

– Na tela seguinte informe o destino do arquivo *.apk.

– Transfira e instale o *.apk para o Smartphone ou Tablet e execute o aplicativo.

76

5.2.4 Dinâmica do jogo PLAY’ed-SCRUM’ces

Ao executar/”rodar” o jogo PLAY’ed-SCRUM’ces, em um dispositivo móvel Android(Smartphone ou Tablet), a tela de login/identificação, representada pela figura 18, será exibida.

Figura 18 – Tela de Login


O usuário/jogador deverá informar o login e senha. Caso ele já tenha sido cadastrado é só cli-car/”tocar” no botão OK, caso contrário deverá selecionar/marcar a opção Novo Jogador, antesde clicar/”tocar” no botão OK. O jogador poderá também clicar/”tocar” no botão CANCEL ouna opção de menu Sair, caso ele não deseje mais prosseguir com a execução do jogo. Ao “logar”no jogo/aplicativo, uma tela de “boas vindas”, representada pela figura 19, será exibida.

77

Figura 19 – Tela de Boas Vindas


A partir deste momento o jogador tem acesso a todas as funcionalidades do jogo/apli-cativo. Na tela de boas vindas é exibida uma breve descrição dos objetivos/motivos de cria-ção/implementação do jogo PLAY’ed-SCRUM’ces. Com os respectivos autor e orientador. Ojogador poderá então executar uma das seguintes ações/funcionalidades de menu: iniciar umanova partida, visualizar as regras do jogo, estudar/apreender o conteúdo abordado no jogo ousair/interromper o aplicativo/jogo. Outras funcionalidades como pausar e/ou parar/interrompera partida serão acessíveis após o jogador iniciar uma nova partida.

Após iniciada uma partida não será permitido executar a ação de estudar até que a par-tida seja finalizada ou paralisada/interrompida. Dependendo da ação/funcionalidade executadaas opções de menu podem mudar para “atender” a tela resultante da ação. Existem tambémoutras importantes funcionalidades como: visualizar resultados de uma partida e visualizar par-tida; ambas também sendo exemplificadas mais abaixo de como e quando ocorrem.

Ação – Visualizar as Regras do Jogo

Ao “consultar” as regras do jogo a tela, representada pela figura 20, será exibida. O jo-gador poderá/deverá “rolar/deslizar” a tela na vertical para conseguir visualizar todas as regras.

78

Figura 20 – Regras do Jogo


Ação – Visualizar o Conteúdo de Estudo do Jogo

Ao acessar o conteúdo de/para estudo/aprendizagem do jogo a tela, representada pelafigura 21, será exibida. O jogador poderá/deverá “rolar/deslizar” a tela na vertical/horizontalpara conseguir visualizar todo o conteúdo de estudo de cada “página”.

79

Figura 21 – Conteúdo de Estudo do Jogo


80

Ação - Iniciar uma nova Partida

Ao iniciar uma nova partida a tela inicial de nova partida, representada pela figura 22,será exibida.

Figura 22 – Tela de Início de uma Nova Partida


No topo desta tela e abaixo das opções de menu, são exibidas informações como: o temporestante de jogo (que vai decrescendo a medida que o tempo passa), o nível do jogo em que ojogador atualmente se encontra (são três níveis ao todo), e a questão que o jogador atualmenteestá/irá responder (neste caso a primeira questão do primeiro nível). Logo abaixo, no caso destatela, um assunto/conteúdo/conceito introdutório para auxiliar no entendimento/resposta daquelaquestão, localizada logo abaixo, e possivelmente de outras questões nas telas seguintes. O quequer dizer que esta introdução poderá ser referente a apenas à questão atual ou possivelmente aoutras questões seguintes a esta. Isso estará definido no próprio assunto introdutório. Portantohaverão telas que terão tal introdução e outras que não.

Logo mais abaixo vem a pergunta da questão, acompanhada de suas possíveis alter-nativas de respostas. Cada questão informa ao jogador o número máximo de alternativas quepoderá/deverá ser escolhido/marcado. Ao “rolar/deslizar” a tela um pouco para baixo será pos-sível visualizar o(s) botão(ões) de “navegação” de cada tela (no caso desta tela só existe o botãopara “navegar/passar” para a próxima questão/tela). Através destes botões será possível “nave-gar/passar” para próxima questão/nível ou voltar/retornar a questão/nível anterior. Na segunda

81

e última questão/tela do primeiro nível, por exemplo, representadas pela figura 23, é possívelvisualizar os dois botões de navegação.

Figura 23 – Botões de Navegação


Estes botões, quando clicados/”tocados”, também fazem com que as informações presentes notopo de cada questão/tela sejam atualizadas. No caso da segunda tela desta figura, ao clicar nobotão de Próximo fará com que a primeira questão/tela (questão 1) do próximo nível (nível 2)seja exibida.

A seguir, as telas da primeira e última questão dos níveis dois e três são representadaspela figura 24.

82

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


83

Na última questão/tela do nível treis (última tela desta figura), ao clicar no botão Fim, a telacom os resultados da partida será exibida.

Ação – Visualizar Resultados da Partida

A tela com os resultados de uma partida será exibida nas seguintes situações: quando ojogador clicar/tocar no botão FIM DO JOGO (última questão do último nível); quando o tempopara a partida terminar (decrescendo até chegar em zero); ou quando o jogador optar por pa-rar/interromper a partida. Um exemplo de tela com os resultados para uma partida pode servisto a seguir, representado pela figura 25.

84

Figura 25 – Resultados de uma Partida


85

Ação – Pausar uma Partida

Depois de iniciada uma partida, ela poderá ser “pausada”, a qualquer momento, quandoo jogador assim desejar. Isto será possível através da opção de menu Pausar. A figura 26 repre-senta um exemplo de tela com a partida “pausada”.

Figura 26 – Tela de uma Partida Pausada


A partir deste momento não será mais possível interagir com os “controles” da tela (exceto oscontroles de opções de menu), até que a partida seja “retomada”/continuada. O que pode serfeito clicando/”tocando” na opção de menu CONTINUAR.

Ação – Parar/Interromper uma Partida

Depois de iniciada uma partida, ela poderá ser “parada”/interrompida, a qualquer mo-mento, quando o jogador assim desejar. Isto será possível tanto através da opção de menuParar quanto pelo botão de retornar/voltar do dispositivo móvel (Smartphone/Tablet). Utili-zando a opção de menu Parar o jogador será “advertido” sobre sua decisão, para que o mesmopossa confirmá-la ou não. A figura 27 representa um exemplo de partida onde o jogador cli-cou/”tocou” na opção de menu Parar.

86

Figura 27 – Tela de uma Partida sendo Parada


Caso o jogador confirme sua ação, através do botão OK, a tela com os resultados da partidaserá exibida. Do contrário continuará a partida normalmente.

Ação – Visualizar Partida

Na tela de resultados, ao “rolar/deslizar” até a “base”, será possível visualizar o botãoVISUALIZAR PARTIDA (ex: última tela da figura 25). Ao clicar/”tocar” neste botão o jogadorpoderá “navegar” por toda a partida. Sendo que a cada questão/tela serão exibidas informaçõescomo: a quantidade de pontos que "vale"a questão; a pontuação adquirida pelo jogador naquestão; e as alternativas corretas da questão. Dessa forma o jogador poderá visualizar o assun-to/conteúdo do qual a questão se refere e pelo resultado obtido, se será necessário um melhorentendimento (estudar mais) ou não tal conteúdo. Como exemplo, a figura 28, representamalgumas das telas de uma partida finalizada/parada, sendo visualizada pelo jogador.

87

Figura 28 – Visualização de uma Partida


88

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

89

6 CONCLUSÕES E TRABALHOS FUTUROS

Neste capítulo serão apresentadas as conclusões e propostas de possíveis trabalhos futu-ros. As conclusões serão apresentadas com uma avaliação comparativa do que se propôs a fazercom o que de fato foi feito/realizado e com algumas ponderações.

6.1 Conclusões

Como principal objetivo este trabalho visou projetar e desenvolver um jogo educacionaldigital, para dispositivos móveis Android (Smartphone/Tablet), para avaliar/auxiliar o ensino-aprendizagem de conceitos sobre a metodologia ágil SCRUM. Diante deste contexto este tra-balho foi estruturado em etapas e subetapas, sendo cada uma delas subdividas em atividades“menores”. A medida que estas atividades iam sendo executadas e seus resultados “somados”,com aqueles de atividades anteriores, o objetivo maior aos poucos ia sendo alcançado.

Foram previstas quatro etapas, sendo a quarta subdivida e originando outras quatro novassubetapas, com cada uma, novamente, compostas por suas respectivas atividades. As etapasde um a três objetivavam basicamente a uma fundamentação/embasamento teórico a respeitoda literatura sobre os respectivos assuntos dos quais se tratavam. Assuntos estes escolhidosde forma deliberadamente para permitir tanto há um embasamento teórico por parte do autor,como também, possibilitar ao leitor “comum” (que não fosse da área de Computação) ter umavisão geral de como pode-se dá um processo de desenvolvimento e gerência de um projeto desoftware. E a quarta etapa objetivava ao projeto/desenvolvimento do jogo.

Na primeira etapa se propôs fazer uma análise/revisão/fundamentação da literatura paraEngenharia de Software, Gerência de Projetos e SCRUM. Para a ES os resultados obtidos foramde acordo com uma das principais referências para a área. Foram apresentadas uma definição ea “visão” em “camadas” e com foco na qualidade, do autor, para a ES. Para a GP utilizou-se aprincipal referência na área para se chegar aos resultados. Foram apresentadas definições e umabreve apresentação dos principais conceitos (requisitos, fases, processos etc) que devem estarpresentes durante a gerência de um projeto. Já para o SCRUM, cuja fundamentação teórica éuma das mais importantes deste trabalho, os resultados deveriam ser apresentados de forma apermitir um entendimento mais aprofundado sobre o assunto. Para tanto foram apresentadospara o Scrum: seus principais conceitos (definição, “teorias” base, os principais componentesbásicos etc) segundo os idealizadores desta metodologia; uma visão geral dos ciclos (Sprint’s)e uma visão mais aprofundada do framework Scrum, segundo um dos principais “guia” paraScrum.

Na segunda etapa se propôs fazer uma análise da literatura para Ensino-Aprendizageme Jogos-Educacionais. Para o EA os resultados foram alcançados a partir de referências “situ-adas” em diferentes espaços de tempo, mas que na sua maioria com uma opinião em comumpara o EA (trata-se de um processo fortemente influenciado pela Psicologia ao longo do tempo).

90

Foram apresentadas algumas definições e uma outra fundamentação das mais importantes destetrabalho, que são o Design Instrucional e mais especificamente a metodologia ADDIE utiliza-da/empregada neste trabalho para o desenvolvimento do DI/JE. Para os JE os resultados foram aapresentação de algumas definições e classificações para os tipos de jogos. Nas referências uti-lizadas é possível perceber a importância que os JE podem exercer no processo de EA, segundoseu autores. De acordo com o mesmos, os aspectos de jogos (divertidos, desperta interesse etc)aliados, de forma adequada, aos aspectos de instrução podem formar um recurso poderoso paraauxiliar no processo de EA.

Na terceira etapa se propôs fazer uma revisão dos JE existentes na literatura para o EA deES/SCRUM. Os resultados alcançados, tanto para os JE de ES quanto para os de SCRUM, foramas análises destes jogos e a representação dos dados através de tabelas. Facilitando, dessa forma,o entendimentos destes dados por parte do leitor. Algumas das informações analisadas foram:objetivos de aprendizagem, nível de aprendizagem, público-alvo, modo de iteração, resultadosde avaliações, tipo do jogo etc. Com os resultados apresentados nesta etapa e considerando quealguns dos jogos que foram analisados já existem desde 2007, é possível inferir que os JE estãoganhando cada vez mais “popularidade”, como recurso de apoio ao processo de EA. E ao quetudo indica, esse parece ser um caminho sem volta.

A quarta etapa deu origem as seguintes subetapas: Análise/Projeto Instrucional; Análi-se/Projeto do Jogo; Fundamentação teórica/prática sobre Programação para Dispositivos Mó-veis Android e Implementação. Sendo todas essas quatro subetapas baseadas nas três primeirasfases do modelo ADDIE. De forma que a primeira subetapa representando as fases de Aná-lise e Design do modelo ADDIE, e as outras três representando a fase de Desenvolvimento domodelo. E os resultados obtidos ao fim destas subetapas/fases vão formando/originando umDesign Instrucional do qual o jogo PLAY’ed-SCRUM’ces é parte integrante.

Na primeira subetapa da etapa quatro se propôs fazer a Análise Instrucional e o ProjetoInstrucional do Design Instrucional, cujo o jogo PLAY’ed-SCRUM’ces será parte integrante.Os resultados alcançados para a Análise Instrucional foram: a definição de um possível público-alvo, formado basicamente por estudantes de Scrum; a definição de alguns possíveis contextosinstrucionais para a aplicação do jogo; e a definição das metas e/ou objetivos de aprendizagemque o jogador deverá atingir após jogar uma partida do jogo. Para o Projeto Instrucional osresultados alcançados são: a definição do conteúdo educacional para o jogo; a definição dasequência de apresentação para o conteúdo educacional; e a definição de estratégias de ensinode forma a garantir que as metas/objetivos educacionais sejam atingidos.

Na segunda subetapa da etapa quatro se propôs fazer a Análise e o Projeto para o jogo.Os resultados alcançados foram: a modelagem do jogo PLAY’ed-SCRUM’ces, com a criaçãodo diagrama DER (definição das tabelas/relacionamentos para o banco de dados do jogo), acriação do diagrama Casos de Uso (algumas das principais funcionalidades do jogo), a criaçãodo diagrama de Classes (algumas das principais classes do jogo/aplicativo); e a definição dealguns aspectos de jogos para o jogo PLAY’ed-SCRUM’ces, como a navegabilidade para ojogo, e a criação e/ou definição das regras do jogo.

91

Na terceira subetapa da etapa quatro se propôs fazer a fundamentação teórica/práticada literatura para programação de aplicativos para dispositivos móveis Android. Os resultadosalcançados foram: identificação e obtenção dos recursos/ferramentas necessários; instalação econfiguração destes recursos; “criação”/execução/testes de aplicativos de exemplo; e geraçãodo arquivo *.apk para distribuição.

Na quarta e última subetapa da etapa quatro se propôs fazer a codificação/implementa-ção do aplicativo/jogo. Os resultados alcançados foram: o aplicativo/jogo foi codificado/imple-mentado/criado; testes foram feitos/realizados durante e após a codificação; o arquivo *.apk, doaplicativo, foi gerado, “transferido”/distribuído e instalado/executado.

6.1.1 Algumas ponderações

Por toda a estrutura deste trabalho procurou-se usar o máximo de recursos visuais e deformatação, de forma a permitir/proporcionar uma melhor apresentação do texto/assunto dosquais estes tratavam. E como consequência permitir com que tais assuntos fossem assimiladosmais facilmente pelo leitor. Muitos recursos visuais como: figuras, tabelas etc; e de forma-tação como: capítulos, seções, subseções, parágrafos, endentação/citação, fonte “destacada”,itemização etc; estão presentes por todo o trabalho desde o primeiro até o último capítulo. Fo-ram ainda adicionados assuntos “extras”, através de apêndices, para proporcionar ao leitor ummelhor entendimento do conteúdo educacional presente no jogo PLAY’ed-SCRUM’ces.

Durante a realização dos testes do jogo/aplicativo - PLAY’ed-SCRUM’ces, ou simples-mente durante uma partida pelo simples ato de jogar, ou mesmo ainda utilizando/navegandopor outras funcionalidades no PLAY’ed-SCRUM’ces; foi possível se ter uma “ideia”/”noção”de quão interessante/estimulante pode ser a experiência de se utilizar/jogar este tipo de aplica-tivo/jogo em dispositivos móveis como Smartphone e/ou Tablets.

De certa forma essa agradável ”impressão”/experiência é bastante compreensível, pois ojogador/estudante tem, “ali”, a um simples toque de seus dedos, todo um conteúdo educacional,que ele poderá “acessar”, caso seja de seu interesse ou por pura necessidade mesmo, a qualquerhora, em qualquer lugar. Melhor ainda, este conteúdo está em “formato” de um jogo, o quesignifica que ele pode aprender “brincando”/divertindo-se.

Acredito que alguns outros fatores, falando especificamente do PLAY’ed-SCRUM’ces,foram também responsáveis por essa agradável experiência. Dentre os quais pode-se citar: oconteúdo do jogo; a forma como o conteúdo foi “estruturado” e está sendo apresentado ao joga-dor; a navegabilidade/dinâmica do jogo; a forma como os resultados estão sendo apresentados;e as possibilidades/funcionalidades disponibilizadas etc; estão influenciando diretamente e deforma positiva nesta “impressão” que tive ao testar/utilizar/jogar o jogo/aplicativo PLAY’ed-SCRUM’ces.

Nas etapas 2 e 3, apesar de utilizadas as principais referências na área e a breve ex-planação sobre os assuntos, ainda sim, a citação de mais referências poderia “enriquecer” os

92

argumentos apresentados. Na etapa 4 (com suas respectivas subetapas) foi onde se deu a “cria-ção” do Design Instrucional cujo jogo PLAY’ed-SCRUM’ces é parte integrante.

Estes resultados foram alcançados graças a utilização/emprego de um modelo utilizadopara criação de Design Instrucionais – o modelo ADDIE. Acontece que foram “executadas”apenas as três primeiras fases deste modelo – Análise, Projeto e Desenvolvimento. De formaque o DI resultante ficou/está incompleto. Restando ainda acrescentar ao DI resultante, os resul-tados das fases Implementação/Aplicação e Avaliação. Fases estas responsáveis, basicamente,pela execução/aplicação e avaliação do DI resultante das três primeiras fases. Dessa formapode-se dizer que: o DI desenvolvido não foi testado (colocado à prova), e por isso sua eficáciaainda não foi comprovada.

Por fim, pode-se dizer também que o jogo, apesar de disponibilizar muitos recursosgráficos como imagens, não disponibiliza quase ou nenhum recurso gráfico como animaçõese/ou “bonecos” etc; o que tinha sido previsto fazer na subetapa 2 da etapa 4.

6.2 Propostas de Possíveis Trabalhos Futuros

• Como mencionado anteriormente, o Design Instrucional (DI) desenvolvido neste traba-lho, e cujo jogo PLAY’ed-SCRUM’ces é parte integrante, ficou/está “incompleto”. Fal-tando ainda os resultados das fases Implementação/Aplicação e Avaliação – do modeloADDIE. Fases estas responsáveis, basicamente, pela execução/aplicação e avaliação doDI resultante das três primeiras fases. Portanto uma possível proposta de trabalho a serfeito/realizado é a execução/aplicação e avaliação de resultados para o DI (jogo/aplica-tivo) desenvolvido neste trabalho.

• Considerando os seguintes fatos: o jogo PLAY’ed-SCRUM’ces é um jogo educativo, porisso seu principal objetivo é o de auxiliar o processo de Ensino-Aprendizagem do Scrum;em um ambiente universitário ou empresarial, onde exista algum curso sobre Scrum,este jogo pode ser utilizado como recurso de auxílio/apoio etc. Diante desse contexto,uma outra possível proposta de trabalho futuro é criar um segundo “módulo” para o jogoPLAY’ed-SCRUM’ces. De forma que, o que já está pronto constituiria o módulo de usuá-rio/jogador e o novo módulo seria o de administrador. Através do qual, todo o conteúdoeducacional do jogo seria gerenciado. Além disso a base de dados (banco de dados) dojogo PLAY’ed-SCRUM’ces agora não seria mais “local” (no próprio dispositivo móvel),mas em um local “remoto” e compartilhada/acessada por todos os módulos clientes (mó-dulo de usuário/jogador). Gerenciada, também, pelo administrador do módulo adminis-trador. Este administrador poderia ser um professor de ES, e como tal incluir, visualizar,alterar, excluir etc o conteúdo educacional do jogo. Além é claro, de poder analisar osdados de resultados das partidas realizadas por seus alunos. Proporcionando ao professoruma “poderosa” ferramenta/mecanismo para avaliar o processo de ensino-aprendizagemdo Scrum.

93

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

94

Referências

ABES SOFTWARE. Mercado brasileiro de software: Panorama e Tendências.São Paulo, p. 6–9, jun. 2015. Edição 2015 Dados de 2014. Disponível em:<http://central.abessoftware.com.br/Content/UploadedFiles/Arquivos/DadosAcesso em: 9mar. 2016.

ABT, Clark C. Serious Games. 2. ed. University Press of America, 1987. Disponí-vel em: <https://books.google.co.in/books/about/Serious_Games.html?id=axUs9HA-hF8C>.Acesso em: 11 may 2016.

BATTISTELLA, Paulo E.; WANGENHEIM, Christiane G. von; FERNANDES, João M. Comojogos educacionais são desenvolvidos?: Uma revisão sistemática da literatura. Florianópolis-SC, jul. 2014. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/wei/2014/0014.pdf>.Acesso em: 29 feb. 2016.

BENITTI, Fabiane Barreto Vavassori; MOLLéRI, Jefferson Seide. Utilização de umrpg no ensino de gerenciamento e processo de desenvolvimento de software. In:SBC - SOCIEDADE BRASILEIRA DE COMPUTAçÃO, XXVIII., 2008, Pará. Pará:Sociedade Brasileira de Computação, 2008. p. 443. Ref. 258–267. Disponível em:<http://www.lbd.dcc.ufmg.br/colecoes/wei/2008/0030.pdf>. Acesso em: 20 mar. 2016.

BLOOM, Benjamin S. Taxonomy of Educational Objectives Book 1: Cogni-tive Domain. 2. ed. Addison Wesley Publishing Company, 1984. Disponível em:<https://books.google.co.in/books/about/Taxonomy_of_Educational_Objectives.html?id=hos6AAAAIAAJ>.Acesso em: 5 nov. 2016.

BONWELL, Charles C.; EISON, James A. Active learning: Creating excite-ment in the classroom.: Eric digest. Washington-DC, 1991. Disponível em:<http://documents.manchester.ac.uk/display.aspx?DocID=19800>. Acesso em: 6 nov.2016.

BRAGA, Juliana Cristina. Objetos de Aprendizagem: Metodologia de De-senvolvimento. 1. ed. Santo André - SP: UFABC, 2015. Disponível em:<http://proec.ufabc.edu.br/uab/metdesOA2/2014-BRAGA-livro-oa.pdf>. Acesso em: 4mar. 2016.

CAMARGO, André Stangarlin de. Jogo de RPG para Ensinar SCRUM. 2013. 103 f.Monografia (Bacharel em Ciências da Computação) — Departamento de Informáticae Estatística, Universidade Federal de Santa Catarina, Florianópolis. Disponível em:<http://www.gqs.ufsc.br/wp-content/uploads/2011/11/TCC-Andre-Camargo-vf.pdf>. Acessoem: 29 fev. 2016.

CEVIU. 2016. Disponível em: <http://www.ceviu.com.br/buscar/empregos?termoPesquisa=Scrum>.Acesso em: 29 fev. 2016.

CHAPMAN, Alan. blooms taxonomy - learning domains. 2009. Disponível em:<http://www.businessballs.com/bloomstaxonomyoflearningdomains.htm>. Acesso em: 5 nov.2016.

CLARK, Donald. ADDIE Model. 7 1995. Atualizado em 6 de Setembro de 2015. Disponívelem: <http://nwlink.com/ donclark/history_isd/addie.html>. Acesso em: 5 nov. 2016.

95

CMS - CENTER FOR MEDICARE & MEDICAID SERVICES. Se-lecting a development approach. Maryland, fev. 2005. Disponível em:<https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf>. Acesso em: 28 fev.2016.

CROSS, K. Patricia. Teaching "for"learning. Carolina do Norte, p. 1–23, feb. 1987. Paper pre-sented at the North Carolina State University Centennial Year Provost’s Forum. Disponível em:<http://files.eric.ed.gov/fulltext/ED280537.pdf>. Acesso em: 1 mar. 2016.

DEITEL & ASSOCIATES, INC. Installing ADT Plug-In for Eclipse. 2015. Disponívelem: <http://www.deitel.com/bookresources/AndroidFP2/InstallAndroidSDKandEclipse.pdf>.Acesso em: 9 oct. 2016.

DEITEL, Paul; DEITEL, Harvey; DEITEL, Abbey. Android How to Program:with an introduction to java. 2. ed. Pearson Education, Inc, 2015. Disponível em:<http://www.deitel.com/Books/Android/AndroidHowtoProgram2e/tabid/3654/Default.aspx>.Acesso em: 19 jul. 2016.

DEMPSEY, CJohn V.; RASMUSSEN, Karen; LUCASSEN, Barbara. The instructionalgaming literature: Implications and 99 sources. 1996. Technical Report 96-1. Disponível em:<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.2287&rep=rep1&type=pdf>.Acesso em: 6 nov. 2016.

DJAOUTI, Damien et al. Origins of Serious Games. [s.n.], 2011. Disponível em:<http://www.ludoscience.com/EN/diffusion/551-Origins-of-Serious-Games.html>. Acessoem: 29 may 2016.

DRISCOLL, Marcy P. Psychology of learning for instruction. In: .3. ed. Florida: Pearson, 2004. cap. 1, p. 1–28. Disponível em:<http://ocw.metu.edu.tr/pluginfile.php/8344/mod_resource/content/1/Dris_2005.pdf>. Acessoem: 17 may 2016.

E-LEARNING. ADDIE Instructional Design Model. 2016. Disponível em:<http://www.about-elearning.com/addie-instructional-design-model.html>. Acesso em:10 mar. 2016.

E-LEARNING. Instructional Design Principles and Foundations. 2016. Disponível em:<http://www.about-elearning.com/instructional-design.html>. Acesso em: 10 mar. 2016.

FILATRO, Andrea Cristina. Design instrucional contextualizado: educa-ção e tecnologia. 3. ed. São Paulo: Senac São Paulo, 2004. Disponível em:<http://www.editorasenacsp.com.br/portal/produto.do?appAction=vwProdutoDetalhe&idProduto=20142>.Acesso em: 4 mar. 2016.

FILATRO, Andrea Cristina. Design Instrucional na Prática. 1. ed. Pearson Educationdo Brasil, 2008. Disponível em: <http://loja.pearson.com.br/design-instrucional-na-pratica-9788576051886/p>. Acesso em: 5 nov. 2016.

FONSECA, João José Saraiva da. Metodologia da Pesquisa Científica. Ceará,2002. 127 p. Disponível em: <http://www.ia.ufrrj.br/ppgea/conteudo/conteudo-2012-1/1SF/Sandra/apostilaMetodologia.pdf>. Acesso em: 25 mar. 2016.

96

GARTNER INC. Gartner says worldwide software market grew 4.8 percent in 2013. Stamford/-Connecticut, mar. 2014. Disponível em: <http://www.gartner.com/newsroom/id/2696317>.Acesso em: 13 mar. 2016.

GKRITSI, Aikaterini. Scrum Game: An Agile Software Management Game. 2011. 96 p.Tese (MSc Software Engineering) — School of Electronics and Computer Science Faculty ofEngineering, Science and Mathematics University of Southampton, Southampton. Disponívelem: <http://eprints.soton.ac.uk/272775/1.hasCoversheetVersion/MSc_Final.pdf>. Acesso em:29 fev. 2016.

GONçALVES, Susana. Teorias da aprendizagem. Coimbra: Mcgraw Hill, 1993.

INTULOGY. The ADDIE Process. 2016. Disponível em: <http://intulogy.com/addie/>.Acesso em: 5 nov. 2016.

KNIBERG, Henrik. Scrum and XP from the Trenches: How we do Scrum. [S.l.]: InfoQ,2007.

KRIVITSKY, Alexey. Scrum Simulation with LEGO Bricks. 2009. Disponível em:<http://kiev2016.agileee.org/wp-content/uploads/2011/12/Scrum-Simulation-with-LEGO-Bricks-v2.0.pdf>. Acesso em: 23 mar. 2016.

KUBO, Olga Mitsue; BOTOMé, Sílvio Paulo. Ensino-aprendizagem: Uma intera-ção entre dois processos comportamentais. Florianópolis, p. 1–19, 2001. Departa-mento de Psicologia da Universidade Federal de Santa Catarina. Disponível em:<http://revistas.ufpr.br/psicologia/article/view/3321/2665>. Acesso em: 18 may 2016.

LARMAN, Craig. Agile and Iterative Development: A Manager’sGuide. 2. ed. Boston/MA: Pearson Education, Inc., 2004. Disponívelem: <https://books.google.com.br/books?id=76rnV5Exs50C&pg=PR5&hl=pt-BR&source=gbs_selected_pages&cad=2#v=onepage&q&f=false>. Acesso em: 2 mar.2016.

LARMAN, Craig; BASILI, Victor R. Iterative and incremental development: A Brief His-tory. jun. 2003. Disponível em: <http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf>. Acesso em: 2 mar. 2016.

LEITãO, Michele de Vasconcelos. Aplicação de Scrum em Ambiente de Desenvolvimentode Software Educativo. 2010. 72 f. Monografia (Bacharel em Engenharia da Computação)— Escola Politécnica de Pernambuco – Universidade de Pernambuco, Recife. Disponível em:<http://tcc.ecomp.poli.br/20101/TCC_final_Michele.pdf>. Acesso em: 9 mar. 2016.

LINKEDIN. 2016. Disponível em: <https://www.linkedin.com/jobs/scrum-jobs?trk=jserp_search_button_execute>. Acesso em: 29 fev. 2016.

LINO, Juliana Izabel. Proposta de um Jogo Edcucacional para a Área de Medição e Aná-lise de Software. 2007. 243 f. Monografia (Bacharel em Sistemas de Informação) — Univer-sidade Federal de Santa Catarina, Florianópolis. Disponível em: <http://www.gqs.ufsc.br/wp-content/uploads/2011/11/2007_Juliana_Izabel_Lino.pdf>. Acesso em: 18 may 2016.

MA, Minhua; OIKONOMOU, Andreas; JAIN, Lakhmi C. Serious Ga-mes and Edutainment Applications. Springer-Verlag, 2011. Disponível em:<http://radar.gsa.ac.uk/2068/4/SpringerSGEdutainmentBookFront-matter.pdf>. Acessoem: 29 may 2016.

97

MANIFESTO Ágial: Princípios por trás do Manifesto Ágil. 2001. Disponível em:<http://www.manifestoagil.com.br/principios.html>. Acesso em: 12 mar. 2016.

MATARELLI, Maria; WHEATON, Harvey. 2015 State of Scrum Report. 2015. Disponívelem: <https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/FilesAcesso em: 16mar. 2016.

MERRIENBOER, Jeroen J. G. Van. Training Complex Cogni-tive Skills: A four-component instructional design model for tech-nical training. Educational Technology Pubns, 1997. Disponível em:<https://books.google.com.br/books/about/Training_Complex_Cognitive_Skills.html?id=o0I3IXLfXuAC&redir_esc=y>.

MICHAEL, David; CHEN, Sande. Serious Games: Games That Educate,Train, and Inform. 1. ed. Cengage Learning PTR, 2005. Disponível em:<http://uap.unnes.ac.id/ebook/ebookpalace/Course.Technology.PTR.Serious.Games.Games.That.Educate.Train.and.Inform.Sep.2005.eBook-DDU/Course.Technology.PTR.Serious.Games.Games.That.Educate.Train.and.Inform.Sep.2005.eBook-DDU.pdf>. Acesso em: 6 nov. 2016.

MOLENDA, Michael. In search of the elusive addie model. Indiana, jun. 2003. Pu-blished in slightly amended form in Performance Improvement, May/June 2003. Disponívelem: <http://www.comp.dit.ie/dgordon/Courses/ILT/ILT0004/InSearchofElusiveADDIE.pdf>.Acesso em: 4 nov. 2016.

MORRIS, Joseph M. Software industry accounting. In: . Wiley e Book. 2.ed. New York: John Wiley & Sons, Inc., 2001. cap. 1, p. 1–4. Disponível em:<https://books.google.com.br/books?id=fPyXeuK3DVEC>. Acesso em: 10 mar. 2016.

NAVARRO, Emily. SimSE: A Software Engineering Simulation Environment forSoftware Process Education. 2006. 321 p. Tese (Doctor of Philosophy in Informationand Computer Science) — University of California, Irvine, California. Disponível em:<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.5381&rep=rep1&type=pdf>.Acesso em: 12 mar. 2016.

NETO, Erasmo Isotton. Scrumming: Ferramenta Educacional para Ensino de Práticas doSCRUM. 2008. 80 f. Monografia (Bacharelado em Sistemas de Informação) — Faculdade deInformática, Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre. Disponí-vel em: <xps-project.googlecode.com/svn/trunk/scrum/Scrumming.pdf>. Acesso em: 4 mar.2016.

OLIVEIRA, BRUNO CÉSAR DE. TestEG - UM SOFTWARE EDUCACIONALPARA O ENSINO DE TESTE DE SOFTWARE. 2013. 92 f. Monografia (Bacha-rel em Ciência da Computação) — Universidade Federal de Lavras, LAVRAS. Dis-ponível em: <http://www.bcc.ufla.br/wp-content/uploads/2013/09/TestEG-UM-SOFTWARE-EDUCACIONAL-PARA-O-ENSINO-DE-TESTE-DE-SOFTWARE-.pdf>. Acesso em: 27feb. 2016.

ORACLE. JDK Installation for Microsoft Windows. 2014. Disponível em:<https://www.oracle.com/index.html>. Acesso em: 9 oct. 2016.

PIAZZA, ALEXIS. Melhoria de uma Unidade Instrucional para Planejamento deCustos de Projetos de Software. 2012. 102 f. Monografia (Bacharel em Sistemasde Informação) — Universidade Federal de Santa Catarina, Florianópolis. Disponí-vel em: <http://www.gqs.ufsc.br/wp-content/uploads/2013/02/TCC_AlexisPiazza_vf.pdf>.Acesso em: 4 nov. 2016.

98

PMI INC. Guia PMBOK: Um Guia do Conhecimento em Gerenciamento de Proje-tos. 5. ed. Pennsylvania: Project Management Institute, Inc., 2013. Disponível em:<https://andreysmith.files.wordpress.com/2015/03/pmbok-5c2aa-edic3a7c3a3o.pdf>. Acessoem: 12 mar. 2016.

PRESSMAN, Roger S. Software engineering: a practitioner’s approach. In: . 5. ed. NewYork: McGraw-Hill, 2001. cap. 31, p. 829–833. Acesso em: 12 apr. 2016.

PRESSMAN, Roger S. Engenharia de software - uma abordagem profissional. In: .7. ed. Porto Alegre: AMGH Editora Ltda, 2011. cap. 1, p. 38–45. Disponível em:<http://www.resource.mitfiles.com/IT/IIAcesso em: 11 apr. 2016.

QUARESMA, Leandro. Processo ensino-aprendizagem: do conceito à análise do atualprocesso. 2016. Disponível em: <http://www.academia.edu/4936831/Processo_Ensino-Aprendizagem_do_Conceito_Acesso em: 17 may 2016.

RITTINGHOUSE, John W. Managing Software Deliverables: A Software Deve-lopment Management Methodology. Massachusetts: Elsevier, 2004. Disponível em:<https://books.google.com.br/books?id=t5VPlbBtMVIC>. Acesso em: 15 mar. 2016.

RUBIN, Kenneth S. Essential SCRUM: A Practical Guide to the Most Po-pular Agile Process. 1. ed. Michigan: Addison-Wesley, 2013. Disponível em:<http://deca.cuc.edu.cn/Community/media/p/17439.aspx>. Acesso em: 12 mar. 2016.

SATPATHY, Tridibesh et al. Guia SBOK: Um Guia para o Conhecimentoem Scrum. Edição 2016. Arizona: SCRUMstudy, 2016. Disponível em:<http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2013-Portuguese.pdf>.Acesso em: 17 mar. 2016.

SAVI, Rafael. Avaliação de Jogos Voltados para a Disseminação do Conhecimento.2011. 236 p. Tese (Doutor em Engenharia e Gestão do Conhecimento) — Uni-versidade Federal de Santa Catarina, Programa de Pós-Graduação em Engenharia eGestão do Conhecimento, Santa Catarina. Disponível em: <http://btd.egc.ufsc.br/wp-content/uploads/2011/12/RafaelSavi.pdf>. Acesso em: 12 mar. 2016.

SCHAEFER, Ben. The Latest Statistics, Surveys and Studies: Into the SCRUM.2015. Disponível em: <https://www.pmi.org/ /media/PDF/Publications/state-of-scrum-by-the-numbers.ashx>. Acesso em: 16 mar. 2016.

SCHNEIDER, Marcelo Frantz. SCRUM’ed: um jogo de RPG para ensinar Scrum. 2015.98 f. Monografia (Bacharel em Sistemas de Informação) — Departamento de Informá-tica e Estatística, Universidade Federal de Santa Catarina, Florianópolis/SC. Disponível em:<http://www.gqs.ufsc.br/wpcontent/uploads/2011/11/TCCfinal_SCRUMed.pdf>. Acesso em:27 fev. 2016.

SCHWABER, Ken; SUTHERLAND, Jeff. Guia do scrum: Um guia de-finitivo para o Scrum: As regras do jogo. Jul. 2013. Disponível em:<http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf>.Acesso em: 26 fev. 2016.

SCHWABER, Ken; SUTHERLAND, Jeff. The scrum guide: The Defini-tive Guide to Scrum: The Rules of the Game. Jul. 2013. Disponível em:<http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf>. Acesso em: 26fev. 2016.

99

SCRUM.ORG. 2016. Disponível em: <https://www.scrum.org/Courses>. Acesso em: 16 mar.2016.

SHORE, James; WARDEN, Shane. The art of agile deve-lopment. Mary O’Brien, San Francisco, 2008. Disponível em:<https://poetiosity.files.wordpress.com/2011/04/art_of_agile_development.pdf>. Acessoem: 16 mar. 2016.

SILLER, Felipe; BRAGA, Juliana Cristina. Software educacional para prá-tica do scrum. Santo André – SP, may 2013. Disponível em: <www.br-ie.org/pub/index.php/wcbie/article/download/2664/2318>. Acesso em: 8 jun. 2016.

SOUSA, Sónia Marlene Pereira de. Play Scrum: Um Jogo para aAprendizagem do Método Ágil Scrum. 2009. 84 f. Tese (Mestradoem Informática) — Universidade do Minho, Braga. Disponível em:<http://mei.di.uminho.pt/sites/default/files/dissertacoes/eeum_di_dissertacao_pg10919.pdf>.Acesso em: 29 fev. 2016.

THE STANDISH GROUP INTERNATIONAL INC. Chaos manifesto 2013:Think Big, Act Small. 2013. Edição 2013 Dados de 2012. Disponível em:<https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf>. Acesso em:29 fev. 2016.

UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS. Métodos de Pesquisa: Cursode Graduação Tecnológica - Planejamento e Gestão para o Desenvolvimento Rural. RioGrande do Sul, 2009. 120 p. (EAD, Série Educação a Distância). Disponível em:<http://www.ufrgs.br/cursopgdr/downloadsSerie/derad005.pdf>. Acesso em: 25 mar. 2016.

WANGENHEIM, Christiane Gresse von. learning game-based. jul. 2012. Dis-ponível em: <http://www.inf.ufsc.br/ c.wangenheim/download/CSBC2012-ComoEnsinarComJogos_Wangenheim_vf.pdf>. Acesso em: 23 mar. 2016.

WANGENHEIM, Christiane Gresse von. SCRUMIA: An Educational Game for Tea-ching SCRUM in Computing Courses. 2013. Disponível em: <http://www.gqs.ufsc.br/wp-content/uploads/2013/06/SCRUMIA-Description-vE20-2013.pdf>. Acesso em: 23 mar. 2016.

WIKIPEDIA. Software development. ago. 2014. Disponível em:<https://en.wikipedia.org/wiki/Software_development>. Acesso em: 28 fev. 2016.

WIKIPEDIA. ADDIE Model. 2016. Disponível em: <https://en.wikipedia.org/wiki/ADDIE_Model>.Acesso em: 1 mar. 2016.

WIKIPEDIA. Educational game. 2016. Disponível em:<https://en.wikipedia.org/wiki/Educational_game>. Acesso em: 9 mar. 2016.

WIKIPEDIA. Educational technology. 2016. Disponível em:<https://en.wikipedia.org/wiki/Educational_technology>. Acesso em: 9 mar. 2016.

WIKIPEDIA. Ensino. 2016. Disponível em: <https://pt.wikipedia.org/wiki/Ensino>. Acessoem: 11 may 2016.

WIKIPEDIA. Game. 2016. Disponível em: <https://en.wikipedia.org/wiki/Game>. Acessoem: 9 mar. 2016.

100

Appendices

101

A CONTEÚDO EDUCACIONAL PARA O JOGO PLAY’ED-SCRUM’CES - PARTEPRÁTICA

Esta parte do conteúdo educacional para o jogo PLAY’ed-SCRUM’ces é composta por pergun-tas/questões “fechadas”, distribuídas entre 3 “níveis” de dificuldade. Com as perguntas do nível1 apresentando o menor grau de dificuldade, as perguntas do nível 2 com um grau de dificul-dade maior que aquelas do primeiro, e no terceiro e último nível as perguntas de mais alto graude dificuldade. As perguntas “fechadas” possuem um número de alternativas/opções variandode 5 até 8, sendo que os níveis 1 e 2 são compostos por 15 perguntas cada e o terceiro nível écomposto por 19 perguntas.

Peguntas do nível 1

Dentre as práticas fundamentais para a adoção/implantação da metodologia do framework Scrumdestacam-se os Eventos do Scrum, os Artefatos do Scrum e os Papéis do Scrum.

Os eventos Scrum são “fechados” (time-boxed) com uma duração mínima e máxima previa-mente estabelecidos, e objetivam, entre outras coisas, a definição de uma rotina/ciclo evitandoa necessidade de eventuais encontros não planejados. Além disso, uma outra principal carac-terística destes eventos é tornar as práticas/processos do Scrum o mais transparentes possívelpara todas as partes integrantes/interessadas. Considerando estas ponderações e o conhecimentoadquirido sobre tais conceitos do Scrum, escolha a alternativa que melhor define cada um doseventos do Scrum nas questões que se seguem.

1. O evento Reunião Diária é?

a) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá otrabalho a ser realizado durante o ciclo e que possui um time-boxed de no máximo 8horas.

b) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao finalde um ciclo, participam o Time Scrum e Stakeholders e onde uma versão do produto seráapresentada para avaliação e disponibilização ao cliente.

c) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-mento sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentose programa as tarefas para o dia seguinte.

d) Um evento considerado como o principal do Scrum, representando um ciclo completodo Scrum e um “contêiner” para outros eventos, possui um time-boxed com duração deno máximo um mês e durante o qual uma versão utilizável do produto será desenvolvida.

e) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui umtime-boxed de no máximo 3 horas de duração e representa uma oportunidade para rever otrabalho que foi realizado durante um ciclo. Dessa forma possibilitando ao Time Scrumidentificar e adotar práticas, que serão implementadas no próximo ciclo, para melhorar otrabalho/desempenho do mesmo.

2. O evento Retrospectiva do Ciclo Scrum é?

102

a) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui umtime-boxed de no máximo 3 horas de duração e representa uma oportunidade para rever otrabalho que foi realizado durante um ciclo. Dessa forma possibilitando ao Time Scrumidentificar e adotar práticas, que serão implementadas no próximo ciclo, para melhorar otrabalho/desempenho do mesmo.

b) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-mento sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentose programa as tarefas para o dia seguinte.

c) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá otrabalho a ser realizado durante o ciclo e que possui um time-boxed de no máximo 8horas.

d) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao finalde um ciclo, participam o Time Scrum e Stakeholders e onde uma versão do produto seráapresentada para avaliação e disponibilização ao cliente.

e) Um evento considerado como o principal do Scrum, representando um ciclo completodo Scrum e um “contêiner” para outros eventos, possui um time-boxed com duração deno máximo um mês e durante o qual uma versão utilizável do produto será desenvolvida.

3. O evento Revisão do Ciclo Scrum é?

a) Um evento considerado como o principal do Scrum, representando um ciclo completodo Scrum e um “contêiner” para outros eventos, possui um time-boxed com duração deno máximo um mês e durante o qual uma versão utilizável do produto será desenvolvida.

b) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui umtime-boxed de no máximo 3 horas de duração e representa uma oportunidade para rever otrabalho que foi realizado durante um ciclo. Dessa forma possibilitando ao Time Scrumidentificar e adotar práticas, que serão implementadas no próximo ciclo, para melhorar otrabalho/desempenho do mesmo.

c) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao finalde um ciclo, participam o Time Scrum e Stakeholders e onde uma versão do produto seráapresentada para avaliação e disponibilização ao cliente.

d) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá otrabalho a ser realizado durante o ciclo e que possui um time-boxed de no máximo 8horas.

e) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-mento sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentose programa as tarefas para o dia seguinte.

4. O evento Sprint é?

a) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui umtime-boxed de no máximo 3 horas de duração e representa uma oportunidade para rever otrabalho que foi realizado durante um ciclo. Dessa forma possibilitando ao Time Scrumidentificar e adotar práticas, que serão implementadas no próximo ciclo, para melhorar otrabalho/desempenho do mesmo.

103

b) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao finalde um ciclo, participam o Time Scrum e Stakeholders e onde uma versão do produto seráapresentada para avaliação e disponibilização ao cliente.

c) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-mento sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentose programa as tarefas para o dia seguinte.

d) Um evento considerado como o principal do Scrum, representando um ciclo completodo Scrum e um “contêiner” para outros eventos, possui um time-boxed com duração deno máximo um mês e durante o qual uma versão utilizável do produto será desenvolvida.

e) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá otrabalho a ser realizado durante o ciclo e que possui um time-boxed de no máximo 8horas.

5. O evento Reunião de Planejamento do Ciclo é?

a) Um evento que possui um time-boxed de 15 minutos, em que a Equipe de Desenvolvi-mento sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentose programa as tarefas para o dia seguinte.

b) Um evento considerado como o principal do Scrum, representando um ciclo completodo Scrum e um “contêiner” para outros eventos, possui um time-boxed com duração deno máximo um mês e durante o qual uma versão utilizável do produto será desenvolvida.

c) Um evento que ocorre no início de um ciclo Scrum, onde o Time Scrum definirá otrabalho a ser realizado durante o ciclo e que possui um time-boxed de no máximo 8horas.

d) Um evento que possui um time-boxed de no máximo 4 horas, ocorre próximo ao finalde um ciclo, participam o Time Scrum e Stakeholders e onde uma versão do produto seráapresentada para avaliação e disponibilização ao cliente.

e) Um evento que ocorre no final de um ciclo Scrum, para “fechar” o ciclo. Possui umtime-boxed de no máximo 3 horas de duração e representa uma oportunidade para rever otrabalho que foi realizado durante um ciclo. Dessa forma possibilitando ao Time Scrumidentificar e adotar práticas, que serão implementadas no próximo ciclo, para melhorar otrabalho/desempenho do mesmo.

Os Artefatos do Scrum representam o trabalho e/ou o “valor do negócio”, e permitem maistransparência e oportunidades para inspeções e adaptações. Considerando estas ponderaçõese o conhecimento adquirido sobre tais conceitos do Scrum, escolha a alternativa que melhordefine cada um dos Artefatos do Scrum nas questões que se seguem.

6. O Artefato Taskboard é?

a) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-vidades planejadas para o Sprint, possibilitando o acompanhamento das mesmas. Esterecurso deverá está acessível a todos os colaboradores e ser atualizado constantemente.

104

b) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-cionados de um lista maior. Os itens presentes nesta lista determinam as funcionalidadesque devem estar presentes na próxima versão do produto e possuem uma estimativa dotrabalho que será necessário para que o objetivo seja atingido.

c) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-sibilita a detecção de possíveis desvios e deve ser atualizado diariamente. Neste gráficoo eixo vertical representa uma estimativa do esforço/trabalho restante em horas e o eixohorizontal representa os dias que compreendem o Sprint atual.

d) Representa o conjunto de todos os requisitos/funcionalidades completados até o Sprintatual, somados com todos aqueles que já foram desenvolvidos nos Sprint’s passados,resultando em uma nova versão utilizável do produto.

e) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário(funções, requisitos, melhorias etc) para ao desenvolvimento do produto ou serviço. Estalista é muito dinâmica, mudando constantemente para representar o que o produto neces-sita e existirá enquanto este existir. Os itens presentes nesta lista possuem os atributos dedescrição, ordem, estimativa e valor.

7. O Artefato Incremento do Produto é?

a) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-sibilita a detecção de possíveis desvios e deve ser atualizado diariamente. Neste gráficoo eixo vertical representa uma estimativa do esforço/trabalho restante em horas e o eixohorizontal representa os dias que compreendem o Sprint atual.

b) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário(funções, requisitos, melhorias etc) para ao desenvolvimento do produto ou serviço. Estalista é muito dinâmica, mudando constantemente para representar o que o produto neces-sita e existirá enquanto este existir. Os itens presentes nesta lista possuem os atributos dedescrição, ordem, estimativa e valor.

c) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-vidades planejadas para o Sprint, possibilitando o acompanhamento das mesmas. Esterecurso deverá está acessível a todos os colaboradores e ser atualizado constantemente.


e) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-cionados de um lista maior. Os itens presentes nesta lista determinam as funcionalidadesque devem estar presentes na próxima versão do produto e possuem uma estimativa dotrabalho que será necessário para que o objetivo seja atingido.

8. O Artefato Backlog do Sprint é?

a) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário(funções, requisitos, melhorias etc) para ao desenvolvimento do produto ou serviço. Estalista é muito dinâmica, mudando constantemente para representar o que o produto neces-sita e existirá enquanto este existir. Os itens presentes nesta lista possuem os atributos dedescrição, ordem, estimativa e valor.

105

b) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-sibilita a detecção de possíveis desvios e deve ser atualizado diariamente. Neste gráficoo eixo vertical representa uma estimativa do esforço/trabalho restante em horas e o eixohorizontal representa os dias que compreendem o Sprint atual.

c) Representa o conjunto de todos os requisitos/funcionalidades completados até o Sprintatual, somados com todos aqueles que já foram desenvolvidos nos Sprint’s passados,resultando em uma nova versão utilizável do produto.

d) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-vidades planejadas para o Sprint, possibilitando o acompanhamento das mesmas. Esterecurso deverá está acessível a todos os colaboradores e ser atualizado constantemente.

e) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-cionados de um lista maior. Os itens presentes nesta lista determinam as funcionalidadesque devem estar presentes na próxima versão do produto e possuem uma estimativa dotrabalho que será necessário para que o objetivo seja atingido.

9. O Artefato Burndown Chart é?

a) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-sibilita a detecção de possíveis desvios e deve ser atualizado diariamente. Neste gráficoo eixo vertical representa uma estimativa do esforço/trabalho restante em horas e o eixohorizontal representa os dias que compreendem o Sprint atual.

b) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-cionados de um lista maior. Os itens presentes nesta lista determinam as funcionalidadesque devem estar presentes na próxima versão do produto e possuem uma estimativa dotrabalho que será necessário para que o objetivo seja atingido.

c) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário(funções, requisitos, melhorias etc) para ao desenvolvimento do produto ou serviço. Estalista é muito dinâmica, mudando constantemente para representar o que o produto neces-sita e existirá enquanto este existir. Os itens presentes nesta lista possuem os atributos dedescrição, ordem, estimativa e valor.


e) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-vidades planejadas para o Sprint, possibilitando o acompanhamento das mesmas. Esterecurso deverá está acessível a todos os colaboradores e ser atualizado constantemente.

10. O Artefato Backlog Priorizado do Produto é?

a) Uma lista de tarefas a serem executadas no próximo Sprint, cujo os itens foram sele-cionados de um lista maior. Os itens presentes nesta lista determinam as funcionalidadesque devem estar presentes na próxima versão do produto e possuem uma estimativa dotrabalho que será necessário para que o objetivo seja atingido.

b) Uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário(funções, requisitos, melhorias etc) para ao desenvolvimento do produto ou serviço. Esta

106

lista é muito dinâmica, mudando constantemente para representar o que o produto neces-sita e existirá enquanto este existir. Os itens presentes nesta lista possuem os atributos dedescrição, ordem, estimativa e valor.

c) Um recurso utilizado para auxiliar na “visualização” do progresso/evolução das ati-vidades planejadas para o Sprint, possibilitando o acompanhamento das mesmas. Esterecurso deverá está acessível a todos os colaboradores e ser atualizado constantemente.

d) Um gráfico que representa o progresso dos trabalhos/esforços durante um Sprint, pos-sibilita a detecção de possíveis desvios e deve ser atualizado diariamente. Neste gráficoo eixo vertical representa uma estimativa do esforço/trabalho restante em horas e o eixohorizontal representa os dias que compreendem o Sprint atual.

e) Representa o conjunto de todos os requisitos/funcionalidades completados até o Sprintatual, somados com todos aqueles que já foram desenvolvidos nos Sprint’s passados, re-sultando em uma nova versão utilizável do produto.

Os Papéis do Scrum são/estão associados ao Time Scrum, que representa grupo(s) auto-organizáveise multifuncionais. Um grupo auto-organizável é o responsável por definir a melhor forma paraconcluir seu trabalho e portanto não precisa ser gerenciado por alguém fora do grupo. Em umgrupo multifuncional os membros são providos de todas as habilidades necessárias para com-pletar seu trabalho e portanto não dependem de pessoas de fora do grupo. O modelo de time noScrum foi pensado para melhorar a flexibilidade, criatividade e produtividade de seus integran-tes. Além dos Papéis-Centrais do Scrum existem também os Papéis Não-Essenciais no Scrum,considerados como sendo não obrigatórios para um projeto Scrum e/ou por não estarem con-tinuamente/diretamente envolvidos no processo Scrum. Considerando estas ponderações e oconhecimento adquirido sobre tais conceitos do Scrum, escolha a alternativa que melhor definecada um dos Papéis do Scrum nas questões que se seguem.

11. O Papel Scrum Master é?

a) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-petências essenciais da organização do projeto.

b) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-preensão e criação da Visão do Projeto. Colaboram com o Time Scrum na definição/iden-tificação dos requisitos de funcionalidades que deverão estar presentes na versão final doproduto. Esperam que suas necessidades sejam “traduzidas” para o produto final de talforma que este poça proporcionar o maior valor possível para o seu negócio.

c) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade doScrum. Trabalha para que as teorias, práticas e regras do Scrum sejam compreendidas eexecutadas por todos, tanto por parte dos integrantes do Time Scrum quanto por aquelesde fora do Time. Atua como um facilitador para o Time Scrum na realização de suasatividades.

d) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-cremento utilizável do “produto” no final de cada ciclo Sprint. São auto-organizados emultifuncionais, são eles próprios os responsáveis por organizar e gerenciar seu própriotrabalho. Deve ser composto por um grupo com um mínimo de 3 e máximo de 9 colabo-radores.

107

e) O responsável, entre outras coisas, por maximizar o valor do negócio para o projeto,mantendo sua justificativa de negócio e garantindo que o Time Scrum entregue valorpara o negócio do cliente. Representa a voz do cliente e portanto é o articulador dasnecessidades e prioridades deste para com o Time Scrum. É também o único responsávelpor gerenciar o Backlog do Produto.

12. O Papel Stakeholders é?

a) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-preensão e criação da Visão do Projeto. Colaboram com o Time Scrum na definição/iden-tificação dos requisitos de funcionalidades que deverão estar presentes na versão final doproduto. Esperam que suas necessidades sejam “traduzidas” para o produto final de talforma que este poça proporcionar o maior valor possível para o seu negócio.

b) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade doScrum. Trabalha para que as teorias, práticas e regras do Scrum sejam compreendidas eexecutadas por todos, tanto por parte dos integrantes do Time Scrum quanto por aquelesde fora do Time. Atua como um facilitador para o Time Scrum na realização de suasatividades.

c) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-cremento utilizável do “produto” no final de cada ciclo Sprint. São auto-organizados emultifuncionais, são eles próprios os responsáveis por organizar e gerenciar seu própriotrabalho. Deve ser composto por um grupo com um mínimo de 3 e máximo de 9 colabo-radores.

d) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-petências essenciais da organização do projeto.


13. O Papel Fornecedores é?

a) O responsável, entre outras coisas, por maximizar o valor do negócio para o projeto,mantendo sua justificativa de negócio e garantindo que o Time Scrum entregue valorpara o negócio do cliente. Representa a voz do cliente e portanto é o articulador dasnecessidades e prioridades deste para com o Time Scrum. É também o único responsávelpor gerenciar o Backlog do Produto.

b) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-petências essenciais da organização do projeto.

c) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-preensão e criação da Visão do Projeto. Colaboram com o Time Scrum na definição/iden-tificação dos requisitos de funcionalidades que deverão estar presentes na versão final doproduto. Esperam que suas necessidades sejam “traduzidas” para o produto final de talforma que este poça proporcionar o maior valor possível para o seu negócio.

108

d) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade doScrum. Trabalha para que as teorias, práticas e regras do Scrum sejam compreendidas eexecutadas por todos, tanto por parte dos integrantes do Time Scrum quanto por aquelesde fora do Time. Atua como um facilitador para o Time Scrum na realização de suasatividades.

e) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-cremento utilizável do “produto” no final de cada ciclo Sprint. São auto-organizados emultifuncionais, são eles próprios os responsáveis por organizar e gerenciar seu própriotrabalho. Deve ser composto por um grupo com um mínimo de 3 e máximo de 9 colabo-radores.

14. O Papel Equipe de Desenvolvimento é?

a) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-petências essenciais da organização do projeto.

b) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-cremento utilizável do “produto” no final de cada ciclo Sprint. São auto-organizados emultifuncionais, são eles próprios os responsáveis por organizar e gerenciar seu própriotrabalho. Deve ser composto por um grupo com um mínimo de 3 e máximo de 9 colabo-radores.

c) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade doScrum. Trabalha para que as teorias, práticas e regras do Scrum sejam compreendidas eexecutadas por todos, tanto por parte dos integrantes do Time Scrum quanto por aquelesde fora do Time. Atua como um facilitador para o Time Scrum na realização de suasatividades.

d) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-preensão e criação da Visão do Projeto. Colaboram com o Time Scrum na definição/iden-tificação dos requisitos de funcionalidades que deverão estar presentes na versão final doproduto. Esperam que suas necessidades sejam “traduzidas” para o produto final de talforma que este poça proporcionar o maior valor possível para o seu negócio.


15. O Papel Produto Owner é?

a) Os responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/in-cremento utilizável do “produto” no final de cada ciclo Sprint. São auto-organizados emultifuncionais, são eles próprios os responsáveis por organizar e gerenciar seu própriotrabalho. Deve ser composto por um grupo com um mínimo de 3 e máximo de 9 colabo-radores.

b) Os responsáveis por fornecerem produtos e/ou serviços que não estão dentro das com-petências essenciais da organização do projeto.

109

c) O responsável, entre outras coisas, por maximizar o valor do negócio para o projeto,mantendo sua justificativa de negócio e garantindo que o Time Scrum entregue valorpara o negócio do cliente. Representa a voz do cliente e portanto é o articulador dasnecessidades e prioridades deste para com o Time Scrum. É também o único responsávelpor gerenciar o Backlog do Produto.

d) O responsável, entre outras coisas, por garantir o entendimento e aplicabilidade doScrum. Trabalha para que as teorias, práticas e regras do Scrum sejam compreendidas eexecutadas por todos, tanto por parte dos integrantes do Time Scrum quanto por aquelesde fora do Time. Atua como um facilitador para o Time Scrum na realização de suasatividades.

e) Os responsáveis por interagirem com o Time Scrum auxiliando no entendimento, com-preensão e criação da Visão do Projeto. Colaboram com o Time Scrum na definição/iden-tificação dos requisitos de funcionalidades que deverão estar presentes na versão final doproduto. Esperam que suas necessidades sejam “traduzidas” para o produto final de talforma que este poça proporcionar o maior valor possível para o seu negócio.


Como dito anteriormente dentre as práticas fundamentais para a adoção/implantação da meto-dologia do framework Scrum destacam-se os Eventos do Scrum, os Artefatos do Scrum e osPaipéis do Scrum.

Considerando as relações/interações entre as práticas Eventos do Scrum com os Artefatos doScrum bem como de suas implicações, responda as questões que se seguem.

Obs – Deverão ser marcadas o máximo de alternativas possíveis.

1. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Retrospectivado Sprint?

a) Burndown Chart.

b) Backlog do Sprint.

c) Taskboard.

d) Backlog do Produto.

e) Incremento do Produto.

2. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Reunião Diá-ria?

a) Taskboard.

b) Incremento do Produto.

c) Burndown Chart.

110

d) Backlog do Sprint.

e) Backlog do Produto.

3. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Sprint?

a) Incremento do Produto.


c) Backlog do Produto.

d) Taskboard.

e) Burndown Chart.

4. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Revisão doSprint?

a) Taskboard.

b) Backlog do Produto.

c) Burndown Chart.

d) Incremento do Produto.

e) Backlog do Sprint.

5. Qual(is) o(s) artefato(s) produzido(s) e/ou atualizado(s) ao final do evento Reunião dePlanejamento do Sprint?

a) Backlog do Sprint.

b) Taskboard.


d) Incremento do Produto.

e) Burndown Chart.

Considerando agora as relações/interações entre as práticas Eventos do Scrum com os Papéisdo Scrum bem como de suas implicações, responda as questões que se seguem.


6. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Retros-pectiva do Sprint?

a) Stakeholders.

111

b) Scrum Master.

c) Fornecedores.

d) Produto Owner.

e) Equipe de Desenvolvimento.

7. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento ReuniãoDiária?

a) Fornecedores.

b) Stakeholders.

c) Scrum Master.

d) Equipe de Desenvolvimento.

e) Produto Owner.

8. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Revisãodo Sprint?

a) Produto Owner.

b) Scrum Master.

c) Equipe de Desenvolvimento.

d) Stakeholders.

e) Fornecedores.

9. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Reuniãode Planejamento do Sprint?

a) Equipe de Desenvolvimento.

b) Stakeholders.

c) Produto Owner.

d) Fornecedores.

e) Scrum Master.

10. Qual(is) o(s) papel(is) associados ou não ao Time Scrum participam do evento Sprint?

a) Scrum Master.

b) Produto Owner.

c) Stakeholders.

112

d) Fornecedores.

e) Equipe de Desenvolvimento.

Considerando agora as relações/interações entre as práticas Artefatos do Scrum com os Papéisdo Scrum bem como de suas implicações, responda as questões que se seguem.


11. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Stakeholders?

a) Backlog do Produto.


c) Taskboard.

d) Nenhum arterfato.

e) Backlog do Sprint.

f) Burndown Chart.

12. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Equipe de Desenvolvimento?

a) Taskboard.

b) Burndown Chart.


d) Backlog do Sprint.

e) Incremento do Produto.

f) Nenhum arterfato.

13. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Produto Owner?

a) Backlog do Sprint.


c) Burndown Chart.

d) Nenhum arterfato.

e) Taskboard.

f) Backlog do Produto.

14. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Fornecedores?

113

a) Backlog do Produto.


c) Incremento do Produto.

d) Burndown Chart.

e) Nenhum arterfato.

f) Taskboard.

15. Qual(is) o(s) artefato(s) é(são) gerenciado(s) pelo papel Scrum Master?

a) Nenhum arterfato.

b) Burndown Chart.

c) Incremento do Produto.

d) Backlog do Produto.

e) Taskboard.

f) Backlog do Sprint.


O Framework Scrum é formado por três “conjuntos de métodos/práticas” que constituem osfundamentos para esta metodologia. Este “conjuntos” são:

• Os Princípios do Framework Scrum;

• Os Aspectos do Framework Scrum; e

• Os Processos do Framework Scrum.

Os princípios do Scrum são imutáveis, devem ser seguidos a risca, enquanto que os aspectose processos do Scrum podem ser modificados para atender/adequar aos requisitos de projetoe/ou organizacionais. A compreensão das relações entre estes “conjuntos” são de fundamentalimportância para o entendimento do framework Scrum.

Considerando estas ponderações e o conhecimento adquirido sobre tais conceitos do Scrum,escolha a alternativa que melhor se aplica a cada um destes “conjuntos de métodos/práticas” doFramework Scrum nas questões que se seguem.

1. Quais são os Princípios do Framework Scrum?

a) Transparência; Inspeção; Adaptação.

b) Criar o Backlog Priorizado do Produto; Criar o Backlog do Sprint; Criar os Entregá-veis; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

114

c) Iniciar; Planejar e Estimar; Implementar; Revisão e Retrospectiva; Release.

d) Controle de Processos Empíricos; Auto-organização; Colaboração; Priorização Base-ada em Valor; Time-boxing; Desenvolvimento Iterativo.

e) Organização; Justificativa de Negócio; Qualidade; Mudanças; Riscos.

2. Quais são os Aspéctos do Framework Scrum?

a) Iniciar; Planejar e Estimar; Implementar; Revisão e Retrospectiva; Release.

b) Controle de Processos Empíricos; Auto-organização; Colaboração; Priorização Base-ada em Valor; Time-boxing; Desenvolvimento Iterativo.

c) Transparência; Inspeção; Adaptação.

d) Organização; Justificativa de Negócio; Qualidade; Mudanças; Riscos.

e) Criar o Backlog Priorizado do Produto; Criar o Backlog do Sprint; Criar os Entregá-veis; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

Os Processos do Framework Scrum incluem as atividades/práticas aplicadas durante um projetoScrum e a ordem em que as mesmas são empregadas. Ao todo são dezenove processos dividi-dos/agrupados em fases.

Considerando mais estas ponderações e o conhecimento adquirido sobre tais conceitos doScrum, escolha uma alternativa na questão a seguir.

3. Quais são as fases em que os Processos do Framework Scrum estão agrupados?

a) Organização; Justificativa de Negócio; Qualidade; Mudanças; Riscos.

b) Iniciar; Planejar e Estimar; Implementar; Revisão e Retrospectiva; Release.

c) Transparência; Inspeção; Adaptação.

d) Controle de Processos Empíricos; Auto-organização; Colaboração; Priorização Base-ada em Valor; Time-boxing; Desenvolvimento Iterativo.

e) Criar o Backlog Priorizado do Produto; Criar o Backlog do Sprint; Criar os Entregá-veis; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

Como dito anteriormente dentre as práticas fundamentais para a adoção/implantação da me-todologia do framework Scrum destacam-se os eventos, artefatos e papéis. Estas práticas sãoparte integrante dos princípios, aspectos e processos do framework Scrum e portanto definidaspor estes “conjuntos” de métodos/práticas. Os eventos são definidos pelos princípios do fra-mework, os artefatos são definidos pelos processos do framework, e os papéis pelos aspectosdo framework Scrum.

115

Considerando tais ponderações e o conhecimento adquirido sobre tais conceitos do Scrum, es-colha uma alternativa nas questões que se seguem.

4. Qual dos Princípios do Framework Scrum define os Eventos?

a) Controle de Processos Empíricos.

b) Auto-organização.

c) Colaboração.

d) Priorização Baseada em Valor.

e) Time-boxing.

f) Desenvolvimento Iterativo.

5. Qual dos Aspectos do Framework Scrum define os Papéis?

a) Organização.

b) Justificativa de Negócio.

c) Qualidade.

d) Mudanças.

e) Riscos.

As teorias empíricas utilizadas para controle de processos, são as teorias aplicadas na funda-mentação do framework Scrum. O empirismo declara que o conhecimento se constrói a partirde experiências e que as decisões deverão ser tomadas baseado neste conhecimento. O controlede processos empíricos é apoiado por três pilares que são:

• Transparência;

• Inspeção; e

• Adaptação.

No framework Scrum estes pilares fazem parte do princípio Controle de Processos Empíricos.

Considerando tais ponderações e o conhecimento adquirido sobre tais conceitos do Scrum, es-colha uma alternativa na questão que se segue.

6. Quais são as práticas do Framework Scrum em que os pilares do empirismo melhor seaplicam?

a) Eventos.

b) Artefatos.

116

c) Papeis.

d) Eventos e Artefatos.

f) Eventos e Papéis.

g) Artefatos e Papéis.

Como dito anteriormente os Processos do Scrum incluem as atividades/práticas aplicadas du-rante um projeto Scrum e a ordem em que as mesmas são empregadas. Ao todo são dezenoveprocessos divididos/agrupados em fases. As fases em que estes processos estão agrupados são:

1. Iniciar;

2. Planejar e Estimar;

3. Implementar;

4. Revisão e Retrospectiva; e

5. Release.

Considerando estas ponderações e o conhecimento adquirido sobre tais conceitos do Scrum,escolha uma alternativa nas questões que se seguem.

7. Quais são os processos do Framework Scrum agrupados na fase Iniciar?

a) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizadodo Produto.

b) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

c) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar oTime Scrum; Desenvolver os Épicos; Criar o Backlog Priorizado do Produto; Conduzir oPlanejamento da Release.

d) Enviar os Entregáveis; Retrospectiva do Projeto.

e) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;Criar as Tarefas; Estimar as Tarefas; Criar o Backlog do Sprint.

8. Quais são os processos do Framework Scrum agrupados na fase Planejar e Estimar?

a) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

b) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizadodo Produto.

c) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;Criar as Tarefas; Estimar as Tarefas; Criar o Backlog do Sprint.

d) Enviar os Entregáveis; Retrospectiva do Projeto.

117

e) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar oTime Scrum; Desenvolver os Épicos; Criar o Backlog Priorizado do Produto; Conduzir oPlanejamento da Release.

9. Quais são os processos do Framework Scrum agrupados na fase Implementar?

a) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;Criar as Tarefas; Estimar as Tarefas; Criar o Backlog do Sprint.

b) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizadodo Produto.

c) Enviar os Entregáveis; Retrospectiva do Projeto.

d) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar oTime Scrum; Desenvolver os Épicos; Criar o Backlog Priorizado do Produto; Conduzir oPlanejamento da Release.

e) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

10. Quais são os processos do Framework Scrum agrupados na fase Revisão e Retrospectiva?

a) Enviar os Entregáveis; Retrospectiva do Projeto.

b) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;Criar as Tarefas; Estimar as Tarefas; Criar o Backlog do Sprint.

c) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

d) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizadodo Produto.

e) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar oTime Scrum; Desenvolver os Épicos; Criar o Backlog Priorizado do Produto; Conduzir oPlanejamento da Release.

11. Quais são os processos do Framework Scrum agrupados na fase Release?

a) Criar a Visão do Projeto; Identificar o Scrum Master e o(s) Stakeholder(s); Formar oTime Scrum; Desenvolver os Épicos; Criar o Backlog Priorizado do Produto; Conduzir oPlanejamento da Release.

b) Enviar os Entregáveis; Retrospectiva do Projeto.

c) Criar as Estórias de Usuário; Aprovar, Estimar, e Comprometer as Estórias de Usuário;Criar as Tarefas; Estimar as Tarefas; Criar o Backlog do Sprint.

d) Convocar o Scrum de Scrums; Demonstrar e Validar o Sprint; Retrospectiva do Sprint.

e) Criar os Entregáveis; Conduzir a Reunião Diária; Refinamento do Backlog Priorizadodo Produto.

Para cada um dos dezenove processos do framework Scrum existem as entradas, ferramentas esaídas. Sendo que:

118

entradas - representam os pré-requisitos para originar o produto/resultado do processo;

ferramentas - representam os recursos necessários; e

saídas - representam os produtos/resultados do processo.

Considerando estas ponderações e o conhecimento adquirido sobre tais conceitos do Scrum,responda as questões que se seguem.

12. Considere as entradas, ferramentas e saídas a seguir:

Entradas Ferramentas Saídas-Time Central do Scrum -Expertise do Time -Entregável/Incremento do

Sprint-Backlog do Sprint -Scrumboard/Taskboard Atuali-

zado-Scrumboard/Taskboard -Registro de Impedimentos Atu-

alizado-Registro de Impedimentos

Dentre as opções de processos a seguir, selecione aquele cujas entradas, ferramentas esaídas, citadas acima, o representam ?

a) Criar a Visão do Projeto.

b) Identificar o Scrum Master e o(s) Stakeholder(s).

c) Criar o Backlog Priorizado do Produto.

d) Criar o Backlog do Sprint.

e) Criar os Entregáveis/Incrementos.

f) Conduzir a Reunião Diária.

g) Demonstrar e Validar o Sprint.

h) Retrospectiva do Sprint.


Entradas Ferramentas Saídas-Time Central do Scrum -Reunião de Revisão do Sprint -Entregáveis Aprovados e Acei-

tos-Entregáveis do Sprint-Backlog do Sprint-Critério de Pronto-Critérios de Aceitação da Estó-ria de Usuário 119











Entradas Ferramentas Saídas-Time Central do Scrum -Reunião de Planejamento do

Sprint-Backlog do Sprint

-Lista de Tarefas de Esforço Es-timado

-Gráfico Burndown do Sprint

-Duração do Sprint











120

Entradas Ferramentas Saídas-Scrum Master -Reunião de Retrospectiva do

Sprint-Pontos de Melhorias Acorda-dos

-Equipe de Desenvolvimento doScrum-“Saídas/Meios” de Demonstrare Validar o Sprint











Entradas Ferramentas Saídas-Declaração da Visão do Projeto -Critérios de Seleção -Scrum Master é Identificado-Produto Owner -Stakeholder(s) é(são) Identifi-

cados








121




Entradas Ferramentas Saídas-Equipe de Desenvolvimento doScrum

-Reunião Diária -Gráfico Burndown do SprintAtualizado

-Scrum Master -Três Perguntas Diárias -Registro de Impedimentos Atu-alizado

-Gráfico Burndown do Sprint-Registro de Impedimentos











Entradas Ferramentas Saídas-Caso de Negócios do Projeto -Reunião da Visão do Projeto -Declaração da Visão do Projeto

-Produto Owner é Identificado





122







Entradas Ferramentas Saídas-Time Central do Scrum -Métodos de Priorização de Es-

tórias de Usuário-Backlog Priorizado do Produto

-Épicos -Critério(s) de Pronto-Personas










123

B CONTEÚDO EDUCACIONAL PARA O JOGO PLAY’ED-SCRUM’CES - PARTETEÓRICA

Esta parte do conteúdo educacional para o jogo PLAY’ed-SCRUM’ces é composta por toda asubseção 2.3 do capítulo 2 deste trabalho. E foi estruturada, para ser exibida no jogo, com amesma sequência apresentada por esta subseção.

124