Apresentação do TCC PLAY’ed-SCRUM’ces

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

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

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

8. 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).

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. Visão Geral do Scrum

24. 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.

25. 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”.

26. 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.

27. 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.

28. 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.

29. Processos do Scrum – Fase Iniciar

30. Processos do Scrum – Fase Planejar e Estimar

31. Processos do Scrum – Fase Implementar

32. Processos do Scrum – Fase Revisão e Retrospectiva

33. Processos do Scrum – Fase Release

34. 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.

35. 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

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. Análise do Jogo SimSE
Descrição
Resumida
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 Software
Nível de Aprend. Nível 3 – Aplicação
Categoria do Jogo Simulação
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
Resultados 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 jogo
Linguagem de Progr. Java
Plataforma Windows e Linux
Referência N/A

42. Análise do Jogo SCRUM-Scape
Descrição
Resumida
Jogo de Perguntas e Respostas.
Objetivos de Aprend. Ensinar conceitos básicos (Papéis, Artefatos e Reuniões) do Scrum
Nível de Aprend. Nível 2 - Compreensão
Categoria do Jogo RPG - Role Playing Game
Público-Alvo Estudantes da Metodologia Ágil Scrum
Modo de Interação Único Jogador/Individual
Pré-requisitos do
Público-alvo
Possuir algum conhecimento básico sobre Gerência de Projetos e Metodologia
Ágil Scrum.
Idioma Disponível Português
Resultados 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 jogo
Tipo de Jogo Digital
Linguagem de Progr. Engine de Jogos - RPG Maker
Plataforma N/A
Referência N/A

43. Análise do Jogo Playing Scrum
Descrição
Resumida
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 Scrum
Nível de Aprend. Nível 3 - Aplicação
Categoria do Jogo Simulação
Público-Alvo Estudantes de Engenharia de Software
Modo de Interação Multijogador
Pré-requisitos Púb-alvo N/A
Idioma Disponível Português
Resultados Avaliações N/A
Feedback ao Jogador Durante e após o jogo
Tipo de Jogo Digital
Linguagem de Progr. Java EE
Plataforma Computador/Web
Referência N/A

44. 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.

45. 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.

46. Diagrama DER

47. Diagrama de Caso de Uso

48. Diagrama de Classes

49. Regras do jogo PLAY’ed-SCRUM’ces

Na apresentação do jogo

50. Dinâmica do jogo PLAY’ed-
SCRUM’ces

Na apresentação do jogo

51. GAME OVER