Ata da 1ª reunião do Grupo EE Games

Data: 29/08/2013

Escolha do tipo de jogo

Algumas ideias de jogos foram apresentadas pelos membros do grupo. Dentre elas foi escolhida a ideia de um jogo de arcade do tipo “Whac-a-mole” (jogo no qual toupeiras surgem de buracos e o jogador deve acertá-las para marcar pontos).

A ideia principal é a de que palavras relacionadas com conceitos de Engenharia de Software apareceriam na tela e o jogador deverá clicar nelas para marcar pontos. Algumas palavras “erradas”, não relacionadas com a matéria, também apareceriam e, caso o jogador clique nelas, perderia pontos ou sofreria algum tipo de penalidade, como congelamento do mouse, ou outros.

À medida que o jogador clica nas palavras corretas, estas formam frases sobre conceitos de Engenharia de Software e caso alguma frase seja completada, o jogador ganha pontos extras.

Pode-se também utilizar a ideia de “dica voadora”, uma frase que passa na tela para dar ao usuário uma dica de qual palavra falta para completar a frase.

O nível de dificuldade é escolhido antes do início do jogo e vai regular a quantidade de palavras “erradas” e a velocidade de aparecimento das palavras.

Escolha da engine

A engine escolhida foi Game Maker: Studio (http://en.wikipedia.org/wiki/GameMaker:_Studio) desenvolvida pela YoYo Games, devido a sua facilidade de programação.

Escolha do processo para o desenvolvimento do software

Após uma votação entre os integrantes do grupo, o processo escolhido foi o Kanban, pois ele permite uma boa visibilidade do trabalho que está sendo desenvolvido e ele funciona bem para pequenas equipes.

Metodologia de trabalho

Foi decidido que o grupo fará reuniões uma vez por semana e que os integrantes do grupo se revezarão na comunicação com o cliente (a cada semana um integrante será responsável por postar no blog do trabalho prático). Foi decidido também que releases serão liberados em intervalos de aproximadamente duas semanas.

Gestão de configurações e controle de versões

Foi decidido que utilizaremos a ferramenta Mercurial (mercurial.selenic.com) para realização do controle de versão e a ferramenta Google Code (code.google.com)como repositório central de código.

Lembrando: O trabalho será principalmente avaliado com relação a aderência a um processo e justificativa das tomadas de decisões! Esta parte da avaliação equivale a 60% do total.

Sendo assim, que processo seguir?

Aqui temos algumas referências simples de entender. 

XP 

Dentro do espírito de simplicidade, um dos Valores XP, a quantidade de artefatos na XP é bastante reduzida. Na verdade, na XP nós não falamos realmente de artefatos como tais. Exceto pelo código de produção, todos os outros artefatos produzidos pelo processo implicam em trabalho que é tangencial à meta final, um produto executável. Em teoria, todo o resto deve ser considerado como opcional. O conjunto de artefatos apresentado aqui é comumente usado, pelas equipes XP, para entregar software de forma eficiente. Como regra, tente limitar a quantidade de esforço colocado em qualquer trabalho tangencial a menos que seja comprovado que ele melhore o processo, de alguma forma demonstrável.

Veja aqui os artefatos que fazem parte do XP. Isto deixa evidente a aderência ao processo utilizado, se utilizado.

Link XP

SCRUM

Scrum é um framework para desenvolver e manter produtos complexos. Este guia contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles apóiam o Guia do Scrum.

Veja aqui os artefatos que fazem parte do SCRUM. Isto deixa evidente a aderência ao processo utilizado, se utilizado.

Link SCRUM 1 

Link SCRUM 2

Também é interessante usar o Kanban
O Kanban é baseado na ideia onde atividades em andamento devem ser limitadas. Um novo item só pode ser iniciado quando o item em andamento é finalizado ou quando uma função automática inicia o mesmo instantaneamente.
O Kanban, basicamente, tem como principal objetivo transformar o trabalho em andamento visível para toda equipe, criando um sinal visual que indica que o novo trabalho pode ou não ser iniciado e se o limite acordado para cada fase está sendo respeitado.


Veja o artigo: Desenvolvimento Ágil de software: uma análise sintética a partir da metodologia Kanban


Dilbert usando Kanban (video)

Mais CIOs estão tornando-se ágeis

Mais CIOs estão tornando-se ágeis. Número de organizações com planos para implantar projetos de desenvolvimento ágil vem aumentando, revela pesquisa...
(http://cio.uol.com.br/tecnologia/2013/08/26/mais-cios-estao-tornarem-se-ageis)

Área reservada para a formação dos grupos de trabalho.

Não esqueça de ver o post anterior sobre o Trabalho Prático (TP)
Faça aqui os seus comentários e discussões para a formação dos grupos, use este espaço!

Proposta (TP):

Projeto e implementação de um jogo para ensinar conceitos de Engenharia de Software (ES).
Poderá ser escolhido conceitos sobre Requisitos ou Processos de software.

Importante:

TP estará descolado das aulas Teóricas da disciplina. Enquanto as aulas teóricas seguem uma certa sequência o grupo deverá trabalhar desde agora com vários aspectos que não estão presentes nas aulas teóricas ou que serão tratados apenas no final do semestre.

Objetivo:

Consiste na contratação do grupo como time de desenvolvimento de um jogo.
O cliente do jogo é o professor Sérgio Crespo (crespo@dcc.ufmg.br) o jogo deve ter como objetivo ensinar conceitos de Engenharia de Software.

O desenvolvimento deverá ser do tipo interativo incremental, entregas frequentes, controle de versão, dirigido por testes, o grupo deve investir na maturidade do processo.

IMPORTANTE!!!!

O trabalho sera principalmente avaliado com relação a aderência a um processo e justificativa das tomadas de decisões! Esta parte da avaliação equivale a 60% do total.
O jogo desenvolvido será também avaliado entre os alunos que deverão ordenar os resultados dos grupos (40%)

Toda a evidencia de aderência ao processo deve estar postado no BLOG da turma e justificada, bem como todos os objetos entregáveis que o processo exige.
>>>>  http://esrrsc.blogspot.com.br/ <<<<
===========================================================

AVALIAÇÃO

O processo de avaliação é incremental e formativa. Incremental pois as avaliações serão de forma continua, levando em consideração o esforço realizado pelo grupo na aderência ao processo, nas suas postagens no Blog e em seus seminários. Os documentos postados tem a característias de serem sempre atualizados pelos membros do grupo, gerando novos documentos com mais

informação e isto reflete uma melhoria na avaliação seguinte.
A avaliação formativa visa fornecer subsídios para que o aluno compreenda o seu próprio processo de aprendizagem e o funcionamento de suas capacidades cognitivas subjacentes na resolução de problemas. Dentro desse escopo, o foco se desloca do nível do desempenho para o da competência.

Para o professor, a avaliação formativa orienta e regula a prática pedagógica, uma vez que se propõe analisar e identificar a adequação de ensino com o verdadeiro aprendizado dos alunos. No nosso caso, estamos priorizando manter e ajudar o aluno na aderência ao processo.

O grupo também será avaliado em termos de conseguir se organizar para trabalhar de forma que o trabalho não seja do tipo "picos de esforço"... ou escrito de outra forma: deverá ser possível identificar um esforço mais distribuído e não simplesmente um esforço "anormal" umas horas ou dia antes de um ponto de verificação (a verificação será feita na sua maior parte em função das publicações no "blog").

>>>>  http://esrrsc.blogspot.com.br/ <<<<
********************************************************************************


No artigo http://sbgames.org/sbgames2012/proceedings/papers/artedesign/AD_Full16.pdf pode ter uma noção de uma metodologia para o desenvolvimento de jogos.


Cada grupo deve preparar o roteiro do jogo, selecionar a engine mais apropriada, justificando a decisão.
No endereço http://en.wikipedia.org/wiki/List_of_game_engines pode-se ter uma relação de motores de jogos disponíveis.

É importante que o jogo permita que um administrador tenha acesso a dados do jogador de forma a identificar se o conceito teve indicativos de ter sido assimilado ou não.

O estilo do jogo fica a critério do grupo, por exemplo: Jogos de plataforma, corrida, luta, esporte, simulação, musical, estratégia, aventura, Tabuleiro, ação, Quebra-cabeça, etc.

Cada grupo deve ser o usuário do experimento de outro grupo, de forma a testar o aprendizado dos conceitos.

Os grupos, como uma das etapas de avaliação, devem promover seminários, de 20 minutos, informando o desenvolvimento do projeto, suas dificuldades, cronograma e avanços obtidos da

apresentação anterior. O cronograma dos seminários esta assim elaborado:

Seminario1 05 set
Seminario2 19 set

*****26 prova

Seminario3 03 out
Semonário4 17 out
Seminario5 31 out
Apresentaçao final 19 nov