PLAY’ed-SCRUM’ces: UM JOGO EDUCACIONAL PARA AVALIAR E/OU AUXILIAR O ENSINO-APRENDIZAGEM DE SCRUM

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS ICEI - Instituto de Ciências Exatas e de Informática

Aporano Alves da Silva Torres

PLAY’ed-SCRUM’ces: UM JOGO EDUCACIONAL PARA AVALIAR E/OU AUXILIAR O ENSINO-APRENDIZAGEM DE SCRUM

Belo Horizonte - MG 8 de dezembro de 2016

Aporano Alves da Silva Torres

PLAY’ed-SCRUM’ces: UM JOGO EDUCACIONAL PARA AVALIAR E/OU AUXILIAR O ENSINO-APRENDIZAGEM DE 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 parcial para obtenção do título de Bacharel em Ciências da Computação. Orientador: Prof. Dr. Carlos Pietrobon Área de concentração: Engenharia de Software/SCRUM

Belo Horizonte - MG 8 de dezembro de 2016

Aporano Alves da Silva Torres

PLAY’ed-SCRUM’ces: UM JOGO EDUCACIONAL PARA AVALIAR E/OU AUXILIAR O ENSINO-APRENDIZAGEM DE 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 parcial para obtenção do título de Bacharel em Ciências da Computação. Orientador: Prof. Dr. Carlos Pietrobon Área de concentração: Engenharia de Software/SCRUM

Prof. Dr. Carlos Pietrobon - PUC Minas

Prof. Dr. - PUC Minas

Prof. Dr. - PUC Minas

Belo Horizonte - MG 8 de dezembro de 2016

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 estruturaçã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 responsá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 jogadores/profissionais uma maior motivação/atenção devido à uma maior interação dos mesmos 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, Metodologias, SCRUM, Ensino-Aprendizagem, Jogos Educativos, Design Instrucional, ADDIE.

Abstract The Software Industry has become one of the largest and most influential in contemporary 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 achievement. 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/attention due to their greater interaction with an environment closer to what these professionals 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 methodology. Key-words:

Software Engineering, Project Management, Processes, Methodologies,

SCRUM, Teaching-Learning, Educational Games, Instructional Design, ADDIE.

Lista de Figuras

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

Etapas da Pesquisa Científica . . . . . . . . . . . . . . . . . . . . . . . Camadas da Engenharia de Software . . . . . . . . . . . . . . . . . . . Projeto de Fase Única . . . . . . . . . . . . . . . . . . . . . . . . . . . Processos para Gerenciamento de Projetos . . . . . . . . . . . . . . . . Exemplo de Backlog Priorizado do Produto . . . . . . . . . . . . . . . . Exemplo de Backlog do Sprint . . . . . . . . . . . . . . . . . . . . . . Exemplo de Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Taskboard . . . . . . . . . . . . . . . . . . . . . . . . . . . Fluxo de Execução do Scrum para um Projeto . . . . . . . . . . . . . . Fundamentação do Framework Scrum . . . . . . . . . . . . . . . . . . . Princípios do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processos do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fases do modelo ADDIE . . . . . . . . . . . . . . . . . . . . . . . . . Categorias do domínio cognitivo segundo a taxonomia de Bloom (1956) Diagrama Entidade Relacionamento - DER . . . . . . . . . . . . . . . . Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tela de Boas Vindas . . . . . . . . . . . . . . . . . . . . . . . . . . . . Regras do Jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conteúdo de Estudo do Jogo . . . . . . . . . . . . . . . . . . . . . . . . Tela de Início de uma Nova Partida . . . . . . . . . . . . . . . . . . . . Botões de Navegação . . . . . . . . . . . . . . . . . . . . . . . . . . . Primeira e Última Telas do Nível 2 e 3 . . . . . . . . . . . . . . . . . . Resultados de uma Partida . . . . . . . . . . . . . . . . . . . . . . . . . Tela de uma Partida Pausada . . . . . . . . . . . . . . . . . . . . . . . . Tela de uma Partida sendo Parada . . . . . . . . . . . . . . . . . . . . . Visualização de uma Partida . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

18 22 26 27 30 31 31 32 33 34 35 37 45 47 70 71 72 77 78 79 80 81 82 83 85 86 87 88

Lista de Tabelas

1 2 3 4 5 6 7 8 9 10 11 12 13

Processos da Fase Iniciar . . . . . . . . . Processos da Fase Planejar e Estimar . . . Processos da Fase Implementar . . . . . . Processos da Fase Revisão e Retrospectiva Processos da Fase Release . . . . . . . . . Informações sobre o jogo SimSE . . . . . Informações sobre o jogo X-MED . . . . . Informações sobre o jogo TestEG . . . . . Informações sobre o jogo SCRUM-Scape . Informações sobre o jogo SCRUM’ed . . . Informações sobre o jogo Scrum Game . . Informações sobre o jogo Scrumming . . . Informações sobre o jogo Playing Scrum .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

38 39 40 40 41 50 52 53 55 56 58 62 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 1.1 Contextualização . . . . . . . . . . . . . . 1.2 Objetivos . . . . . . . . . . . . . . . . . . 1.2.1 Objetivo Geral . . . . . . . . . . . 1.3 Escopo/Limites do Trabalho . . . . . . . . 1.4 Métodos de Pesquisa . . . . . . . . . . . . 1.4.1 Tipos de Pesquisa . . . . . . . . . . 1.4.2 Etapas de uma Pesquisa . . . . . . . 1.4.3 Pesquisa Empregada neste Trabalho 1.5 Estrutura deste Trabalho . . . . . . . . . .

. . . . . . . . .

11 11 16 16 16 16 16 17 18 20

. . . . . . . . . . . . . .

22 22 22 23 24 24 24 25 26 26 27 28 28 32 34

. . . . .

42 42 44 44 47 47

4 ANÁLISE SOBRE JE PARA O EA DE ES/SCRUM 4.1 JE para o Ensino-Aprendizagem de ES . . . . . . . . . . . . . . . . . . . . . . . 4.2 JE para o Ensino-Aprendizagem de SCRUM . . . . . . . . . . . . . . . . . . . .

50 50 54

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

2 FUNDAMENTAÇÃO TEÓRICA PARA ES/GP/SCRUM 2.1 Engenharia de Software . . . . . . . . . . . . . . . . . 2.1.1 Processo de Software . . . . . . . . . . . . . . 2.1.2 Métodos/Práticas da Engenharia de Software . 2.1.3 Ferramentas de Software . . . . . . . . . . . . 2.2 Gerência de Projetos . . . . . . . . . . . . . . . . . . 2.2.1 Projeto . . . . . . . . . . . . . . . . . . . . . 2.2.2 Gerência de Projeto . . . . . . . . . . . . . . . 2.2.3 Ciclo de Vida do Projeto . . . . . . . . . . . . 2.2.4 Processos para Gerenciamento de Projetos . . . 2.3 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Teoria do Scrum . . . . . . . . . . . . . . . . 2.3.2 Principais Componentes do Scrum . . . . . . . 2.3.3 Visão Geral do Scrum . . . . . . . . . . . . . 2.3.4 O Framework SCRUM . . . . . . . . . . . . 3 FUNDAMENTAÇÃO TEÓRICA PARA EA/JE 3.1 Ensino-Aprendizagem . . . . . . . . . . . 3.1.1 Design Instrucional . . . . . . . . . 3.1.2 O Padrão/Modelo ADDIE . . . . . 3.1.3 Taxonomia de Bloom . . . . . . . . 3.2 Jogos Educacionais/Jogos “Sérios” . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . . . . . . .

. . . . .

5 DESENVOLVIMENTO/CRIAÇÃO DO JOGO PLAY’ed-SCRUM’ces 5.1 Análise/Projeto Instrucional . . . . . . . . . . . . . . . . . . . . . 5.1.1 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Desenvolvimento Instrucional . . . . . . . . . . . . . . . . . . . . 5.2.1 Diagramas do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . 5.2.2 Regras do jogo PLAY’ed-SCRUM’ces . . . . . . . . . . . . 5.2.3 Fundamentação teórica sobre a tecnologia Android/Java . . 5.2.4 Dinâmica do jogo PLAY’ed-SCRUM’ces . . . . . . . . . .

. . . . . . . .

66 66 66 67 69 69 72 74 77

6 CONCLUSÕES E TRABALHOS FUTUROS 6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Algumas ponderações . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Propostas de Possíveis Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . .

90 90 92 93

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Appendices

101

A Conteúdo Educacional para o Jogo PLAY’ed-SCRUM’ces - Parte Prática

102

B Conteúdo Educacional para o Jogo PLAY’ed-SCRUM’ces - Parte Teórica

124

1 INTRODUÇÃO

A Indústria de Software se tornou uma das maiores e mais influentes nas sociedades contemporâneas. Modificando, alterando, aumentando etc; a forma como pensamos, agimos e interagimos nestas sociedades. A influência abrange e provavelmente vai além dos contextos sociais, políticos e econômicos. Com essa importância segue-se a necessidade, cada vez mais crescente, de se produzir produtos, bens e serviços em quantidade, qualidade e complexidade cada vez maiores. Em conjunto com esse desenvolvimento da Indústria de Software segue-se a necessidade de uma melhor/maior estruturação, planejamento, construção e controle dos Processos de Desenvolvimento de Software que são amplamente empregados nesta indústria para uma melhor qualidade no Gerenciamento de Projetos de Software. Aumentando com isso as responsabilidades 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 popularidade, dentro da Engenharia de Software, são àquelas conhecidas como: Metodologias de Desenvolvimento Ágil. Em particular podemos destacar a utilização/aceitação cada vez mais crescente do método de desenvolvimento e gestão de projetos, SCRUM. Devido a essa maior aceitação/utilização do SCRUM os profissionais da área de Engenharia de Software estão se vendo na exigência de uma melhor qualificação a respeito deste método. No entanto, o mercado de software ainda carece de tais profissionais qualificados com os conhecimentos necessários para o emprego desta metodologia. Atualmente alguns modelos de ensino estão sendo utilizados para a aprendizagem do SCRUM, mas que na sua maioria são muito teóricos e manuais. Uma alternativa que está se tornando cada vez mais viável é o emprego de jogos digitais, capazes de despertar nos jogadores/profissionais uma maior motivação/atenção devido à uma maior interação dos mesmos com um ambiente próximo ao que estes profissionais irão encontrar na prática. Possibilitando com isso, de forma efetiva, auxiliar o ensino-aprendizagem de conceitos e práticas do SCRUM e consequente capacitação de profissionais nesta metodologia. Portanto este trabalho objetiva o desenvolvimento de um jogo educativo digital para dispositivos móveis Android (Smartphone/Tablet), para avaliar/auxiliar o ensino-aprendizagem de conceitos sobre a metodologia ágil SCRUM. Para o planejamento e desenvolvimento do jogo será empregada uma metodologia de ensino-aprendizagem, que possibilitará a criação de um projeto instrucional do qual o jogo será parte integrante, como ferramente instrucional.

1.1 Contextualização

A Indústria de Software movimentou cerca de $140 bilhões em receitas no mundo no ano 1998, de acordo com a International Data Corp., representando um aumento de 15% sobre 11

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

12

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

13

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

14

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

1.3 Escopo/Limites do Trabalho

1. Este trabalho se limita ao desenvolvimento de um jogo digital educacional, para dispositivos móveis Android – Smartphone e/ou Tablet. Portanto não sendo possível a utilização deste jogo/aplicativo em outros dispositivos móveis, baseados em outras plataformas e/ou sistemas operacionais (ex: Iphone/Apple etc). 2. O propósito do jogo será o de avaliar/auxiliar no ensino-aprendizagem dos conceitos sobre a metodologia ágil SCRUM. Portanto não sendo abordadas outras metodologias ágeis empregadas na Gerência de Projetos. 3. O jogo destina-se à apenas um jogador. Não será possível mais de um jogador simultaneamente. 4. O jogo não disponibilizará recursos gráficos como cenários etc; comuns em jogos do gênero RPG. A apresentação do conteúdo do jogo, através da interface com o usuário, será feita basicamente por “elementos” textuais e figuras.

1.4 Métodos de Pesquisa

Nesta subseção será feita uma breve explanação sobre os possíveis tipos de pesquisas científicas existentes; as possíveis etapas que compõem uma pesquisa científica; e um detalhamento maior sobre a pesquisa empregada neste trabalho bem como das etapas que a compreendem.

1.4.1 Tipos de Pesquisa

a) Quanto à Abordagem 16

a.1 Pesquisa Qualitativa Para (UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009), “A pesquisa qualitativa não se preocupa com representatividade numérica, mas, sim, com o aprofundamento da compreensão de um grupo social, de uma organização, etc.” a.2 Pesquisa Quantitativa Para (FONSECA, 2002), “Diferentemente da pesquisa qualitativa, os resultados da pesquisa quantitativa podem ser quantificados.” b) Quanto à Natureza b.1 Pesquisa Básica Para (UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009), “Objetiva gerar conhecimentos 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 conhecimentos para aplicação prática, dirigidos à solução de problemas específicos”. c) Quanto aos Objetivos c.1 Pesquisa Exploratória; c.2 Pesquisa Descritiva; c.3 Pesquisa Explicativa. d) Quanto aos Procedimentos d.1 Pesquisa Experimental; d.2 Pesquisa Bibliográfica; d.3 Pesquisa Documental; d.4 Pesquisa de Campo; d.5 Pesquisa Ex-Post-Facto; d.6 Pesquisa de Levantamento; d.7 Pesquisa com Survey; d.8 Estudo de Caso; d.9 Pesquisa Participante; d.10 Pesquisa-Ação; d.11 Pesquisa Etnográfica; d.12 Pesquisa Etnometodológica.

1.4.2 Etapas de uma Pesquisa

Através da figura 1 é possível identificar as etapas que compõem uma pesquisa científica.

17

Figura 1 – Etapas da Pesquisa Científica

Fonte: Quivy; Campenhoudt a citado e adaptado por (UNIVERSIDADE ABERTA DO BRASIL – UAB/UFRGS, 2009) a

Quivy & Campenhoudt, 1995

1.4.3 Pesquisa Empregada neste Trabalho

O método de pesquisa que será utilizado neste trabalho classifica-se como um método de pesquisa aplicada. O que significa que o desenvolvimento deste trabalho objetiva gerar conhecimento com consequente aplicação prática e direcionado à resolver/minimizar a um problema específico. Isto porque este trabalho objetiva desenvolver um jogo educacional (o conhecimento), para ser jogado por estudantes (a prática), para avaliar/auxiliar o ensino-aprendizagem de conceitos sobre SCRUM (resolver/solucionar a não aprendizagem total/parcial a respeito de conceitos de SCRUM). Este método de pesquisa será composto das seguintes etapas:

Etapa 1 - Fundamentação teórica sobre a literatura para ES/GP/SCRUM (parte da Etapa 2 na Figura 1) Será feita uma análise teórica de parte da literatura existente para a Engenharia de Software, Gerência de Projetos e em especialmente em relação a metodologia ágil SCRUM aplicada à GP. A seguir as atividades que compõem esta etapa: Atividade 1.1: Análise teórica de parte da literatura para a área de ES. Atividade 1.2: Análise teórica de parte da literatura para a área de GP. Atividade 1.3: Análise teórica de parte da literatura para a área de SCRUM. 18

Etapa 2 - Fundamentação teórica sobre a literatura para o Ensino-Aprendizagem e os Jogos Educacionais (como parte da Etapa 2 na Figura 1) Será feita uma análise teórica de parte da literatura existente para algumas das metodologias de Ensino-Aprendizagem bem como de suas aplicações por meio de jogos, conhecidos como Jogos Educacionais, como recursos didáticos. A seguir as atividades que compõem esta etapa: Atividade 2.1: Análise teórica de parte da literatura para a área de EA. Atividade 2.2: Análise teórica de parte da literatura para a área de JE.

Etapa 3 – Fundamentação teórica sobre a literatura de JE para o ensino-aprendizagem de ES/SCRUM (como parte da Etapa 2 na Figura 1) Será feita uma análise sobre os JE existentes na literatura para o ensino-aprendizagem da ES/SCRUM. A seguir as atividades que compõem esta etapa: Atividade 3.1: Análise de JE aplicados para ES. Atividade 3.2: Análise de JE aplicados para o SCRUM.

Etapa 4 – Desenvolvimento do Jogo (compreende a Etapa 3 e a Etapa 4 na Figura 1) Para o desenvolvimento do jogo será empregada uma metodologia de desenvolvimento que abranja a criação de jogos educacionais. Esta metodologia deverá contemplar tanto os aspectos relacionados a jogos (design de jogos) quanto os aspectos relacionados ao ensino/instrução (design instrucional) Savi (2011), Camargo (2013), Schneider (2015). A seguir as subetapas que compõem esta etapa:

Etapa 4.1 - Análise/Projeto Instrucional (como parte da Etapa 3 na Figura 1) Definição/Identificação dos conceitos pedagógicos que definem as instruções/conteúdo educacional do jogo. A seguir as atividades que compõem esta etapa: Atividade 4.1.1: Análise Instrucional - Definição de metas instrucionais, análise de contextos e de quais serão os objetivos de desempenho. Atividade 4.1.2: Projeto Instrucional - Definição do conteúdo a ser abordado bem como se dará a sequência do mesmo durante a dinâmica do jogo e quais serão as estratégias instrucionais.

Etapa 4.2 - Análise/Projeto do Jogo (como parte da Etapa 3 na Figura 1) Definição dos requisitos, tabelas, diagramas etc; bem como a identificação/desenvolvimento dos elementos constituintes do jogo, incluindo a dinâmica e as regras do jogo. A seguir as atividades que compõem esta etapa: 19

Atividade 4.2.1: Identificação/Definição de elementos que compõe o jogo. Atividade 4.2.2: Identificação/Definição da dinâmica do jogo. Atividade 4.2.3: Identificação/Definição das regras do jogo. Atividade 4.2.4: Levantamento dos Requisitos. Atividade 4.2.5: Modelagem de Dados. Atividade 4.2.6: Construção dos Diagramas (de classe etc).

Etapa 4.3 – Fundamentação teórica/prática sobre Programação para Dispositivos Móveis Android (como parte da Etapa 4 na Figura 1) Pesquisar, levantar material e estudar para compreender as tecnologias utilizadas para programação de aplicativos voltados para dispositivos móveis Android. A seguir as atividades que compõem esta etapa: Atividade 4.3.1: Pesquisar, levantar material e estudar sobre as tecnologias de programação para dispositivos móveis Android. Atividade 4.3.2: Ler, fazer/criar exercícios/exemplos e compreender a tecnologia.

Etapa 4.4 - Implementação (como parte da Etapa 4 na Figura 1) Desenvolver/Codificar a aplicação, testar e implantar/distribuir/instalar/configurar. A seguir as atividades que compõem esta etapa: Atividade 4.4.1: Desenvolver/Codificar a aplicação. Atividade 4.4.2: Realizar testes durante/depois da codificação. Atividade 4.4.3: Distribuir e/ou implantar, instalar e configurar a aplicação.

1.5 Estrutura deste Trabalho

No capítulo 2 será apresentada uma análise teórica sobre a Engenharia de Software, Gerê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 metodologias de Ensino-Aprendizagem existentes, bem como de suas aplicações por meio de jogos, conhecidos como Jogos Educacionais, como recursos didáticos. No capítulo 4 será apresentada uma análise sobre os JE existentes na literatura para o ensino-aprendizagem da ES/SCRUM. 20

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

21

2 FUNDAMENTAÇÃO TEÓRICA PARA ES/GP/SCRUM

Neste capítulo será apresentada uma análise teórica sobre parte da literatura existente para a Engenharia de Software, Gerência de Projetos e em especialmente em relação a metodologia ágil SCRUM aplicada à GP.

2.1 Engenharia de Software

Segundo (PRESSMAN, 2011), Engenharia de Software é uma “espécie” de tecnologia baseada em camadas (Figura 2), cuja fundamentação/base deverá ser/ter o foco na qualidade quando na definição de processos, métodos/práticas e ferramentas para o apoio da mesma. Com a aplicação desses recursos, definidos por essas “camadas”, será possível o desenvolvimento de melhores projetos de software, com a possibilidade de um melhor controle/gerenciamento, tendo como consequência um produto de software de qualidade, confiável, mais eficiente, entregue 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 engenharia de software e a responsável por unir as outras camadas. Por meio desta camada está fundamentada a gerência de projetos de software e a definição de um contexto para aplicação dos métodos/práticas da engenharia de software. A camada de métodos fornece informações técnicas e envolvem tarefas como: comunicação, requisitos, modelagem, implementação, testes e suporte. Já a camada de ferramentas dará o suporte necessário para as outras duas camadas de forma a automatizar suas respectivas atividades e práticas.

2.1.1 Processo de Software

Definição de Processos de Software para a Engenharia de Software segundo (PRESSMAN, 2011). Processo é a aplicação de um conjunto de atividades, ações e tarefas que objetivam produzir um produto como resultado. Uma atividade poderá ser empregada independe do campo de aplicação, do projeto e de esforços necessários para se chegar ao resultado. Uma ação se 22

constitui a partir da execução de um conjunto de tarefas que resultará, em um contexto de processo de software, em um artefato de software. Para uma tarefa caberá a responsabilidade de um objetivo menor mas bem definido que produzirá um resultado concreto. Para a engenharia de software um processo não é, e não deverá ser, um conjunto de atividades, ações e tarefas preestabelecidos que deverão serem executadas de forma invariavelmente para desenvolver um produto de software. Mas sim uma metodologia adaptativa, dependente do projeto de software etc, por meio da qual será possível a seleção/escolha de um conjunto mais apropriado de ações e tarefas a serem empregados na realização do trabalho. Utilizando-se de uma estrutura de processos será possível a identificação/definição de atividades base, como: comunicação; planejamento; modelagem; construção; e emprego. Essas atividades base podem/devem ser empregadas em qualquer processo/projeto de desenvolvimento de software, dos mais simples e menores ao mais complexos e maiores. Essa mesma estrutura de processos possibilitará/permitirá ainda a “adição” de um grupo de atividades de “suporte” que complementem as atividades base. Para estas atividades adicionais, são as características do projeto de software e/ou do processo adotado que definem/determinam a aplicação ou não das mesmas. O que poderá ocorrer durante a execução do processo/projeto de software. As atividades de suporte mais comuns são: controle e acompanhamento do projeto; administração de riscos; garantia da qualidade de software; revisões técnicas; medição; gerenciamento da configuração de software; gerenciamento de reusabilidade; preparo e produção de artefatos de software; etc.

2.1.2 Métodos/Práticas da Engenharia de Software

Definição de Métodos/Práticas de Engenharia de Software segundo (PRESSMAN, 2011). As atividades base e de suporte estabelecem um plano para a efetiva prática da engenharia de software. Mas a execução deste plano por si só não garante o “exercício” da Engenharia de Software. É preciso que, aliado a execução deste plano, se aplique alguns princípios tais como: 1. Compreender o problema (envolve as atividades de comunicação e análise) Algumas questões que deverão serem respondidas: • Quem são os interessados na solução do problema? • Quais dados, funções e recursos são necessários para resolver o problema? • É possível dividir o problema para facilitar a compreensão? • O problema pode ser representado através de gráficos? 2. Planejar uma solução (envolve as atividades de modelagem e projeto de software) Questões que deverão serem respondidas: • Já se deparou com problemas similares? 23

• Existem elementos que podem ser reutilizados? • Existem soluções aparentes e imediatas? • É possível criar um modelo de projeto? 3. Executar o plano (geração de código) 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ísticas necessárias?

2.1.3 Ferramentas de Software

Definição de Ferramentas de Software empregadas pela/na Engenharia de Software segundo (PRESSMAN, 2001). A camada de ferramentas possibilitará automatizar as atividades e práticas das camadas de processos e métodos respectivamente. Permitindo, entre outras coisas, a produção/geração de “produtos de trabalho” (modelos, documentos, dados, relatórios, formulários, etc.) que serão/poderão serem empregados/utilizados para geração de outro(s) produto(s) em uma outra etapa/subetapa com o suporte de outra(s) ferramenta(s) de software. A seguir algumas categorias destas ferramentas: Ferramentas para gerenciamento de processos; Ferramentas para modelagem de processos; Ferramentas para desenvolvimento de processos ágil; Ferramentas para planejamento 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 qualidade; Ferramentas para gerenciamento de testes; Ferramentas para gerenciamento de projetos; etc.

2.2 Gerência de Projetos

2.2.1 Projeto De acordo com (PMI INC., 2013), Projeto é: 24

Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. A natureza temporária dos projetos indica que eles têm um início e um término definidos. O término é alcançado quando os objetivos do projeto são atingidos ou quando o projeto é encerrado porque os seus objetivos não serão ou não podem ser alcançados, ou quando a necessidade do projeto deixar de existir. Um projeto também poderá ser encerrado se o cliente (cliente, patrocinador ou financiador) desejar encerrá-lo.

O resultado de um projeto é único e na maioria das vezes duradouro. O termo temporário não se aplica ao resultado mas sim ao projeto por meio do qual se alcança este resultado. Cada projeto, mesmo compartilhando certas características com outros projetos, possui suas próprias características e portanto apresentam uma natureza exclusiva. Os projetos podem ser empregados em todos os níveis organizacionais, envolver equipes compostas por um único ou vários membros, envolver uma única/várias unidades organizacionais ou ainda várias organizações. A execução de um projeto pode ter como resultado um produto, serviço, melhorias ou a geração de documento. Exemplos de projetos podem envolver o desenvolvimento de produto/serviço; efetuar alterações na estrutura, processos, pessoal ou modo de uma organização; Desenvolver, adquirir ou modificar um sistema de hardware e/ou software; Realização e registro de uma pesquisa; Construção de um prédio, de uma planta ou uma infraestrutura; ou ainda a implementação, melhorias de processos e procedimentos de negócios.

2.2.2 Gerência de Projeto De acordo com (PMI INC., 2013), Gerência de Projeto é: a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e integração apropriadas dos 47 processos de gerenciamento de projetos, logicamente agrupados em cinco grupos de processos. 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; determinar quais as necessidades das partes interessadas; estabelecimento de comunicação entre as partes; atender os requisitos do projeto bem como de suas entregas; e equacionar as restrições de escopo, qualidade, cronograma, orçamento, recursos e riscos inerentes a todo projeto. As restrições de projeto estão diretamente relacionadas entre si de forma tal que a alteração em uma delas certamente implicará em mudanças em pelo menos uma outra. Os responsáveis pelo desenvolvimento/execução do projeto deverão ser capazes de avaliar tais situações e agir de forma tal que se cumpra a entrega do resultado do projeto de acordo com os requisitos preestabelecidos.

25

2.2.3 Ciclo de Vida do Projeto

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

Fonte: (PMI INC., 2013)

2.2.4 Processos para Gerenciamento de Projetos Para (PMI INC., 2013); Esses processos garantem o fluxo eficaz do projeto ao longo da sua existência. Abrangem as ferramentas e técnicas envolvidas na aplicação de habilidades e

26

capacidades descritas nas áreas de conhecimento.

Os processos de gerenciamento de projetos apresentam-se como elementos distintos, mas na prática eles se sobrepõem e interagem entre si. Existe mais de uma forma para se controlar um projeto, no entanto a utilização de processos representa um guia na aplicação de conhecimentos e habilidades necessários ao gerenciamento do projeto. Esse emprego de processos se dará de forma iterativa e quando necessário o processo poderá ser repetido ao longo do projeto. A natureza do gerenciamento de projetos exige uma inter-relação e/ou sobreposição dos processos empregados para essa finalidade. Como demonstrado pela figura 4, os processos de monitoramento de controle fornecem uma “base” para outros quatro grupos de processos. Figura 4 – Processos para Gerenciamento de Projetos

Fonte: (PMI INC., 2013)

2.3 SCRUM De acordo com (SCHWABER; SUTHERLAND, 2013a), SCRUM é: Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtivamente e criativamente entregam produtos com o mais alto valor possível. um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990. Scrum não é um processo ou uma técnica para construir produtos; em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las.

O Scrum adota uma abordagem iterativa e incremental objetivando a melhoria da previsibilidade 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 (SCHWABER; SUTHERLAND, 2013a). As teorias empíricas para controle de processo são as teorias utilizadas na fundamentação do Scrum. O empirismo declara que o conhecimento se constrói a partir de experiências e que as decisões deverão ser tomadas baseado neste conhecimento. O controle de processo empíricos é apoiado por três pilares que são: 1. Transparência: Os aspectos mais importantes do processo devem estar acessíveis aos responsáveis pelos resultados. 2. Inspeção: Muitos dos aspectos de processo devem ser inspecionados com frequência suficiente para que as variações inaceitáveis no processo possam ser detectadas Leitão (2010). 3. Adaptação: Quando práticas do processo saem do escopo do projeto, impossibilitando a aceitação do resultado, os aspectos e/ou processos devem ser adaptados/ajustados o quanto antes possível para minimizar os desvios.

2.3.2 Principais Componentes do Scrum

O Scrum consiste em time(s) do Scrum que são associados a papéis, eventos/reuniões, artefatos e regras (SCHWABER; SUTHERLAND, 2013a). Cada componente serve a um propósito específico e é indispensável para o sucesso do Scrum (SCHWABER; SUTHERLAND, 2013a). As regras integram os eventos, papéis e artefatos, controlando as relações e interações entre os mesmos (SCHWABER; SUTHERLAND, 2013a).

2.3.2.1 Time/Papéis do Scrum Definição dos principais Time(s)/Papéis do Scrum segundo (SCHWABER; SUTHERLAND, 2013a). Time(s) Scrum são exemplo(s) de grupo(s) auto-organizáveis e multifuncionais. Um grupo auto-organizável é o responsável por definir a melhor forma para concluir seu trabalho e portanto não precisa ser gerenciado por alguém fora do grupo. Um grupo multifuncional são providos de todas as habilidades necessárias para completar seu trabalho e portanto não dependem de pessoas de fora do grupo. O modelo de time no Scrum foi pensado para melhorar a flexibilidade, criatividade e produtividade. O Time Scrum está associado aos Papéis do Scrum que são:

28

• Produto Owner/Dono do Produto: é o responsável, entre outras coisas, por maximizar o valor do resultado do projeto e do trabalho empregado pela Equipe de Desenvolvimento Scrum. • Equipe de Desenvolvimento do Scrum: responsáveis, entre outras coisas, pelo trabalho que resultará em uma versão/incremento utilizável do “produto” no final de cada ciclo Sprint. • Scrum Master: é o responsável, entre outras coisas, por garantir que o entendimento e aplicabilidade do Scrum.

2.3.2.2 Eventos do Scrum Definição dos principais Eventos do Scrum segundo (SCHWABER; SUTHERLAND, 2013a). Os eventos previamente definido pelo Scrum criam uma rotina e evitam a necessidade de encontros não planejados pelo TS. Qualquer evento definido pelo Scrum possui uma duração mínima e máxima de tempo (eventos Time-Boxed), de forma tal que depois de iniciados estes eventos não podem ter seus intervalos alterados. Algumas das principais características destes eventos é tornar as práticas/processos do Scrum o mais transparentes possível para o TS, Stakeholders e demais interessados, e possibilitar ao TS realizar inspeções e fazer adaptações quando necessário. Os principais eventos do Scrum são: • Sprint: é o evento/ciclo “cerne” do Scrum e um contêiner para outros eventos. É um time-boxed com duração de um mês ou menos onde uma versão utilizável do produto será desenvolvida. Assim que um Sprint termina um novo é inciado e o ciclo se repte até a conclusão do projeto. Além do trabalho de desenvolvimento se dá durante o Sprint ele também é composto pelas reuniões de Planejamento do Sprint, Reuniões Diárias, Revisão do Sprint e Retrospectiva do Sprint. • Reunião de Planejamento do Sprint: reunião onde o TS define o trabalho que será realizado durante o Sprint. Este evento representa um time-boxed de no máximo oito horas para um Sprint de um mês e no caso de Sprint’s menores este tempo máximo também diminui. • Reunião Diária: Este evento possui um time-boxed de 15 minutos durante o qual a EDS sincroniza/inspeciona as atividades do dia, discute sobre eventuais impedimentos e programa as tarefas para o dia seguinte. • Revisão do Sprint: Este evento possui um time-boxed de 4 horas para um Sprint de um mês ou um intervalo menor caso a duração do Sprint seja inferior a um mês. Nesta reuniã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 participantes (TS e os Stakeholders) motivação e colaboração, e caso necessário adaptações no BPP serão realizadas. • Retrospectiva do Sprint: ocorre depois da RRS e antes da RPS para o próximo Sprint. Esta é uma oportunidade para o TS inspecionar a se próprio e de planejar melhorias para serem executadas no próximo Sprint. Possui um time-boxed de três horas para um Sprint de um mês e intervalos menores caso o Sprint dure menos que um mês.

2.3.2.3 Artefatos do Scrum Definição dos principais Artefatos do Scrum segundo (SCHWABER; SUTHERLAND, 2013a). Representam o trabalho e/ou o “valor do negócio” além de permitir mais transparência e possibilidades para inspeções e adaptações. Os principais artefatos do Scrum são: • Backlog do Produto/Backlog Priorizado do Produto: uma lista ordenada, de acordo com valor de negócio, de tudo aquilo que for necessário (funções, requisitos, melhorias etc) para o desenvolvimento do produto. Esta lista é muito dinâmica, mudando constantemente para representar o que o produto necessita. O BPP evolui junto com o produto e com o “ambiente” Scrum e existirá enquanto o produto existir. A figura 5 representa um exemplo de BPP. Figura 5 – Exemplo de Backlog Priorizado do Produto

Fonte: (LARMAN, 2004), citado por (SCHNEIDER, 2015)

• Backlog do Sprint: é um subconjunto de requisitos do BPP escolhidos para fazerem parte do Sprint em conjunto com o planejamento de entrega do incremento do produto. O BS é uma seleção e estimativa realizada pelo TS para determinar as funcionalidades que devem estar presentes na próxima versão do produto e também o trabalho que será necessário para que seja atingido este objetivo. A figura 6 representa um exemplo de BS.

30

Figura 6 – Exemplo de Backlog do Sprint

Fonte: (LARMAN, 2004), citado por (SCHNEIDER, 2015)

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

Fonte: (RUBIN, 2013)

31

• Taskboard/Scrumboard: de acordo com Camargo (2013), pode ser um “painel/quadro”, software ou outro tipo de “ferramenta”. É utilizado para auxiliar na “visualização” do progresso/evolução do Sprint, possibilitando o acompanhamento das atividades planejadas para este Sprint. Deverá está acessível ao TS e como acontece para BC também deve ser atualizado constantemente durante o Sprint (provavelmente na Reunião Diária). A figura 8 representa um exemplo de Taskboard. Figura 8 – Exemplo de Taskboard

Fonte: (KNIBERG, 2007) citado por (CAMARGO, 2013)

2.3.3

Visão Geral do Scrum

Visão geral da metodologia Scrum segundo (SATPATHY et al., 2016). Para a conclusão de um projeto Scrum é necessário que se faça um esforço considerável de colaboração, entre os envolvidos, para se alcançar um novo resultado (produto, serviço etc) que esteja de acordo com o que foi definido na Declaração de Visão de Projeto. Restrições de tempo, custo, escopo, qualidade, recursos, capacidade de organização, entre outras, podem afetar um projeto dificultando seu planejamento, implementação, gerenciamento e como consequência determinar o fracasso do mesmo. De outra forma quando se obtêm êxito no desenvolvimento de um produto, a partir da conclusão de um projeto, os benefícios comercias podem ser significativos para uma organização. Por isso a importância da escolha e prática de uma metodologia para gerência de projeto por parte das organizações. O Scrum se tornou uma das metodologias ágeis mais populares atualmente. Isto porque apresenta, entre outras características, alto grau de adaptação, iteratividade, rapidez, flexibilidade e eficiência. Foi “desenhada” de forma a permitir uma valorização do negócio deste o início do desenvolvimento do projeto. O Scrum possibilita para as partes envolvidas a transparência na comunicação desenvolvendo um ambiente de responsabilidade coletiva e de evolução 32

contínua no progresso do projeto. Entre os fatores de maior relevância pode-se destacar o fato que o(s) “time(s)” do Scrum são multifuncionais, auto-organizados e emponderados, e cujo trabalho é dividido em ciclos curtos de tempo bem definidos conhecidos como Sprints. A figura 9 exibe uma visão geral do fluxo de execução Scrum para um determinado projeto. Figura 9 – Fluxo de Execução do Scrum para um Projeto

Fonte: (SATPATHY et al., 2016) adaptado pelo autor

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

33

2.3.4

O Framework SCRUM

2.3.4.1 Principais Fundamentos/Bases do Framework Scrum Os principais fundamentos/bases do Framework Scrum segundo (SATPATHY et al., 2016). 1. Princípios: formam o “alicerce” sobre o qual o Scrum se baseia. 2. Aspectos: devem ser empregados na execução de qualquer projeto Scrum, independente de tamanho, complexidade etc. 3. Processos: incluem os dezenove processos do Scrum com suas respectivas entradas, ferramentas e saídas. Os princípios do Scrum não são alteráveis, devem ser seguidos a risca, enquanto que os aspectos e processos do Scrum podem ser modificados para atender/adequar aos requisitos de projeto e/ou organizacionais. Os princípios, aspectos e processos do Scrum constituem a base para esta metodologia e a compreensão de suas relações são de fundamental importância para entendimento deste framework. A figura 10 representa os “conjuntos de métodos/práticas/regras” 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

Fonte: (SATPATHY et al., 2016)

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

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

2.3.4.1.3 Processos do SCRUM Os Processos do Framework Scrum segundo (SATPATHY et al., 2016). Os Processos do Scrum incluem as atividades/práticas aplicadas durante um projeto Scrum e a ordem em que as mesmas são empregadas. Ao todo são dezenove processos divididos em cinco fases conforme apresentado na figura 12. Figura 12 – Processos do Scrum

Fonte: (SATPATHY et al., 2016)

As fases descrevem detalhadamente cada processo, destacando entradas, ferramentas/recursos e saídas para cada processo, além de especificar quais destes “critérios” são obrigatórios e quais são opcionais. A seguir são descritos os processos de cada fase e a especificação de entradas, ferramentas e saídas obrigatórios para cada um, será realizada ao final destas fases. • Iniciar 1. Criar a Visão do Projeto: O Caso de Negócio do Projeto é analisado na Reunião da Visão do Projeto e a Declaração de Visão do Projeto é criada para servir como orientação durante todo o projeto. Neste processo também se dará a identificação do Produto Owner. 2. Identificar o Scrum Master e o(s) Stakeholder(s): de acordo com determinados critérios o Scrum Master e o(s) Stakeholder(s) são identificados. 37

3. Formar o Time/Equipe Scrum: os colaboradores da Equipe de Desenvolvimento são definidos. 4. Desenvolver os Épicos: a DVP é utilizada como base para a criação dos Épicos e caso necessário serão realizadas reuniões com grupo de usuários. 5. Criar o Backlog Priorizado do Produto: os Épicos são refinados, processados e priorizados para originar o BPP. Critérios de “Pronto” também são definidos. 6. Conduzir/Definir o Planejamento das Release’s: o TS analisa as Estórias de Usuário “anexas”/presentes no BPP para criar o Cronograma de Planejamento das Release’s. A duração do(s) cliclo(s) Sprint também é definida. A tabela 1 a seguir define as entradas, ferramentas e saídas obrigatórios para cada processo na fase Iniciar. Tabela 1 – Processos da Fase Iniciar

Fonte: (SATPATHY et al., 2016)

• Planejar e Estimar 1. Criar as Estórias de Usuários: o PO cria as Estórias de Usuário juntamente com os Critérios de Aceitação para EU. As EU devem ser projetadas de forma a permitir a transparência e compreensão dos requisitos de cliente, para os Stakeholders. As EU são incorporadas/”anexadas” ao BPP. 2. Aprovar, Estimar e Comprometer as EU: o PO seleciona as EU para o Sprint e o SM juntamente com a EDS estimam os esforços para completá-las. Para finalizar a EDS se compromete a entregar os requisitos sob EU. 3. Criar as Tarefas:as EU aprovadas, estimadas e comprometidas são divididas em tarefas e agrupas na Lista de Tarefas. Em geral uma Reunião de Planejamento de Tarefas acontece para este fim. 38

4. Estimar as Tarefas:a EDS na RPT estima os esforços para completar as tarefas da LT. 5. Criar o Backlog do Sprint:o TS durante a Reunião de Planejamento do Sprint cria o Backlog do Sprint com as tarefas a serem desenvolvidas no Sprint. A tabela 2 a seguir define as entradas, ferramentas e saídas obrigatórios para cada processo na fase Planejar e Estimar. Tabela 2 – Processos da Fase Planejar e Estimar

Fonte: (SATPATHY et al., 2016)

• Implementar 1. Criar os Entregáveis/Incrementos: a EDS desenvolve as tarefas do BS para criar os Entregáveis. O acompanhamento do progresso dos trabalhos e atividades é realizado através do Scrumboard/Taskboard. 2. Conduzir a Reunião Diária: momento utilizado pela EDS para informarem-se entre se sobre suas atividades, progressos e quaisquer impedimentos, além de definir o que será realizado no dia seguinte. 3. Refinamento do Backlog Priorizado do Produto: o BPP é constantemente atualizado e mantido. Uma Reunião de Revisão do BPP pode ser realizada para que eventuais mudanças e atualizações no BPP possam ser debatidas e se for o caso incorporadas ao BPP. A tabela 3 a seguir define as entradas, ferramentas e saídas obrigatórios para cada processo na fase Implementar.

39

Tabela 3 – Processos da Fase Implementar

Fonte: (SATPATHY et al., 2016)

• Revisão e Retrospectiva 1. Convocar o Scrum de Scrums: os TS são convocados para a Reunião do Scrum de Scrum’s, em intervalos preestabelecidos. Relevante apenas para grandes projetos. 2. Demonstrar e Validar o Sprint:na Reunião de Revisão do Sprint a EDS apresenta, para PO e para os Stakeholders, os entregáveis/incrementos desenvolvidos durante o Sprint. O PO então avalia os entregáveis e caso sejam aprovados e/ou aceitos então uma versão utilizável do produto poderá ser disponibilizada aos Stakholders. 3. Retrospectiva do Sprint: o SM junto com a EDS se reúnem na Reunião de Retrospectiva do Sprint para discutir sobre lições aprendidas no Sprint. Estas informações são documentadas e poderão serem utilizadas nos próximos Sprint’s. A tabela 4 a seguir define as entradas, ferramentas e saídas obrigatórios para cada processo na fase Revisão e Retrospectiva. Tabela 4 – Processos da Fase Revisão e Retrospectiva

Fonte: (SATPATHY et al., 2016)

• Release 1. Envio de Entregáveis: os Entregáveis/Incrementos aprovados/aceitos pelo PO são disponibilizados aos Stakholders e um acordo formal documenta o sucesso do Sprint. 40

2. Retrospectiva do Projeto: os Stakholders e o TS se reúnem para fazer uma retrospectiva 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 processo na fase Release. Tabela 5 – Processos da Fase Release

Fonte: (SATPATHY et al., 2016)

41

3 FUNDAMENTAÇÃO TEÓRICA PARA EA/JE

Neste capítulo será apresentada uma análise teórica sobre parte da literatura existente para a metodologia de Ensino-Aprendizagem bem como de suas aplicações por meio de jogos, conhecidos como Jogos Educacionais, como recursos didáticos.

3.1 Ensino-Aprendizagem De forma resumida a aprendizagem pode ser definida como: - são conhecimentos adquiridos pelos humanos que refletem em mudanças persistentes no desempenho e no potencial dos mesmos e deve surgir como um resultado da experiência e interação dos aprendizes com o mundo, segundo (DRISCOLL, 2004) - traduzido. - é o ato de adquirir, modificar e/ou reforçar novos conhecimentos, comportamentos, habilidades, valores ou preferências e pode envolver a sintetização de diferentes tipos de informação, segundo (WIKIPEDIA, 2016c) – traduzido. - tem como finalidade ajudar a desenvolver nos indivíduos as capacidades que os tornem capazes de estabelecer uma relação pessoal com o meio em que vivem (físico e humano), servindo-se para este efeito, das suas estruturas 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 humanos para instruir e educar seus semelhantes, segundo (WIKIPEDIA, 2016d). - Ensinar define-se por obter aprendizagem do aluno e não pela intenção (ou objetivo) do professor ou por uma descrição do que ele faz em sala de aula. A relação entre o que o professor faz e a efetiva aprendizagem do aluno é o que, mais apropriadamente, pode ser chamado de ensinar, segundo (KUBO; BOTOMé, 2001).

De acordo com Lino (2007), o processo ensino-aprendizagem na educação pode ser definido pela composição de duas vertentes diferentes mas que se complementam: de um lado o educador - aquele que detém o conhecimento e o responsável por transmiti-lo; do outro o aprendiz que está ávido por novos conhecimentos. Ainda segundo Lino (2007), este é um processo que está em constante transformações assim como a natureza dos componentes base neste processo. Segundo (CROSS, 1987), para se alcançar um aprendizado de excelência é necessário que os instrutores estejam cientes do que eles podem fazer para que o ensino seja transmitido de tal forma que o conhecimento a ser captado/assimilado possibilite maximar o aprendizado. O que os instrutores podem fazer para tornar possível/viável este nível de aprendizado, ainda segundo (CROSS, 1987), é: 42

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

43

3.1.1 Design Instrucional De acordo com (FILATRO, 2004) citado por (BRAGA, 2015), o Design Instrucional é: a ação institucional e sistemática de ensino, que envolve o planejamento, o desenvolvimento e a utilização de métodos, técnicas, atividades, materiais, eventos e produtos educacionais em situações didáticas específicas, a fim de facilitar a aprendizagem humana a partir dos princípios de aprendizagem e instrução conhecidos.

De acordo com (E-LEARNING, 2016b), o Design Instrucional é definido como sendo um processo sistemático de “tradução” dos princípios/fundamentos do ensino-aprendizagem no planejamento de “materiais” para aplicação no processo de ensino-aprendizagem. As “raízes” do DI tiveram origem na ciência da psicologia cognitiva e comportamental, que dizem respeito a pesquisas educacionais/ensino e as teorias de ensino-aprendizagem para o desenvolvimento/implementação de estratégias/processos de ensino (E-LEARNING, 2016b). Este é um processo em que se emprega, de forma sistemática, as teorias de ensino-aprendizagem com objetivo de obter um ensino de qualidade; o que requer a realização de análises das necessidades e objetivos de aprendizagem, com consequente desenvolvimento e distribuição de “sistemas” adequados a tais necessidades (E-LEARNING, 2016b). Segundo (GONçALVES, 1993) citado por Schneider (2015), Unidades Instrucionais podem “ser um curso, um exercício, uma aula, um jogo, um evento onde a aprendizagem é influenciada pelas interações entre o aluno, o professor e os materiais da aula”. As UI podem ser, sistematicamente, planejadas, desenvolvidas e avaliadas segundo a descrição/estrutura dos processos de DI’s, segundo PIAZZA (2012) citado por Schneider (2015). De acordo com (MOLENDA, 2003) citado por Camargo (2013), o ISD (Instrucional System Development) define um conjunto de modelos baseados no processo de DI e são utilizados para o desenvolvimento de “plataformas educacionais”. Através de modelos ISD’s o desenvolvimento 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, Design, 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 genéricos utilizados para o desenvolvimento de projetos instrucionais/ensino, representando guias descritivos para elaboração de “ferramentas” de apoio e de treinamentos. Segundo (BRAGA, 2015), ADDIE, acrônimo em inglês para Analyze (Analisar), Design (Projetar), Develop (Desenvolver), Implement (Implementar) and Evaluate (Avaliar), “é um paradigma de desenvolvimento de produtos em geral, mas tem sido muito aplicado para um tipo específico de produto 44

que são os materiais instrucionais”. De acordo com Savi (2011), o ADDIE é uma metodologia utilizada para definir um público-alvo, “levantar” os “requisitos” para este público, projetar e desenvolver uma solução e avaliar os resultados coletados a partir da aplicação da solução. A figura 13, a seguir, exibe as fases do modelo e suas possíveis relações. Figura 13 – Fases do modelo ADDIE

Fonte: (E-LEARNING, 2016a), citado por (CAMARGO, 2013)

A seguir cada uma das fases do padrão ADDIE serão descritas segundo (CLARK, 1995; FILATRO, 2008; INTULOGY, 2016) citados por Savi (2011). Análise Na fase de análise são identificadas as deficiências educacionais a serem sanadas no público-alvo, são levantados os requisitos de aprendizagem e consequentemente metas e objetivos de ensino-aprendizagem são definidos. Procura-se caracterizar o público-alvo através de identificação de conhecimentos, habilidades e deficiências. Estes levantamentos/pesquisas são realizados por meio de entrevistas e/ou questionários através de e-mail’s, telefone ou presenciais. Como resultado desta fase é gerado um “documento” com informações dos resultados dos levantamentos/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 produzido. Será definida sua estrutura, a sequência em que o conteúdo será apresentado, etc; são identificadas as estratégias e atividades de ensino para se alcançar os objetivos e metas de aprendizagem. Esta fase é composta, basicamente, por três subetapas que são: • Planejamento do Projeto Instrucional: define-se como o “material” e/ou conteúdo a ser criado e utilizado deverá ser estruturado e sequenciado para a 45

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

46

3.1.3 Taxonomia de Bloom

A taxonomia de Bloom foi estruturada de forma a possibilitar sua utilização para o planejamento, projeto e avaliação do aprendizado e de treinamentos (BLOOM, 1984; CHAPMAN, 2009) citados por Savi (2011). Aborda os domínios cognitivo, psicomotor e afetivo Camargo (2013), mas é mais difundida/conhecida e aplicada pelos “trabalhos” relacionados ao domínio cognitivo Savi (2011). No domínio cognitivo a efetivação da aprendizagem (conhecimentos/habilidades etc) é medida através de níveis de complexidade, que determina que o avanço para o próximo nível - para se obter o conhecimento relativo ao próximo nível – só será possível se os requisitos (conhecimentos, habilidades etc) relativos ao nível anterior já foram alcançados Camargo (2013). A figura 14, a seguir, ilustra a taxonomia de Bloom para o domínio cognitivo. Figura 14 – Categorias do domínio cognitivo segundo a taxonomia de Bloom (1956)

Fonte: (CAMARGO, 2013)

3.2 Jogos Educacionais/Jogos “Sérios” Algumas definições para jogo: - qualquer competição (jogo) entre os adversários (jogadores) que operam sob restrições (regras) para um objetivo (vitória ou lucro), segundo (ABT, 1987) citado por (BATTISTELLA; WANGENHEIM; FERNANDES, 2014). - uma competição, física ou "mental", jogada de acordo com regras específicas, com um objetivo de diversão ou recompensa aos participantes, segundo (WIKIPEDIA, 2016e) – traduzido.

Algumas definições para jogos educacionais ou jogos “sérios”: - jogos que não possuem como principal propósito o entretenimento, o prazer ou a diversão”, segundo (MICHAEL; CHEN, 2005) citado por (DJAOUTI et al., 2011). - uma competição "mental", jogada com o computador, que usa o entretenimento e acontece de acordo com regras específicas que controlam o progresso (do jogador), podendo simular, por exemplo, um treinamento empresarial, uma atividade educacional, um treinamento na área da saúde, um treinamento policial 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 pensados para ensinar, e não ser jogado simplesmente para diversão, segundo (ABT, 1987) citado por (WANGENHEIM, 2012).

De acordo com (MA; OIKONOMOU; JAIN, 2011), a recente “onda” a respeito de jogos “sérios” teve como parte de sua origem, os vídeo games, que introduziram o conceito de jogos projetados para outros propósitos além do entretenimento; e dentre as possíveis áreas de aplicação para estes destaca-se a educacional, engenharia, saúde, militar, planejamento de cidades, produção e “resposta à crises”. Para os jogadores esse tipo de jogo representará uma nova forma de aprender/aperfeiçoar conhecimentos e habilidades, promover atividades físicas, suporte ao desenvolvimento social/emocional, e o tratamento de diferentes tipos de doenças psicológicas e físicas entre outras (MA; OIKONOMOU; JAIN, 2011). Recentes estudos, considerando diferentes contextos, tem demonstrado os benefícios de se utilizar os jogos com fins além do entretenimento. Vantagens como baratos/acessíveis, amplamente disponíveis e divertidos, combinadas com abordagens educacionais e treinamentos podem fornecer um poderoso recurso para transferê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 pessoas acerca de um determinado assunto, expandir conceitos, reforçar o desenvolvimento, ou auxiliá-las exercitando uma habilidade ou buscando uma mudança de atitude enquanto jogam”. Os jogos utilizados com fins educacionais definem como seu principal resultado a aprendizagem; procurando balancear aspectos relacionados ao assunto/tema de aprendizagem, com os aspectos relacionados a jogabilidade e com a capacidade do jogador/aprendiz em assimilar os conceitos sobre este assunto e utilizá-los em situações reais (BATTISTELLA; WANGENHEIM; FERNANDES, 2014). Quando o aprendizado é obtido através de jogos ele é adquirido de uma forma mais ativa, possibilitando ao aprendiz se tornar um agente mais participativo neste processo e com isso aumentando/melhorando sua capacidade de compreensão a respeito do conteúdo ensinado, segundo (BONWELL; EISON, 1991) citado por (BATTISTELLA; WANGENHEIM; FERNANDES, 2014). O desenvolvimento de um jogo é uma atividade desafiadora e necessita de métodos criativos que sejam empregados de forma sistemática. As atividades desenvolvidas por construtores de jogos envolvem, entre outras, a definição de regras que estimulem/motivem o jogador e que permitam a progressão do mesmo durante o jogo; e a partir de tais características (regras, motivação e progressão) os construtores ainda precisarão combinar “desafio, competição e interação para tornar o jogo divertido” de se jogar, segundo (BATTISTELLA; WANGENHEIM; FERNANDES, 2014). Uma maneira de fazer/garantir com que um jogo a ser desenvolvido seja considerado educativo e portanto passível de utilização como recurso de ensino, é que este seja desenvolvido a partir de um Design Instrucional (BATTISTELLA; WANGENHEIM; FERNANDES, 2014). As tarefas relativas a um processo de DI (ajustadas à realidade de um jogo) são responsáveis por definir o conteúdo educacional do jogo, enquanto que o “design de jogo” para o jogo, pode ser definido 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 possibilitarem que alunos apliquem na prática o que aprenderam”; • os jogos possibilitam a diversão, competição, cooperação e disciplina ao mesmo tempo que se aprende; • envolve o “trabalho” em equipe e podem aprimorar esta capacidade; • pode ser uma ferramenta muito útil como meio de avaliação. No próximo capítulo serão abordados os jogos educacionais voltados para o ensinoaprendizagem na área de ES/Scrum.

49

4 ANÁLISE SOBRE JE PARA O EA DE ES/SCRUM

Neste capítulo são apresentados alguns exemplos de jogos educacionais, existentes na literatura, para auxiliar no processo de ensino-aprendizagem de ES/SCRUM. Em especial serão abordados JE direcionados para ensino/prática da metodologia Scrum.

4.1 JE para o Ensino-Aprendizagem de ES

Nesta seção são abordados os JE voltados para o ensino-aprendisagem de Engenharia de Software. Foram analisados e “levantadas” informações como: uma descrição resumida do jogo; objetivos e níveis de aprendizagem; público-alvo; resultados de avaliações etc. Tabela 6 – Informações sobre o jogo SimSE SimSE Jogo

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 SimSE Jogo

Objetivos de

Ensinar Processos de Engenharia de Software

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom 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 Resultados de Avaliações

Aproximadamente 2 horas Quatro testes foram realizados: teste piloto, teste em classe, teste comparativo e estudo observacional. Sendo que no teste em classe alguns dos resultados obtidos, com uma nota variando de 1 até 5, foram: - jogo divertido = 2,5 de média; - reforça a teoria vista em sala = 3,2 de média; - grau de 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 Tipo de Jogo Gênero/Categoria do Jogo

Java Digital Simulação

Plataforma

Windows e Linux

Referência

N/A

Fonte: (NAVARRO, 2006)

51

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

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

Ensinar Processos de Medição e Análise de Software

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo

Estudantes de Processos de Medição e Análise de Software

Modo de Interação

Único Jogador/Individual

Idioma Disponível

Português

Duração

Aproximadamente 2 horas

Resultados de Avaliações

N/A

Linguagem

N/A

Tipo de Jogo Gênero/Categoria do Jogo

Digital Simulação

Fonte: (LINO, 2007)

52

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

Plataforma

N/A

Referência

N/A

Fonte: (LINO, 2007)

Tabela 8 – Informações sobre o jogo TestEG TestEG Jogo

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 TestEG Jogo

Objetivos de

Ensinar Processos de Testes de Software

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo

Estudantes de Processos de Testes de Software

Modo de Interação

Único Jogador/Individual

Idioma Disponível

Português

Duração Resultados de Avaliações

Aproximadamente 10 minutos 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 Tipo de Jogo Gênero/Categoria do Jogo

Engine de Jogos - Unity3D Digital Simulação

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 processo de ensino-aprendizagem sobre a metodologia ágil Scrum. Foram analisados e “levantadas” informações como: uma descrição resumida do jogo, objetivos e níveis de aprendizagem, público-alvo, resultados de avaliações etc.

54

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

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

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

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 2 - Compreensão (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo Pré-requisitos do

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

Público-alvo Modo de Interação

Único Jogador/Individual

Idioma Disponível

Português

Fonte: (CAMARGO, 2013)

55

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

Duração Resultados de Avaliações

Aproximadamente 120 minutos 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 para relevância e atenção durante o jogo; - com relação a experiência obtida com o jogo também foram constados resultados positivos em todas as dimensões avaliadas, com destaque para diversão e imersão; - com relação ao aprendizado adquirido com o jogo os avaliadores, de forma geral, também responderam positivamente, sendo que aproximadamente 70% deles disseram ter aprendido mais com jogo; - por 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 Tipo de Jogo Gênero/Categoria do Jogo

Engine de Jogos - RPG Maker Digital RPG - Role Playing Game

Plataforma

N/A

Referência

N/A

Fonte: (CAMARGO, 2013)

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

Captura de Tela

Fonte: (SCHNEIDER, 2015)

56

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

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

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

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo Pré-requisitos do

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

Público-alvo Modo de Interação

Único Jogador/Individual

Idioma Disponível

Português

Duração Resultados de Avaliações

Aproximadamente 100 minutos 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 questão que perguntava se o conteúdo educacional do jogo estava de acordo com conceitos já “vistos” pelos participantes, e 95 - com relação a experiência obtida com o jogo também foram constados resultados positivos e outros nem tanto, com destaque para a questões como desafiador (boa parte concorda) e cooperação, competição, diversão e interação (boa parte não concorda); - com relação ao aprendizado adquirido com o jogo, mais de 50 - por fim foi avaliado o nível de conhecimento que se atingiu com o aprendizado adquirido após o jogo e, no geral, os participantes responderam que o conhecimento deles melhorou a respeito do assunto abordado, indicando que o nível subiu pelo menos 1 ponto.

Linguagem Tipo de Jogo Gênero/Categoria do Jogo Plataforma

Engine de Jogos - Unity Digital RPG - Role Playing Game Windows

Fonte: (SCHNEIDER, 2015)

57

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

Referência

N/A

Fonte: (SCHNEIDER, 2015)

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

Captura de Telas do Módulo Administrador

Fonte: (GKRITSI, 2011)

58

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

Captura de Telas do Módulo Jogador/User

Fonte: (GKRITSI, 2011)

59

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

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

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

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo Pré-requisitos do

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

Público-alvo Modo de Interação

Único Jogador/Individual

Idioma Disponível

Inglês

Duração

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

Fonte: (GKRITSI, 2011)

60

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

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 em sala de aula; - 95% acham que aprenderiam melhor/mais, sobre Gerência de Projeto, se este jogo fosse utilizado como recurso de ensino-aprendizagem para esta disciplina/conteúdo; - 75% acharam o jogo divertido de se jogar; - esta versão do sistema recebeu uma nota 8 de média num total de 10, quando avaliado de forma geral (interface, navegabilidade etc).

Linguagem Tipo de Jogo Gênero/Categoria do Jogo

PHP Digital Simulação

Plataforma

Computador/Web/Windows

Referência

http://users.ecs.soton.ac.uk/ag2006/COMP6029/

Fonte: (GKRITSI, 2011)

61

Tabela 12 – Informações sobre o jogo Scrumming Scrumming Jogo

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

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

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo Pré-requisitos do

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

Público-alvo

Fonte: (NETO, 2008)

62

Tabela 12 - Informações sobre o jogo Scrumming Scrumming Jogo

Modo de Interação

Único Jogador/Individual

Idioma Disponível

Português

Duração

N/A

Resultados de Avaliações

N/A

Linguagem

Java

Tipo de Jogo Gênero/Categoria do Jogo

Digital Simulação

Plataforma

Computador/Windows

Referência

N/A

Fonte: (NETO, 2008)

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

Captura de Telas do Módulo Administrador/Cliente

Fonte: (SILLER; BRAGA, 2013)

63

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

Captura de Telas do Módulo Jogador/Aluno

Descrição Resumida

O jogo é composto por duas “áreas” sendo uma delas contendo as funcionalidades/atividades relacionadas ao Cliente no Scrum (papel não central), e a outra destinada ao jogador que poderá assumir um dos papeis centrais no Scrum (Produto Owner, Scrum Master, Equipe de Desenvolvimento). Na área do cliente o usuário poderá propor/formalizar um projeto a ser desenvolvido, através do cadastro das 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

Ensinar conceitos/práticas da Metodologia Ágil Scrum

Aprendizagem Feedback ao Jogador Nível de Aprendizagem

Durante e após o jogo Nível 3 - Aplicação (de acordo com a figura 14)

segundo a Taxonomia de Bloom Público-Alvo

Estudantes de Engenharia de Software

Fonte: (SILLER; BRAGA, 2013)

64

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

Pré-requisitos do

N/A

Público-alvo Modo de Interação

Multijogador

Idioma Disponível

Português

Duração

N/A

Resultados de Avaliações

N/A

Linguagem

Java EE

Tipo de Jogo

Digital

Gênero/Categoria do Jogo

Simulação

Plataforma

Computador/Web

Referência

N/A

Fonte: (SILLER; BRAGA, 2013)

65

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

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

5.1 Análise/Projeto Instrucional

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

5.1.1 Análise

Nesta etapa serão definidos o público-alvo, contexto instrucional e metas/objetivos de aprendizagem. Público-alvo do PLAY’ed-SCRUM’ces: de uma forma geral este público poderá ser formado por estudantes da metodologia ágil SCRUM. Dentre os quais podese citar o público formado por estudantes de graduação cujo currículo contemple o assunto/conteúdo SCRUM. Alguns exemplos destes cursos são aqueles que se inserem na área de computação como: Ciência da Computação, Sistemas de Informação, Engenharia de Software etc. Para os jogadores que já possuam algum conhecimento teórico/conceitual sobre o Scrum, principalmente a respeito de conceitos básicos como papéis, artefatos e reuniões, espera-se que eles já consigam jogar sem que seja necessário estudar o conteúdo teórico/educacional do jogo. Mas não é necessário que os jogadores já apresentem previamente tais conhecimentos, pois no próprio jogo será possível estudar o conteúdo educacional abordado durante uma partida do jogo. Contexto Organizacional/Instrucional: considerando-se o fato de que um dos possíveis públicos-alvo para este jogo como sendo alunos da área de computação em geral, permite considerar que as disciplinas destes cursos (cujo currículo contemple o Scrum) como sendo um dos possíveis contextos instrucionais para aplicação deste jogo. Aplicação esta que poderá ser realizada em salas de aula, 66

laboratórios ou mesmo em casa como tarefas de extra classe. Metas/Objetivos de aprendizagem: espera-se que o conteúdo deste jogo possibilite aos jogadores atingir um nível de aprendizagem que contemple aspectos como os de lembrança e compreensão, definidos de acordo com a taxonomia de Bloom. Após ter jogado uma “partida” do jogo espera-se que o jogadores tenham desenvolvido competências/conhecimentos que os possibilite de: • Lembrar o nome e definição conceitual de cada um dos papéis, artefatos e reuniões do Scrum; • Lembrar/Compreender os objetivos/responsabilidades de cada um dos papéis, artefatos e reuniões do Scrum; • Lembrar/Compreender as relações existentes entre cada um dos papéis, artefatos e reuniões do Scrum; • Lembrar/Compreender nomes, conceitos, objetivos e relações dos conjuntos de métodos/práticas/regras considerados como os fundamentos para o framework Scrum, e definidos como sendo os princípios, aspectos e processos deste frameowork.

5.1.2 Projeto

Nesta etapa serão definidos o conteúdo educacional, a sequência de apresentação para este conteúdo e as estratégias/atividades de ensino empregadas para se atingir as metas/objetivos que foram definidos na etapa de análise. Conteúdo de Ensino: o seguinte conteúdo a respeito da metodologia ágil Scrum será abordado no jogo: • Nome e definição conceitual de cada um dos papéis, artefatos e reuniões do Scrum; • Objetivos/Responsabilidades de cada um dos papéis, artefatos e reuniões do Scrum; • As relações existentes entre cada um dos papéis, artefatos e reuniões do Scrum; • O nomes, conceitos, objetivos e relações dos conjuntos de métodos/práticas/regras considerados como sendo os fundamentos do framework Scrum, e definidos como sendo os princípios, aspectos e processos deste frameowork. Mais informações sobre o conteúdo educacional do jogo podem ser encontradas nos Apêndice A e B deste trabalho.

67

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

• Poderão ser utilizados outros jogos educacionais semelhantes a este (com o mesmo fim – ex: SCRUM-Scape Camargo (2013) e SCRUM’ed Schneider (2015)) para ambientar os alunos com este tipo de recurso. • O jogo poderá ser aplicado em laboratórios utilizados para as aulas “práticas” do curso/disciplina (que contemple o Scrum) ou como atividade extra classe. Como o jogo se trata de um aplicativo digital que será desenvolvimento para ser instalado e executado em dispositivos móveis Android (Smartphone/Tablet), poderá ser “levado/carregado” e utilizado em qualquer lugar/local.

5.2 Desenvolvimento Instrucional

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

5.2.1 Diagramas do jogo PLAY’ed-SCRUM’ces

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

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

69

Figura 15 – Diagrama Entidade Relacionamento - DER

Fonte: Criado pelo autor

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

70

Figura 16 – Diagrama de Caso de Uso

Fonte: Criado pelo autor

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

71

Figura 17 – Diagrama de Classe

Fonte: Criado pelo autor

5.2.2 Regras do jogo PLAY’ed-SCRUM’ces

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

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

73

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

Foram realizadas pesquisas/buscas, com intuito de identificar material/recursos sobre a tecnologia utilizada para desenvolvimento de aplicativos para dispositivos móveis que executam/rodam sobre o SO/Plataforma Android. O material levantado foi estudado, exemplos de aplicativos foram criados/codificados e instalados/executados para efeitos de testes. Dessa forma pode-se compreender a tecnologia que seria empregada no desenvolvimento do jogo PLAY’ed-SCRUM’ces. Para o download de recursos/arquivos necessários, preparação/configuração de ambiente de programação, implementação/codificação dos exemplos e do jogo/aplicativo propriamente dito, e geração do arquivo *.apk/aplicativo para distribuição/instalação do jogo, foram realizados os seguintes passos: 1. Identificação e obtenção dos recursos/ferramentas necessários a permitir a codificação, testes, distribuição, instalação e execução do jogo/aplicação (apk); • Download do Java SE Software Development Kit (JDK) em: – http://www.oracle.com/technetwork/java/javase/downloads/index.html, ou em – http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloadsjavase7-521261.html#jdk-7u80-oth-JPR • Download da IDE Eclipse em: – http://download.eclipse.org/eclipse/downloads/, ou em – http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2201301310800/, ou em

– http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2-201301310800/download.php?d SDK-3.8.2-win32.zip • Download do Android Software Development Kit (SDK) em: – https://developer.android.com/studio/index.html – https://dl.google.com/android/installer_r24.4.1-windows.exe • Download do Android SDK Manager (já vem com o SDK); • Download do Android Development Tools (ADT) Plugin para Eclipse em: – https://dl-ssl.google.com/android/eclipse/ a partir do mecanismo de atualização da IDE Eclipse • Download do Android Emulator (já vem com o SDK); e • Download do Android Virtual Device (AVD) Manager (já vem com o SDK). 2. Instalação e configuração dos recursos/ferramentas; • Instalação e configuração do Java SE Software Development Kit (JDK) segundo (ORACLE, 2014) em: 74

– http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jdk-installationwindows.html • Instalação e configuração do Android Software Development Kit (SDK) de acordo com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015); – Clique duplo no instalador (no caso do executável para windows) – Seguir os passos/orientações do instalador – Passe para a instalação da IDE Eclipse, e após completado este passo retorne neste ponto – Execute a IDE Eclipse – Selecione o menu Window -> Android SDK Manager – Desmarque a caixa de seleção Instalados – Selecione os pacotes listados em Tools – Selecione os pacotes listados na versão do Android que se deseja instalar. Exemplo de uma das versões do Android - Android 4.4.2 (API 19) – Selecione os pacotes listados em Extras. Geralmente parte dos pacotes listados aqui são opcionais. Os mais comuns são: Android Support Library ou Android Support Repository, Google USB Driver e Google Play services. – Clique no botão Install • Instalação e configuração da IDE Eclipse de acordo com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015); – Descompacte o arquivo zip no local desejado – Execute a IDE Eclipse – Selecione o menu Window->Preferences e selecione Android no lado esquerdo da tela – Em SDK Location, no lado direito da tela, certifique/selecione o diretório de instalação do Android SDK. – Finalize a IDE. • Instalação e configuração do Android Development Tools (ADT) Plugin para Eclipse de acordo com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015); – Selecione o menu Help -> Install New Software – Clique no botão Add no lado direito da tela

– Informe o nome em Name, e em Location, entre a url https://dl-ssl.google.com/android/eclip – Clique OK e aguarde o download do plugin – Na lista de software disponíveis, quando Developer Tools for exibido marque-o e clique em Next/Finish. • Instalação e configuração do Android Virtual Device (AVD) Manager de acordo com (DEITEL & ASSOCIATES, INC., 2015; DEITEL; DEITEL; DEITEL, 2015); 75

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

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

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

Fonte: Criado pelo autor

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

77

Figura 19 – Tela de Boas Vindas

Fonte: Criado pelo autor

A partir deste momento o jogador tem acesso a todas as funcionalidades do jogo/aplicativo. Na tela de boas vindas é exibida uma breve descrição dos objetivos/motivos de criação/implementação do jogo PLAY’ed-SCRUM’ces. Com os respectivos autor e orientador. O jogador poderá então executar uma das seguintes ações/funcionalidades de menu: iniciar uma nova partida, visualizar as regras do jogo, estudar/apreender o conteúdo abordado no jogo ou sair/interromper o aplicativo/jogo. Outras funcionalidades como pausar e/ou parar/interromper a partida serão acessíveis após o jogador iniciar uma nova partida. Após iniciada uma partida não será permitido executar a ação de estudar até que a partida seja finalizada ou paralisada/interrompida. Dependendo da ação/funcionalidade executada as opções de menu podem mudar para “atender” a tela resultante da ação. Existem também outras importantes funcionalidades como: visualizar resultados de uma partida e visualizar partida; 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 jogador poderá/deverá “rolar/deslizar” a tela na vertical para conseguir visualizar todas as regras.

78

Figura 20 – Regras do Jogo

Fonte: Criado pelo autor

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

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

79

Figura 21 – Conteúdo de Estudo do Jogo

Fonte: Criado pelo autor

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

Fonte: Criado pelo autor

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

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

Fonte: Criado pelo autor

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

82

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

Fonte: Criado pelo autor

83

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

Ação – Visualizar Resultados da Partida

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

84

Figura 25 – Resultados de uma Partida

Fonte: Criado pelo autor

85

Ação – Pausar uma Partida

Depois de iniciada uma partida, ela poderá ser “pausada”, a qualquer momento, quando o jogador assim desejar. Isto será possível através da opção de menu Pausar. A figura 26 representa um exemplo de tela com a partida “pausada”. Figura 26 – Tela de uma Partida Pausada

Fonte: Criado pelo autor

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

Ação – Parar/Interromper uma Partida

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

86

Figura 27 – Tela de uma Partida sendo Parada

Fonte: Criado pelo autor

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

Ação – Visualizar Partida

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

87

Figura 28 – Visualização de uma Partida

Fonte: Criado pelo autor

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 futuros. As conclusões serão apresentadas com uma avaliação comparativa do que se propôs a fazer com o que de fato foi feito/realizado e com algumas ponderações.

6.1 Conclusões

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

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

91

Na terceira subetapa da etapa quatro se propôs fazer a fundamentação teórica/prática da literatura para programação de aplicativos para dispositivos móveis Android. Os resultados alcançados foram: identificação e obtenção dos recursos/ferramentas necessários; instalação e configuração destes recursos; “criação”/execução/testes de aplicativos de exemplo; e geração do arquivo *.apk para distribuição. Na quarta e última subetapa da etapa quatro se propôs fazer a codificação/implementação do aplicativo/jogo. Os resultados alcançados foram: o aplicativo/jogo foi codificado/implementado/criado; testes foram feitos/realizados durante e após a codificação; o arquivo *.apk, do aplicativo, foi gerado, “transferido”/distribuído e instalado/executado.

6.1.1 Algumas ponderações

Por toda a estrutura deste trabalho procurou-se usar o máximo de recursos visuais e de formatação, de forma a permitir/proporcionar uma melhor apresentação do texto/assunto dos quais estes tratavam. E como consequência permitir com que tais assuntos fossem assimilados mais facilmente pelo leitor. Muitos recursos visuais como: figuras, tabelas etc; e de formataçã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. Foram ainda adicionados assuntos “extras”, através de apêndices, para proporcionar ao leitor um melhor entendimento do conteúdo educacional presente no jogo PLAY’ed-SCRUM’ces. Durante a realização dos testes do jogo/aplicativo - PLAY’ed-SCRUM’ces, ou simplesmente durante uma partida pelo simples ato de jogar, ou mesmo ainda utilizando/navegando por outras funcionalidades no PLAY’ed-SCRUM’ces; foi possível se ter uma “ideia”/”noção” de quão interessante/estimulante pode ser a experiência de se utilizar/jogar este tipo de aplicativo/jogo em dispositivos móveis como Smartphone e/ou Tablets. De certa forma essa agradável ”impressão”/experiência é bastante compreensível, pois o jogador/estudante tem, “ali”, a um simples toque de seus dedos, todo um conteúdo educacional, que ele poderá “acessar”, caso seja de seu interesse ou por pura necessidade mesmo, a qualquer hora, em qualquer lugar. Melhor ainda, este conteúdo está em “formato” de um jogo, o que significa que ele pode aprender “brincando”/divertindo-se. Acredito que alguns outros fatores, falando especificamente do PLAY’ed-SCRUM’ces, foram também responsáveis por essa agradável experiência. Dentre os quais pode-se citar: o conteúdo do jogo; a forma como o conteúdo foi “estruturado” e está sendo apresentado ao jogador; a navegabilidade/dinâmica do jogo; a forma como os resultados estão sendo apresentados; e as possibilidades/funcionalidades disponibilizadas etc; estão influenciando diretamente e de forma positiva nesta “impressão” que tive ao testar/utilizar/jogar o jogo/aplicativo PLAY’edSCRUM’ces. Nas etapas 2 e 3, apesar de utilizadas as principais referências na área e a breve explanação sobre os assuntos, ainda sim, a citação de mais referências poderia “enriquecer” os

92

argumentos apresentados. Na etapa 4 (com suas respectivas subetapas) foi onde se deu a “criação” do Design Instrucional cujo jogo PLAY’ed-SCRUM’ces é parte integrante. Estes resultados foram alcançados graças a utilização/emprego de um modelo utilizado para criação de Design Instrucionais – o modelo ADDIE. Acontece que foram “executadas” apenas as três primeiras fases deste modelo – Análise, Projeto e Desenvolvimento. De forma que o DI resultante ficou/está incompleto. Restando ainda acrescentar ao DI resultante, os resultados das fases Implementação/Aplicação e Avaliação. Fases estas responsáveis, basicamente, pela execução/aplicação e avaliação do DI resultante das três primeiras fases. Dessa forma pode-se dizer que: o DI desenvolvido não foi testado (colocado à prova), e por isso sua eficácia ainda não foi comprovada. Por fim, pode-se dizer também que o jogo, apesar de disponibilizar muitos recursos gráficos como imagens, não disponibiliza quase ou nenhum recurso gráfico como animações e/ou “bonecos” etc; o que tinha sido previsto fazer na subetapa 2 da etapa 4.

6.2 Propostas de Possíveis Trabalhos Futuros

• Como mencionado anteriormente, o Design Instrucional (DI) desenvolvido neste trabalho, e cujo jogo PLAY’ed-SCRUM’ces é parte integrante, ficou/está “incompleto”. Faltando ainda os resultados das fases Implementação/Aplicação e Avaliação – do modelo ADDIE. Fases estas responsáveis, basicamente, pela execução/aplicação e avaliação do DI resultante das três primeiras fases. Portanto uma possível proposta de trabalho a ser feito/realizado é a execução/aplicação e avaliação de resultados para o DI (jogo/aplicativo) desenvolvido neste trabalho. • Considerando os seguintes fatos: o jogo PLAY’ed-SCRUM’ces é um jogo educativo, por isso seu principal objetivo é o de auxiliar o processo de Ensino-Aprendizagem do Scrum; em um ambiente universitário ou empresarial, onde exista algum curso sobre Scrum, este jogo pode ser utilizado como recurso de auxílio/apoio etc. Diante desse contexto, uma outra possível proposta de trabalho futuro é criar um segundo “módulo” para o jogo PLAY’ed-SCRUM’ces. De forma que, o que já está pronto constituiria o módulo de usuário/jogador e o novo módulo seria o de administrador. Através do qual, todo o conteúdo educacional do jogo seria gerenciado. Além disso a base de dados (banco de dados) do jogo PLAY’ed-SCRUM’ces agora não seria mais “local” (no próprio dispositivo móvel), mas em um local “remoto” e compartilhada/acessada por todos os módulos clientes (módulo de usuário/jogador). Gerenciada, também, pelo administrador do módulo administrador. Este administrador poderia ser um professor de ES, e como tal incluir, visualizar, alterar, excluir etc o conteúdo educacional do jogo. Além é claro, de poder analisar os dados de resultados das partidas realizadas por seus alunos. Proporcionando ao professor uma “poderosa” ferramenta/mecanismo para avaliar o processo de ensino-aprendizagem do Scrum. 93

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

94

Referências ABES SOFTWARE. Mercado brasileiro de software: Panorama e Tendências. São Paulo, p. 6–9, jun. 2015. Edição 2015 Dados de 2014. Disponível em: