Tarefas da Monografia (Parte I)

Oi pessoal!!!

 

Conforme combinado, vou colocar hoje no grupo SimulES as primeiras versões dos meus arquivos relacionados a cada tarefa que me foi confiada na última aula visando a monografia final da disciplina “Evolução de Software”.

• Arquivo .pdf referente ao Histórico da Monografia;
• Arquivo .pdf referente à Conclusão da Monografia;
• Arquivo .pdf referente ao tópico Refatoração da Monografia, e
• Arquivo .pdf referente ao tópico Gerência de Configuração da Monografia.

 Para acessar os arquivos, basta consultar o nosso grupo do SinulES no google. Todos já estão cadastrados, ok?

 

Até o próximo post!

Montagem de um site para o jogo SimulES

Oi pessoal!!!

 

Estou aqui novamente para informar a todos que estou montando um site para o jogo SimulES. Acredito que essa é um boa forma de divulgar o jogo quando o mesmo estiver com tudo direitinho, bem documentado e com todas as nossas idéias aplicadas. Pensei em algo mais ou menos assim:

 

    

 

É só clicar para que a imagem seja ampliada, ok? O que vocês acham? Coloquei apenas a página principal para ilustrar a idéia. Mas já criei praticamente todas as demais páginas.

 

Novas idéias são sempre bem-vindas. Tenho vários templates para montagem de outros modelos. Gostei desse por ser diferente. Mas aceito sugestões.

 

Alguns outros modelos:

 

Achei esse muito bonito, mas também muito escuro, o que tira um pouco a idéia de diversão que o jogo SimulES proporciona.

 

 

 

Gostei desse, mas achei muito comum. Ignorem, por favor, as informações, pois é só para ter uma idéia, ok?

 

 

Até o próximo post!!!!

Novo Tabuleiro para o Jogo SimulES

Oi Pessoal!

 

Alguns já avaliaram o novo tabuleiro, mas resolvi postar no blog para aqueles que ainda não o fizeram. A opinião de todos é muito importante para o sucesso do jogo. Espero que gostem!!! Basta clicar na imagem para ampliar a mesma e visualizar melhor o tabuleiro, ok?

 

Até o próximo post!!!

Algumas das minhas novas sugestões para as cartas do Jogo SimulES…

Cartas de Problemas que mereciam ser revistas:

Poderíamos permitir artefatos cinzas, desde que inspecionados e corrigidos, por exemplo. Poderíamos apenas alterar a carta para artefatos cinzas não inspecionados maiores ou iguais a 2 ou 3. E a penalidade ser, perder esses artefatos cinzas e 2 brancos que foram comprometidos pela falta de inspeção dos cinzas, por exemplo.

 

Acho que essa carta por ser persistente poderia ser amenizada, ela é muito dura na penalidade!

 

Na penalidade poderia ser escrito até três…. Pois se ela for lançada ao jogador no começo do jogo é certo que o mesmo não terá tantos artefatos de códigos ainda…

Cartas de Conceitos que mereciam ser revistas:

As cartas de conceitos CCD1 (Ambiente de Teste), CDS1 (Desenho por Contato), CGR4 (Inspeção) devem ser alteradas, substituindo o termo componente por módulo, por exemplo. Acredito ser pertinente especificar que é apenas parte do módulo e não todo o módulo.

Sugestões

Acredito que devemos criar novas cartas de conceitos e tentar, na medida do possível, balancear melhor a relação entre cartas de conceito e cartas de problemas.

 

Por exemplo:

• Carta de Conceito de Código:
  Ajuda de um Especialista da Área: Use essa carta para produzir mais dois artefatos de código.

 

• Carta de Conceito de Comunicação:
  Reuniões Semanais: Use essa carta para neutralizar um problema de comunicação entre a equipe de engenheiros.

 

• Carta de Conceito de Desenho:
  Ótima Ferramenta de Design: Use essa carta para neutralizar um problema de desenho.

 

• Carta de Conceito de Recursos Humanos:
  Plano de Saúde Ampliado: Use essa carta para neutralizar um problema de recursos humanos e ainda produzir um artefato de requisito por engenheiro de software.

 

Acrescentar alguns problemas de comunicação seria interessante também:

 

• Desentendimento entre Membros da Equipe: Todos os engenheiros de software do adversário deverão perder (cada um) um artefato de sua escolha.

 

• Presença de um Líder na Equipe: Engenheiros de software com artefatos de código menores ou iguais a 2 não devem produzir na próxima rodada, mas podem inspecionar ou corrigir.

 

• Sentimento de Inferioridade: Engenheiros de software com maturidade menor ou igual a 2 só podem corrigir artefatos na próxima rodada.

Divisão de tarefas para a Monografia…

Oi Pessoal!

 

Gostaria de divulgar no Blog o que ficou estabelecido na divisão de tarefas visando a monografia final da disciplina de Evolução de Software do Professor Julio:

 

– Introdução: Bruno e Maurício.

– Histórico: Fillipe e Milene.

– Produto e Análise da Evolução: Todos, mas o Bruno e o Maurício organizam o texto final juntando os feitos individuais.

– Conclusão: Fillipe e Milene.

Além disso, o Fillipe e eu decidimos criar um grupo no google para dar continuidade à evolução do jogo SimulES. O Maurício e o Bruno estão convidados a participar. Aliás, intimados… Hehehehe….

 

Espero que todos concordem com a divisão estabelecida.

 

Qualquer postagem pode ser feita no grupo google, ok?

 

Mandei um e_mail para cada um de vocês.

 

Até o próximo post!

Aprendendo na prática o que é EVOLUÇÃO!

Gostaria de fazer uma recaptulação do que foi estudado ao longo da disciplina de evolução de software e expor como aprendemos na prática as questões colocadas pelo Professor Julio e debatidas em sala entre os alunos.

Primeiramente, vimos na prática como é importante refletir sobre as leis de Lehman, principalmente, sobre a Oitava Lei. Trata-se da lei que apresenta um posicionamento sobre a questão do feedback e como esse ajuda na evolução dos softwares. Nosso objeto de estudo foi o SimulES. Percebemos, estudando e evoluindo o jogo SimulES, que documentar, desenvolver e institucionalizar um software são tarefas muito difíceis e que requerem muita habilidade, união e colaboração dos membros envolvidos nesses feitos. Mas, não apenas isso, vimos também que, por mais que a equipe seja unida, por mais que todos lutem por bons resultados, só conseguimos perceber os reais problemas e levantar quais são os pontos fortes do software quando o submetemos a um grupo de usuários. São esses usuários que nos dão feedbacks a respeito do produto. E sejam feedbacks positivos ou negativos, temos que o importante é identificar quais direções tomamos, quais delas deram certo e quais deram errado de acordo com a reação daqueles que avaliaram o produto.

No jogo SimulES notamos que os sucessos são oriundos de características que também nos agradaram quando jogamos o mesmo, tais como: (i) diversão devido à presença de cartas bem humoradas (carta de engenheiro “Filho do chefe” e “Paula”); (ii) competição entre os jogadores; (iii) emoção ao longo das rodadas de ação e conceito, e ainda (iv) vontade de vencer que é despertada nos jogadores. Isso tudo pode ser visto como um grande feito conseguido no SimulES, pois trata-se de um jogo educativo que envolve conquistas, junto aos usuários, normalmente obtidas com jogos tipicamente voltados para diversão.

Já as críticas, tais como lentidão, muitos problemas por rodada e falta de controle sobre as fases podem ser vistas como fortes candidatas à mudança e, portanto, à evolução. Temos que procurar melhorar sempre!!!

Logo, o feedback, muito bem documentado no artigo do professor Lehman (link), é importantíssimo para que um software evolua sempre e de forma a atender as espectativas tanto dos clientes, quanto da empresa, quanto dos desenvolvedores. Um software de sucesso costuma ter vida longa e por isso a evolução se faz necessária e presente em todo o ciclo de vida do software.

Um outro ponto importante foi manter o rastro do jogo ao longo das evoluções que propusemos para o mesmo e usando como base as versões geradas. Fizemos na mão, por exemplo, o controle de versão e notamos que é muito difícil determinar a granularidade desse controle, se é uma letra, uma palavra, uma sentença ou outros. Além disso, notamos que uma vez estabelecida a granularidade, é complicado estabelecer as relações entre o que mudou e o que não mudou, o que deve ser alterado e o que já foi alterado. Fica aqui mais um ponto para reflexão levando em consideração a RASTREABILIDADE.

Enfim, o que podemos perceber é que a Evolução de um Software NÃO é algo SIMPLES, não existe um guia passo-a-passo de como evoluir de forma a obter SEMPRE sucesso, de como fazer o rastro e qual a granularidade do mesmo, dentre outros desafios impostos ao longo do ciclo de vida do software. Portanto, precisamos nos basear nas boas práticas e tentar usufruir bastante dos conceitos dados em sala e debatidos com o Professor Julio ao longo da disciplina de Evolução de Software.

Até a próxima semana!

Proposta para melhorar ainda mais a primeira impressão do Jogo SimulES…

Pensei bastante a respeito dos comentários dos alunos e na possibilidade de melhorar ainda mais a impressão do Jogo SimulES quando jogado a primeira vez. Foi quando tive a idéia de desenvolver algumas coisinhas que facilitam na hora de jogar e que provavelmente permitirão maior jogabilidade.

Primeiramente, pensei em um tabuleiro central. Essa tabuleiro contém as fases do jogo. Os jogadores seriam representados por piões de cores diferentes. Dessa forma os jogadores saberiam em que fase estão, se é rodada de ações, de conceitos ou mesmo se devem tratar os problemas. Além disso, existe uma breve explicação em cada quadro do tabuleiro informando o que normalmente espera-se dos jogadores em cada fase do jogo. Abordei questões importantes como, quando demitir, quando contratar, quando lançar um problema, dentre outras dúvidas que foram levantadas pelo grupo de alunos que jogaram como voluntários. A seguir apresento uma sugestão de como poderia ser esse tabuleiro central:

 

 

 

 

Empolgada com a idéia, também proponho um área para colocação das cartas de problemas e conceitos, cartas de engenheiros de software e um espaço central para o cartão de projeto. Pode existir também uma área para lançamento do dado e uma outra, aproveitando o embalo, para colocação dos artefatos brancos e cinzas. Abaixo seguem as sugestões. Espero que gostem!!!

 

Tabuleiro de Cartas:

 

Tabuleiro de Artefatos:

 

Área para Lançamento do Dado:

 

Até o próximo post!!!

Minha Visão Geral do SimulES com base nos comentários dos alunos voluntários…

Lendo o que os alunos escreveram a respeito do SimulES, estabeleci 4 pontos relevantes e que merecem especial atenção:

• Apresentação do Jogo: relativo à qualidade das cartas, tabuleiro, dado e demais recursos.
• Jogabilidade: indica o quanto dinâmico é o jogo.
• Qualidade da Documentação: indica quanto os pacotes contendo as regras do jogo estão bem elaborados.
• Facilidade de Entendimento: indica se o jogo é fácil de ser entendido dados que todos os voluntários eram da área de informática.
• Utilidade como jogo de Aprendizado: indica o quão útil é o jogo em termos de aprendizado e exercício da Engenharia de Software.
• Primeira Impressão de Quem Joga: indica se a primeira impressão dos voluntários é ótima, boa, regular ou péssima.

A figura a seguir ilustra como acho que os alunos enxergaram o jogo segundo esses aspectos. Vale lembrar que a “Qualidade da Documentação” é resultado de um único feedback que obtivemos, uma vez que apenas um único aluno leu o pacote contendo a documentação com as regras do jogo.

                  

Acredito que fundamentalmente precisamos encontrar formas de melhorar a dinâmica do jogo, aumentando a jogabilidade do mesmo e causando uma impressão mais positiva para aqueles que jogam pela primeira vez o jogo SimulES. Sei que é um desafio, mas acredito que uma forma de prover isso seria revisar as regras e balancear melhor o número de cartas de problemas e cartas de conceitos. Além disso, de repente ajudaria ter um tabuleiro central com as etapas do jogo bem estabelecidas e “piões” marcando a posição de cada jogador no jogo. Isso facilitaria para os jogadores se encontrarem no jogo e, principalmente para que os mesmos não se preocupem com detalhes que tiram a atenção dos objetivos principais do jogo que são “aprender Engenharia de Software” e “se divertir para atingir esse feito”.

Até o próximo post!

Construção dos Cenários do Jogo SimulES (Parte III)

Os cenários obtidos com a evolução do jogo são apresentados a seguir e ajudam a entender as regras do jogo SimulES estabelececidas na versão E:

Título: Dinâmica do SimulES

Objetivo: Descrever as regras do SimulES

Contexto: INICIO DE JOGO.

Atores: jogador, jogador da vez.

Recursos: dado, cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador da vez inicia turno.

Se jogador da vez puder empacotar o produto, então jogador da vez SUBMETE PRODUTO.

Jogador da vez JOGA RODADA DE AÇÕES.

Cada jogador JOGA RODADA DE AÇÕES.

Jogador da vez JOGA RODADA DE CONCEITOS.

Cada jogador JOGA RODADA DE CONCEITOS.

Jogador da vez TRATA PROBLEMAS.

Cada jogador TRATA PROBLEMAS. 

______________________________  

Título: Inicio de jogo

Objetivo: Descrever os preparativos para início do jogo.

Contexto: Tabuleiro de cada jogador colocado na mesa de jogo.

Cartas embaralhadas sobre a mesa.

Cada jogador tem uma carta de engenheiro de software.

Atores: jogador, jogador da vez.

Recursos: dado, cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo e é o jogador da vez.

Jogador da vez escolhe aleatoriamente do monte de cartões de projeto. Restrição: Outros jogadores têm que concordar com o cartão escolhido pelo jogador da vez.

Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário.  

______________________________   

Título: Joga Rodada de Ações

Objetivo: Descrever as regras da rodada de ações.

Contexto: Cartão do projeto no centro da mesa.

Jogador da vez já foi escolhido.

Atores: jogador da vez.

Recursos: dado, cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador da vez usa seus Engenheiros de Software em CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE ARTEFATO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades e o custo dessas ações podem ser afetados por cartas de conceitos ou cartas de problemas.

Jogador da vez lança o dado.

Se dado igual a 1, 2 ou 3, então jogador da vez pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador da vez não pode pegar cartas do monte de engenheiros de software.

Se dado igual a 4 ou 5 ou 6, então jogador da vez pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3.  

Se jogador da vez não usou engenheiros de software e nem jogou o dado, então INTEGRA ARTEFATOS EM UM MÓDULO.    

______________________________  

Título: Joga Rodada de Conceitos

Objetivo: Descrever as regras da rodada de conceitos.

Contexto: Cartão do projeto no centro da mesa.

Jogador da vez já foi escolhido.

Todos os jogadores terminaram JOGA RODADA DE AÇÕES.

Atores: jogador, jogador da vez, adversário.

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:

Se jogador da vez tiver mais de 6 cartas nas mãos deve descartar as excedentes.

Jogador da vez aplica conceitos caso sejam permanentes, colocando-os ao lado do tabuleiro. Restrição: Não pode exceder o orçamento do projeto.

Se jogador da vez tem cartas de engenheiro de software, então jogador da vez contrata engenheiros de software de acordo com o orçamento do projeto (que consta no cartão do projeto), colocando-os no tabuleiro.

Se jogador da vez deseja demitir engenheiro de software, deve removê-lo do tabuleiro e descartá-lo.

Se jogador da vez deseja destruir um artefato, deve removê-lo do tabuleiro e descartá-lo.

Jogador da vez pode descartar outras cartas, retornando-as aos montes apropriados.

Jogador da vez escolhe até 3 adversários e pode submeter para cada um deles uma carta de problema. Restrição: Demais jogadores não escolhidos não são afetados por essas cartas de problema. Adversário não pode ter mais de 2 cartas de problemas permanentes e mais de 3 cartas de problemas temporários.

Jogador da vez lê em voz alta o problema que submete ao adversário. Restrição: Quem escolhe as cartas do adversário afetadas pelos problemas impostos é o próprio jogador da vez. 

 ______________________________  

Título: Trata Problemas

Objetivo: Descrever as regras do tratamento de problemas.

Contexto: Cartão do projeto no centro da mesa.

Todos os jogadores terminaram JOGA RODADA DE CONCEITOS.

Adversário recebeu cartas do jogador da vez.

Atores: jogador, jogador da vez, adversário.

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Adversário estuda como atender a demanda da carta de problema colocada pelo jogador da vez. Restrição: Qualquer penalidade imposta pela carta de problema deve ser arredondada para baixo quando necessário.

Adversário atende a demanda da carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito.

Se o problema é temporário então adversário descarta a carta de problema.

Se o problema é permanente então adversário mantém carta de problema. 

 ______________________________   

Título: Submete produto

Objetivo: Descrever as regras da submissão de produto.

Contexto: Cartão do projeto no centro da mesa.

Jogador de vez acabou de integrar seu último módulo.

Atores: jogador, jogador da vez, adversário.

Recursos: cartas, cartão do projeto, módulo.

Episódios:
Jogador da vez mostra que produziu todos os módulos, de acordo com o cartão do projeto.

Adversários escolhem todos os artefatos de x módulos, onde x é o nível de qualidade do projeto. Restrição: Adversários não podem escolher módulo protegido por carta de conceito do jogador da vez.

Adversários desviram artefatos escolhidos.

Adversários verificam artefatos desvirados.

Se artefatos verificados forem livres de defeito, então jogador da vez ganha o jogo.  

Se artefatos verificados forem defeituosos, então jogador da vez pode corrigir um por turno de jogo.  

______________________________   

Título: Constrói artefato  

Objetivo: Descrever as regras da construção de artefatos.  

Contexto: Cartão do projeto no centro da mesa.

Atores: jogador da vez

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador da vez, para cada carta de engenheiro de software, compra do monte de artefatos. Restrição: A quantidade de artefatos depende da habilidade do engenheiro de software, do tipo do artefato escolhido e da complexidade do projeto.

Se jogador da vez compra carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade do engenheiro de software. Restrição: Cartas brancas custam valor da complexidade do projeto.

Se o jogador da vez compra carta cinza, então o número de cartas é determinado pela metade da complexidade do projeto e pela habilidade do engenheiro de software. Restrição: Cartas cinzas custam metade do valor da complexidade do projeto.

Jogador da vez coloca as cartas compradas no tabuleiro de acordo com o engenheiro de software e de acordo com o tipo de artefato produzido. 

______________________________  

Título: Inspeciona artefato

Objetivo: Descrever as regras da inspeção de artefatos.

Contexto: Cartão do projeto no centro da mesa.

Jogador da vez tem artefatos no tabuleiro.

Atores: jogador da vez

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador da vez escolhe artefato do tabuleiro.

Se o engenheiro de software responsável pelo artefato faz a inspeção, então o mesmo gasta um ponto de tempo.

Se outro engenheiro de software faz a inspeção, então esse gasta dois pontos de tempo.

Artefato inspecionado é desvirado no tabuleiro.   

______________________________   

Título: Corrige artefato

Objetivo: Descrever as regras da correção de artefatos.

Contexto: Cartão do projeto no centro da mesa.

Jogador da vez tem artefatos inspecionados com defeito (INSPECIONA ARTEFATO) no tabuleiro.

Atores: jogador da vez

Recursos: cartas, cartão do projeto, tabuleiro.  

Episódios:
Jogador da vez escolhe artefato com defeito do tabuleiro.

Se o engenheiro de software responsável pelo artefato faz a correção, então o mesmo gasta um ponto de tempo.

Se outro engenheiro de software faz a correção, então esse gasta dois pontos de tempo.

Artefato inspecionado é substituído por artefato da mesma cor comprado do monte de artefatos.    

______________________________  

Título: Integra artefatos em um módulo

Objetivo: Descrever as regras da integração de artefatos.

Contexto: Cartão do projeto no centro da mesa.

Jogador da vez tem artefatos no tabuleiro.

Atores: jogador da vez

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador da vez escolhe módulo do projeto.

Jogador da vez seleciona artefatos do tabuleiro, independente do responsável (engenheiro de software) de acordo com o cartão do projeto.

Jogador da vez integra o módulo juntando as cartas em um monte fora do tabuleiro.  

Um dia de Jogo SimulES…

Evoluímos o Jogo SimulES, reestruturamos as regras, montamos os cenários baseados nas novas regras e precisávamos testar. Decidimos então convidar alguns alunos como voluntários para jogar e nos dar um feedback sobre essa nova versão do SimulES.

Conseguimos agendar para quarta-feira, dia 13 de junho, dois horários e dois grupos de voluntários. Ambos os grupos de 4 alunos. O primeiro grupo foi composto de dois alunos de graduação (Daniel e Otávio), um aluno de mestrado (Eduardo) e um aluno de doutorado (Pádua). O segundo grupo foi composto de 4 alunos de graduação (Gisele, Bruno, Bianca e Dias). Todos os voluntários são alunos do Departamento de Informática da própria Puc-Rio.

Foram montados dois pacotes com o material necessário para entender o ambiente e as regras do jogo. O primeiro pacote foi destinado ao grupo 1. Esse pacote continha os cenários e uma documentação complementar que descreve o ambiente do jogo. Já o segundo pacote foi destinado ao grupo 2. Esse pacote continha os cenários e parte do léxico do SimulES. A idéia era analisar o desempenho dos jogadores dado que um pacote os mesmos teriam uma documentação complementar além dos Cenários e o outro teriam que entender o léxico e os Cenários. A comparação nos permitiria saber se realmente o léxico e os cenários estavam representando bem as regras e o ambiente do jogo. A seguir apresento um resumo dessa experiência:

• Grupo 1: o jogo começou no horário previsto, às 16:00 horas. Infelizmente, somente o aluno Eduardo leu o pacote com o material do jogo. Isso já nos decepcionou um pouco, pois todas as comparações que gostaríamos de tirar em virtude dos pacotes montados não foram possíveis. De qualquer forma, começamos o jogo. No começo foi um pouquinho conturbado, pois o grupo não sabia direito quais eram as regras, não entenderam direito quando deveriam agir e quando deveriam atacar. Mas contornamos essa situação, principalmente, porque o aluno Maurício ficou mediando e tirando as dúvidas que foram surgindo. O jogo embalou e parecia que os alunos estavam curtindo jogar. Alguns integraram módulos e quase conseguiram submeter o produto. Um fato curioso é que os participantes não quiseram inspecionar os artefatos. Segundo o grupo, a inspeção era muito cara e não compensa. Mas ela custa 1 e não tem como ser reduzido esse custo!!! Acredito que eles tiveram essa impressão, pois os problemas aplicados penalizavam muito a inspeção e isso a encareceu ao longo do jogo. Passado um tempo de jogo, mais ou menos uma hora, percebemos que lentamente o mesmo ficou mais parado, os jogadores estavam sem atitude e notamos que isso ocorreu, principalmente, devido à quantidade de cartas de problemas que eram lançadas a cada fase de tratamento de problemas. Basicamente tivemos essa confirmação quando perguntamos para os jogadores o que eles acharam do jogo. Sem exceção, TODOS responderam que o jogo é monótono, se arrasta e isso se deve ao fato de existirem muitas cartas de problemas e poucas cartas de conceito. Enfim, o jogo não terminou, pois ninguém conseguiu submeter o produto e o horário do outro grupo havia sido invadido. Ao final, solicitamos ainda que os voluntários escrevessem anonimamente sobre o que acharam do jogo e apontassem sugestões de melhorias. 
• Grupo 2: o jogo não foi realizado da forma como havíamos planejado uma vez que três dos quatro alunos voluntários não compareceram. Apenas a aluna Gisele estava presente. Foi quando decidimos jogar com ela para ela conhecer o jogo e nos dar um feedback posteriormente. O Maurício, o Filipe e eu jogamos com a Gisele. Como ela também não havia lido o material com as regras, explicamos rapidamente como jogar e começamos na prática. Foi bem mais tranqüilo mesmo porque, nós sabíamos as regras e por isso o jogo ficou dinâmico e divertido. Uma modificação que aplicamos foi à redução da quantidade de cartas de problemas que cada adversário poderia receber dos outros. Estabeleceu-se, nesse sentido, uma única carta de problema aplicada pelo jogador da vez por rodada. Isso é, uma vez que um adversário recebia uma carta de problema, nenhum outro jogador da vez podia aplicar outra carta de problema nesse adversário. Essa prática reduziu bastante o número de problemas aplicados por rodada e isso permitiu tornar o jogo mais dinâmico. Pelo menos a Gisele aparentemente apreciou o jogo e o elogiou. Infelizmente, foi um jogo rápido, pois a aluna tinha aula e não conseguimos terminar o jogo submetendo o produto. Mesmo assim, solicitamos à aluna um feedback escrito para usarmos como parâmetro em relação ao grupo 1.  

*** Pontos Fracos: ***

Notei que o fato dos alunos não terem lido o material complicou um pouco e comprometeu o andamento do jogo. Isso foi sentido, principalmente, no primeiro grupo. Mesmo assim, o aluno Eduardo que havia lido o material estava visivelmente mais seguro, mais motivado e jogou bem consciente. Perguntei para ele se foi bom ter lido o material previamente e ele respondeu que sim, pois facilitou entender as rodadas, as regras e não estranhar tanto o ambiente. Acho que esse foi um feedback valioso!!!!!

Outro ponto que observei foi à falta de interesse dos alunos em inspecionar os artefatos. Mas acredito que isso ocorreu muito mais devido a uma particularidade da partida jogada pelo grupo 1, onde muitos problemas foram aplicados e coincidentemente a grande maioria deles penalizava principalmente a inspeção. Isso desestimulou muito os jogadores na ação de inspecionar.

A reclamação geral dos voluntários foi com a quantidade de problemas aplicados e com a falta de conceitos para minimizar os efeitos desses problemas. Essa mesma sensação já havíamos percebido desde a primeira vez que jogamos o SimulES. Sempre defendi que essa proporção de cartas de problemas e cartas de conceito deveria ser revista. Infelizmente, não a alteramos e acho que isso também prejudicou sensivelmente o sucesso dessa experiência com jogadores voluntários. Um re-balanceamento entre essas cartas seria bem-vindo!

Percebi que algumas cartas de conceito precisam ser revisadas, pois estão usando palavras que não fazem mais parte do léxico do jogo, como é o caso da palavra “validação” que agora pode ser entendida como “submissão” e posterior “verificação”.

Outra sugestão é que muitas vezes, principalmente no começo do jogo, algumas cartas solicitam (penalizam) a escolha e o descarte de x artefatos, sendo que muitas vezes o adversário não possui x artefatos. Então acho que isso poderia ser revisado e modificado colocando “até x artefatos”. Ajudaria bastante e evitaria muitas dúvidas.

Uma observação levantada pelo Professor Julio foi o fato de existirem cartas com porcentagem. Não é muito prático e dificulta o andamento do jogo. Seria pertinente revisar isso também.

Acredito que uma breve explicação aos participantes, antes de começar o jogo seria bastante pertinente. Ajudaria a tirar dúvidas e a fluir melhor o jogo posteriormente. Uma espécie de “aula” com uma exposição rápida das regras e uma descrição breve do ambiente do jogo.

Um ponto comentado pelos participantes e observado por todos consistiu no fato da falta de praticidade, na hora do jogo, dessa divisão entre a rodada de ações, rodada de conceitos e tratamento de problema. Os jogadores se perdiam, não sabiam em que rodada estavam e de quem era a vez. Mas ainda acho que isso se deu devido ao fato dos participantes desconhecerem as regras. Acredito que uma vez que as regras forem aprendidas, esse problema se minimizará. Fica aqui a minha esperança. Mesmo assim, vale comentar que pensamos em modificar essa divisão de forma a não deixá-la tão rígida. Isso acarretaria em uma reestruturação dos cenários e não sei se teríamos tempo hábil para esse feito. O que acham?

*** Pontos Fortes: ***

Realmente foi perceptível que a leitura do material com as regras facilitou muito na hora de jogar, uma vez que o jogador mais consciente foi o Eduardo e ele havia lido o documento. Ele investiu menos em cartas cinza que os outros jogadores, pois sabia que a proporção de bugs era menor entre elas. Soube utilizar bem as cartas de conceito para incrementar a habilidade do seu engenheiro. Foi um dos únicos que distribuiu os artefatos entre os tipos permitidos: requisitos, desenho, código, rastro e ajuda. Não se confundiu na hora de aplicar os problemas, sabia onde era especificada a condição e qual efeito isso acarretaria ao adversário. Integrou um módulo, dentre outras atitudes.

As cartas de problema NÃO foram motivos de muitas dúvidas, os participantes rapidamente pegaram o jeito e não sentiram dificuldade em interpretá-las. Isso é motivo de orgulho para o nosso grupo, pois significa que nossas mudanças surtiram efeito. A evolução dessas cartas foi bem pertinente para o jogo. Parabéns a todos!

Começar com um engenheiro de software também foi uma boa prática. Todos já se sentiam capazes de produzir artefatos, de jogar, pois já tinham um engenheiro na equipe desde o começo do jogo. Valeu pela sugestão Maurício!

Mesmo com todos os contratempos, o jogo surtiu efeito. Os participantes estavam felizes, motivados na hora de aplicar problemas, chateados quando não conseguiam integrar um módulo ou quando perdiam artefatos, dentre outras emoções. Essas emoções fazem parte de um ótimo jogo e acho que alcançamos isso com o jogo SimulES.

Valeu equipe!!!

Acredito que fomos vitoriosos em muitos aspectos!!!

PS: Professor Julio, obrigada pelo lanchinho!!! Estava perfeito!