PLAY’ed-SCRUM’ces

UM JOGO EDUCACIONAL

PARAAVALIAR E/OU

AUXILIAR O ENSINO-APRENDIZAGEM

DESCRUM

Motivações A Indústria de Software se tornou uma das maiores e

mais influentes nas sociedades contemporâneas. A influência abrange e provavelmente vai além dos

contextos sociais, políticos e econômicos. No ano de 2013, essa indústria movimentou cerca de

$407,3 bilhões no mundo. Em 2014, foram $418 bilhões, dos quais $11,2 bilhões só no Brasil.

Motivações Em conjunto com esse desenvolvimento, 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 nessa indústria para uma melhor qualidade no Gerenciamento de Projetos de Software.

Nos últimos tempos, uma das abordagens que vem ganhando cada vez mais popularidade, são as Metodologias de Desenvolvimento Ágil. Em substituição das mais tradicionais como àquelas abordagens baseadas no Modelo em Cascata.

Motivações Dentre as metodologias ágeis podemos destacar a

utilização/aceitação cada vez mais crescente do método de desenvolvimento ágil 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.

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.

Justificativas A adoção de metodologias menos teóricas/manuais e

mais práticas/interativas pode facilitar o aprendizado. E dessa forma possibilitar que se alcance resultados mais eficazes no aprendizado do SCRUM.

Uma metodologia que está sendo cada vez mais difundida como estratégia para superar/diminuir os desafios encontrados no ensino-aprendizagem de ES/SCRUM é a utilização de jogos.

Os jogos permitem proporcionar condições que aumentam a capacidade do aprendizado, através de iniciativas e ações tomadas pelo próprio jogador durante sua imersão no contexto do jogo.

Justificativas Fazendo com que o aprendizado ocorra através das

experiências pessoais e verdades criadas/definidas pelo próprio aluno/jogador. Ao mesmo tempo que os jogos possibilitam a descoberta de novos desafios, aumentando com isso a satisfação de aprender.

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.

Objetivo

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. Disponibilizando para o usuário/jogador, um recurso/ferramenta que o possibilitará avaliar/aprender conceitos a respeito desta metodologia.

Pesquisa Empregada no Trabalho

O método de pesquisa utilizado neste trabalho classifica-se como um método de pesquisa aplicada.

O que significa que o desenvolvimento deste trabalho objetivou gerar conhecimento (o jogo educacional desenvolvido), com consequente aplicação prática (utilizado/jogado por estudantes de Scrum) e direcionado à resolver/minimizar a um problema específico (resolver/solucionar a não aprendizagem total/parcial a respeito de conceitos de SCRUM).

Planejamento do Trabalho/Pesquisa Este(a) trabalho/pesquisa foi dividido em 4 etapas, sendo a quarta

subdividida e dando origem a 4 subetapas. Etapa 1 - Fundamentação teórica sobre a literatura para

ES/GP/SCRUM. Etapa 2 - Fundamentação teórica sobre a literatura para o

Ensino-Aprendizagem e os Jogos Educacionais. Etapa 3 – Fundamentação teórica sobre a literatura de JE para o

ensino-aprendizagem de ES/SCRUM. Etapa 4 – Desenvolvimento do Jogo

Etapa 4.1 - Análise/Projeto Instrucional. Etapa 4.2 - Análise/Projeto do Jogo. Etapa 4.3 – Fundamentação teórica/prática sobre

Programação para Dispositivos Móveis Android. Etapa 4.4 – Implementação.

Engenharia de Software Engenharia de Software é uma “espécie” de tecnologia baseada em

camadas, 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 e/ou 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.

Engenharia de Software 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.

Gerência de Projetos Projeto: é um esforço temporário empreendido para

criar um produto, serviço ou resultado exclusivo. 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.

Gerência de Projetos 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 inclui: determinar quais as necessidades das partes interessadas e o estabelecimento de comunicação entre as mesmas; identificação dos requisitos do projeto; atender esses requisitos bem como de suas entregas; e equacionar as restrições de escopo, qualidade, cronograma, orçamento, recursos e riscos inerentes a todo projeto.

Gerência de Projetos As restrições de projeto estão tão relacionadas entre si

que, a(s) alteração(ões) em uma delas implica, necessariamente, em mudanças/adaptações 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 que se cumpra a entrega dos resultados, de acordo com os requisitos preestabelecidos.

SCRUM É um Framework através do qual pessoas podem tratar

e resolver problemas complexos e adaptativos, enquanto produtivamente e criativamente entregam "resultados" com o mais alto valor de negócio. Scrum possibilita o emprego conjunto de processos/técnicas e deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que se 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.

Teorias do SCRUM As teorias empíricas, para controle de processos, 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 processos empíricos é apoiado por três pilares: Transparência: Os aspectos mais importantes do processo

devem estar acessíveis aos responsáveis pelos resultados. 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.

Adaptação: Quando aspectos do processo saem do escopo do projeto, impossibilitando a aceitação do resultado, estes aspectos/processos devem ser adaptados/ajustados o quanto antes possível para minimizar os desvios.

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.

As regras integram os eventos, papéis e artefatos, controlando as relações e interações entre os mesmos.

Papéis do Scrum Scrum Master: é o responsável, entre outras coisas,

por garantir o entendimento e aplicabilidade do 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.

Produto Owner/Dono do Produto: é o responsável, entre outras coisas, por maximizar o valor de negócio do projeto. Além de gerenciar o Backlog do Produto.

Eventos do Scrum Sprint: é o principal evento 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 e disponibilizada. Assim que um Sprint termina um novo é inciado e o ciclo se repete até a conclusão do projeto.

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.

Eventos do Scrum 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 aprovada liberada para o cliente.

Retrospectiva do 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.

Artefatos do Scrum 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. E existirá enquanto o produto existir.

Backlog do Sprint: é um subconjunto de requisitos do BPP escolhidos para fazerem parte do próximo Sprint. O BS é uma seleção dos requisitos/funcionalidades que devem estar presentes na próxima versão do produto, e a estimativa de trabalho que será necessário para que seja atingido este objetivo.

Artefatos do Scrum Incremento/Nova Versão do Produto: é o conjunto de todos os

requisitos do BP completados até o Sprint atual mais 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.

Burndown Chart: 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.

Taskboard/Scrumboard: 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.

Visão Geral do Scrum

Visão Geral do Scrum Um projeto Scrum é iniciado com a Reunião de Visão do Projeto,

resultando em um plano com a Declaração de Visão do Projeto. O Produto Owner apoiado na DVP desenvolve o artefato Backlog

Priorizado do Produto. Em seguida acontece a Reunião de Planejamento das Releases,

onde se define o Cronograma da Release e a duração do Sprint. O primeiro Sprint se inicia com a Reunião de Planejamento do

Sprint, originando o artefato Backlog do Sprint. Durante o Sprint ocorrem as Reuniões Diárias, possibilitando a EDS

discutir sobre o trabalho realizado e dificuldades enfrentadas. Próximo ao fim do Sprint ocorre a Reunião de Revisão do Sprint,

onde uma nova versão do produto, sendo aprovada, será liberada. Por fim o ciclo Sprint se encerra com a Reunião de Retrospectiva

do Sprint, onde possíveis melhorias serão apresentadas.

O Framework SCRUM

Constituem a base do framework Scrum: princípios, aspectos e processos do Scrum.

Princípios: definem as diretrizes essenciais na aplicação do framework Scrum e devem fazer parte de qualquer projeto Scrum. Não “negociáveis”.

Aspectos: precisam ser evidenciados e gerenciados/controlados durante todo o projeto Scrum. São “negociáveis”.

Processos do Scrum: definem as atividades/práticas e o fluxo para um projeto Scrum. São “negociáveis”.

Princípios do SCRUM

Controle de Processos Empíricos: Em Scrum, as decisões são tomadas com base na observação e em experimentos, ao invés de no planejamento inicial detalhado.

Auto-organização: em um ambiente “auto-organizável” proporcionado pelo Scrum, possibilita ao seus colaboradores determinarem, por si mesmos, como fazer o trabalho, sem a necessidade de supervisão direta de suas tarefas.

Colaboração: refere-se ao Time Central do Scrum trabalhando e interagindo com os Stakeholders para criar e validar as versões do projeto, de forma a atender aos seus requisitos.

Priorização Baseada em Valor: destaca um dos propósitos do Scrum, que é o de maximizar a entrega de valor de negócio em um período de tempo mínimo.

Time-boxing: demonstra como o tempo é considerado um fator de restrição na gerência de projeto, propondo a fixação de um certo período de tempo para cada processo/atividade realizada no projeto.

Desenvolvimento Iterativo: o trabalho a ser realizado deverá ocorrer dentro de intervalos de tempo bem definidos e repetitivos, e de forma incremental. Permitindo dessa forma uma melhor gerência de eventuais mudanças e como consequência atender as necessidades dos clientes.

Aspectos do SCRUM

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.

Justificativa de Negócio: 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.

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.

Mudanças: qualquer projeto está sujeito à mudanças, e por esta razão os processos no Scrum são projetados para aceitá-las. Através de ciclos/Sprints iterativos e curtos é possível incorporar, o quanto antes, o feedback do cliente sobre cada “entregável” do Sprint.

Riscos: 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.

Processos do Scrum 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.

Processos do Scrum – Fase Iniciar

Processos do Scrum – Fase Planejar e Estimar

Processos do Scrum – Fase Implementar

Processos do Scrum – Fase Revisão e Retrospectiva

Processos do Scrum – Fase Release

Ensino-Aprendizagem 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.

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.

Qualquer evento que objetiva facilitar a aquisição de algum conhecimento, habilidades, estratégias, atitudes, etc; pode ser caracterizado como uma forma de instruir/ensinar. 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.

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.

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

O Padrão/Modelo ADDIE ADDIE é um framework que define processos genéricos utilizados para

o desenvolvimento de projetos instrucionais (Design Instrucional), representando guias descritivos para elaboração de “ferramentas” de apoio e de treinamentos.

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.

Fases do Modelo ADDIE 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.

Projeto: na fase de projeto determina-se como ficará o “recurso”/UI depois de produzido. São definidos seu conteúdo, a sequência de apresentação para este conteúdo, e as estratégias e atividades de ensino para se atingir as metas/objetivos de aprendizagem.

Desenvolvimento: nesta fase será desenvolvido e/ou organizados o conteúdo. O conteúdo deverá está de acordo com o que foi definido na fase de projeto, e sempre procurando atender as necessidades e objetivos identificados na fase de análise.

Implementação: na fase de implementação ocorre a aplicação da UI produzida. 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.

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/treinamentos. Aborda os domínios cognitivo, psicomotor e afetivo, mas é mais

difundida/conhecida e aplicada pelos “trabalhos” relacionados ao domínio cognitivo. No domínio cognitivo a efetivação da aprendizagem (conhecimentos/habilidades, etc) é medida através de níveis de complexidade.

Jogos Educacionais/Jogos “Sérios” 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.

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.

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.

Dentre as possíveis áreas de aplicação destaca-se a educacional, engenharia, saúde, militar, planejamento de cidades, produção etc. Recentes estudos, considerando diferentes contextos, tem demonstrado os benefícios de se utilizar os jogos com fins além do entretenimento.

Jogos Educacionais/Jogos “Sérios” 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.

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.

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.

Os jogos educacionais podem ser digitais ou não digitais e podem ser empregados, como recurso educacional, nos diferentes níveis do processo de ensino-aprendizagem.

Análise do Jogo SimSEDescriçãoResumida

O jogador assume o papel de gerente de projetos e será responsável por gerenciar uma equipe de desenvolvedores.

Objetivos de Aprend. Ensinar Processos de Engenharia de SoftwareNível de Aprend. Nível 3 – AplicaçãoCategoria do Jogo SimulaçãoPúblico-Alvo Estudantes de Processos de Engenharia de Software/Gerência de

ProjetosModo de Interação Único Jogador/IndividualIdioma Disponível InglêsResultados de Avaliações

Quatro testes foram realizados: 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.

Feedback ao Jogador Durante e após o jogoLinguagem de Progr. JavaPlataforma Windows e LinuxReferência N/A

Análise do Jogo SCRUM-ScapeDescriçãoResumida Jogo de Perguntas e Respostas.

Objetivos de Aprend. Ensinar conceitos básicos (Papéis, Artefatos e Reuniões) do ScrumNível de Aprend. Nível 2 - CompreensãoCategoria do Jogo RPG - Role Playing GamePúblico-Alvo Estudantes da Metodologia Ágil ScrumModo de Interação Único Jogador/IndividualPré-requisitos do Público-alvo

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

Idioma Disponível PortuguêsResultados de Avaliações

Com relação ao aprendizado adquirido com o jogo: 70% disseram ter aprendido mais com jogo; nível de conhecimento, sobre o assunto, aumentou após o jogo.

Feedback ao Jogador Durante e após o jogoTipo de Jogo DigitalLinguagem de Progr. Engine de Jogos - RPG MakerPlataforma N/AReferência N/A

Análise do Jogo Playing Scrum

DescriçãoResumida

O jogador poderá assumir o papel de Produto Owner, Scrum Master ou Equipe de Desenvolvimento. Ele poderá compor equipes para o desenvolvimento de 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 Aprend. Ensinar conceitos/práticas da Metodologia Ágil ScrumNível de Aprend. Nível 3 - AplicaçãoCategoria do Jogo SimulaçãoPúblico-Alvo Estudantes de Engenharia de SoftwareModo de Interação MultijogadorPré-requisitos Púb-alvo

N/A

Idioma Disponível PortuguêsResultados Avaliações

N/A

Feedback ao Jogador Durante e após o jogoTipo de Jogo DigitalLinguagem de Progr. Java EEPlataforma Computador/WebReferência N/A

Análise Instrucional Público-alvo do PLAY’ed-SCRUM’ces: de uma forma geral este público poderá ser

formado por estudantes da metodologia ágil SCRUM. Contexto Organizacional/Instrucional: salas de aula, em casa, ou em qualquer

local/lugar que se deseje jogar. 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 os princípios, aspectos e processos do frameowork Scrum.

Projeto Instrucional Conteúdo de Ensino: 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; os princípios, aspectos e processos frameowork Scrum.

Sequência de Apresentação do Conteúdo: o conteúdo do jogo foi estruturado em duas partes. Uma parte prática com as perguntas do jogo (para jogar) e outra teórica (para estudar).

Estratégias/Atividades de Ensino:

desenvolvimento do jogo PLAY’ed-SCRUM’ces, para avaliar e/ou auxiliar/apoiar o processo de ensino-aprendizagem de conceitos sobre o Scrum.

Apresentação do conteúdo educacional, na parte prática, em formato de perguntas “fechadas” e uma introdução teórica/conceitual para cada assunto do qual se tratam as perguntas.

As perguntas sendo agrupadas em níveis de dificuldades. Apresentação do conteúdo educacional de forma teórica. 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. Poderão ser utilizados outros jogos educacionais semelhantes a este para ambientar os

alunos com este tipo de recurso. O jogo poderá ser aplicado em laboratórios utilizados para as aulas “práticas” de

cursos/disciplinas que contemplem o Scrum, ou como atividade extra classe.

Diagrama DER

Diagrama de Caso de Uso

Diagrama de Classes

Regras do jogo PLAY’ed-SCRUM’ces

Na apresentação do jogo

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

Na apresentação do jogo

GAME OVER