20th Booth Games

Datada uma auditoria de processo pela coordenação do projeto para amanhã, dia 30 de Outubro de 2013. 

Até o momento o processo segue conforme configurado e documentado em Kanban. A fase de implementação segue em desenvolvimento. Não houveram alterações nos requisitos, os quais serão reescritos abaixo:

Requisitos Não-Funcionais:
- Requisitos definidos no enunciado do trabalho, no qual consta a utilização do Blog para evidenciar a evolução do processo, bem como utilizações de ferramentas para gestão de versões e configuração. 

Requisitos Funcionais:

- Requisitos desenvolvidos para a confecção do desenho do projeto, apresentados em seminário, os quais constam:
1) Interface tipo Visual Novel

2) Sprites estáticos para cada cenário de jogo

3) Bots NPCs estáticos para cada circunstância de jogo

4) Sequência estruturada via script de perguntas e respostas relacionadas ao CMMI

Como dito anteriormente, requisitos adicionais foram julgados como desnecessários, dada a liberdade conferida aos desenvolvedores pelo enunciado do projeto. Os requisitos estão sendo atendidos sem dificuldades e são suficientes para o desenvolvimento satisfatório do projeto, levando-se em conta a qualidade do desenvolvimento e atendimento aos prazos. 

G8Games

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante

        Em conversa com o grupo o integrante Vitor Paisante reassaltou que ainda há muito o que ser feito em relação as interfaces gráficas. E por isso iria se dedicar exclusivamente a isso. Como ele é o único integrante com conhecimento da interface Unity, acreditamos em seu julgamento. Pedimos a ele para que o que está sendo feito seja postado no Blog e no nosso Produck Backlog, como qualquer outro caso que estamos fazendo.

EE Games - Ata da reunião do dia 22/10/2013

Assim como foi especificado no seminário virtual, foi realizada uma reunião no dia 22/10/2013. Nesta reunião, realizamos o acompanhamento do projeto. Algumas características atuais do jogo foram questionadas, como a mudança de fase, que atualmente ocorre quando o tempo atinge 60 segundos, independente da pontuação. Ficou definido que tentaremos implementar uma nova lógica para aumentar a dificuldade, que é a seguinte: o jogador deve ter uma pontuação mínima ao fim de 60 segundos para conseguir mudar de fase, caso contrário o jogo termina. Assim, estabelecemos um compromisso entre a pontuação e o tempo ao passar de fase.
Além disso, a tela de "Settings" também foi questionada, e por ser um jogo simples, ficou definido que ela provavelmente será substituída por uma tela de "Tutorial", que ensina o jogador como o jogo funciona.
Também foi detectado nos testes que, ao passar de uma fase para outra, as vidas e a pontuação são resetadas. É necessário corrigir este problema.

É interessante também evidenciar outras características do processo utilizado:

• A gestão de configurações está sendo realizada através do uso de um repositório de versões, ao qual todos os membros têm acesso. Além disso, foi criada uma planilha que evidencia as características implementadas por cada pessoa, bem como testes sugeridos e realizados para aquelas implementações. Link: https://docs.google.com/spreadsheet/ccc?key=0AsbvJsunXSrndF9Eb0llM3dBSlNYUDFPcVRkWk5JTVE&usp=drive_web#gid=0
• Uso do Kanban para especificar e mostrar o andamento de tarefas de cada pessoa. Link do e-kanban: https://docs.google.com/spreadsheet/ccc?key=0AsbvJsunXSrndF9Eb0llM3dBSlNYUDFPcVRkWk5JTVE&usp=drive_web#gid=0
• Criação de uma terceira planilha, que mostra as frases implementadas no objeto bônus para cada fase, se a frase é verdadeira ou falsa e explicações para frases falsas. A planilha está em processo de montagem pelos membros do grupo, mas pode ser acessada em : https://docs.google.com/spreadsheet/ccc?key=0Ap_ZcwwDTFxydEtTYTg5dGRRTjNSd1pfSHIydHZUWEE&usp=sharing#gid=0
• O planejamento de projeto continuou sendo realizado, assim como nas outras reuniões. Outras características que devem ser implementadas são:

• Botão para zerar o ranking;
• Salvar uma sigla para o jogador no ranking;
• Botão para pausar o jogo;
• Explicar as respostas falsas das questões apresentadas no objeto bônus;
• Fazer as fases que faltam.

As especificações do planejamento do projeto começarão a ser implementadas para o próximo release e deverão estar prontas até a entrega do release final.

G8Games

Ata da 8ª Reunião - 23/10

Membros Presentes:

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

- Objetivos da reunião: Desenvolvimento do código, teste e protótipo.

Começamos a desenvolver as classes e seus métodos. Uma breve versão do código está em: http://pastebin.com/0PL9EPvz, pois na verdade usamos a ferramenta GitHub para construção do projeto.

Diagrama base:

versão ampliada: https://docs.google.com/file/d/0B1Sic6iZbQWpcXZsQ0pZZDJPT0E/edit?usp=drive_web

Nesta reunião entendemos um pouco do código e iremos separá-los para que sejam feitos paralelamente pelos integrantes.

G8Games

Ata da 7ª Reunião - 22/10

Membros:

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante

- Objetivos da reunião: Definie os casos a serem feitos a partir do selected backlog e pontuá-los através do Poker planning.

Foi passado o selected backlog (Lista com os casos mais guiados) para o Product Owner para a aprovação, que nos mandou a lista com as tarefas:

Casos do 4º Sprint:

1. Integrar a programação ao GitHub. 5

2. Rodar dois turnos do jogo com dados reais. Épico (Passa dos 20 pontos). Então foi dividido nos sub-casos:

1. Criar controle de reputação do jogador. 13
2. Criar controle do dinheiro. 13
3. Criar controle do salário. 13
4. Criar gerenciamento e alocação de tarefas. 13
5. Integrar dados levantados ao jogo. 13

3. Desenhar testes (TDD). 13

4. Executar e explicitar os testes desenhados. 13

Total: 96 pontos.

Cada caso está relacionado com uma história de usuário. Essa história captura o que o cliente faz ou precisa em relação ao que está sendo feito.

Abaixo mostrarei as histórias de usuários do Sprint atual:

1 - Correspondente ao 1º caso: O cliente gostaria de saber que as configurações do projeto estão sendo devidamente tratadas e com isso dar mais credibilidade ao projeto.

2 - Correspondente aos casos 2.a, 2.b, 2.c, 2.d: O cliente quer saber como será feito o controle de financeiro do jogador, reputação do jogador e alocação de tarefas. Nesta etapa serão criados controle de salário do funcionário e controle de dinheiro do jogador. Também serão estabelecidos os controles de reputação e gerenciamento de alocação de tarefas aos funcionários.

3 - Correspondente ao caso 2.e: O cliente quer ver os dados levantados nos sprint’s passados integrados ao jogo.

4 - Correspondente aos casos 3 e 4: O cliente que saber como e quais testes estão sendo feitos no sistema.

   

As tarefas juntamente com cada história de usuário correspondente podem ser vistos aqui, no task board usado. O task boar é onde todas as tarefas ficam de maneira fácil de serem vistas pela equipe. Escolhemos o site SeeNowDo que fornece um taskboard online e visual. Para mais detalhes pode ser pedido para qualquer integrante do grupo para logar com sua conta e mostra-las.

Ficou decidido que estabeleceremos as classes, métodos e variáveis para serem passados para toda a equipe, que em seguida dividirá o trabalho entre os membros em implementação e testes. Estudaremos mais sobre a execução de testes de unidade e o desenvolvimento dirigido por testes no ambiente em que estamos desenvolvendo e as ferramentas para aplicá-las. No final do sprint um protótipo funcional será disponibilizado para o cliente.

O Mínimo esperado no TP da Disciplina de ES

Estes 5 itens devem estar bem evidenciados por todos os grupos!

(1) Para Ver e Refletir http://www.youtube.com/watch?v=pmRXVVLWa-g

(2) Gerenciamento de Requisitos
O propósito desta área é estabelecer a gestão dos requisitos do projeto e seus produtos de trabalho. Esta área permite identificar inconsistências os requisitos e produtos de trabalho

(3) Planejamento de Projetos
O propósito de Planejamento de Projetos é estabelecer e manter planos para as atividades inerentes ao projeto

(4) Acompanhamento de Projetos
O propósito desta área é prover informações suficientes para o gerenciamento eficaz do projeto. Sempre que o desempenho sair dos limites especificados, ações corretivas devem ser tomadas a fim de colocar o projeto de volta aos limites definidos.

(5) Gerência de Configuração
O Propósito da Gerência de Configuração é estabelecer e manter a integridade dos produtos de trabalho. Para auxiliar os trabalhos, recomenda-se a utilização de uma ferramenta. Para suporte ao processo, auditorias devem ser realizadas a fim de verificar se a gerência de configuração esta sendo realizada de acordo com o especificado.

EE Games - Seminário Virtual - Soft Click 3.0

Está disponível no link https://www.dropbox.com/s/nmzbmufkz1ut8n1/EEgames-Release.exe , o terceiro release do nosso jogo, SoftClick, com mais algumas funcionalidades e nova aparência gráfica! 

Todos os requisitos planejados para essa versão, levantados na última reunião (http://esrrsc.blogspot.com.br/2013/10/eegames-reuniao-do-dia-08102013.html), foram cumpridos e compõem o novo release. Os testes, no entanto, revelaram alguns "bugs" não desejáveis, e as suas soluções devem ter prioridade nas tarefas para o próximo release. Os requisitos atendidos foram : 

 

1) Ranking de scores : as pontuações dos usuários são adicionadas permanentemente a um ranking, acessível por meio do menu "Statistics";

2) Nova figura para representar o símbolo para exibição de uma frase contextualizada (joguem e vejam);

3) Extraídas frases para os capítulos 4,5 e 7 : As frases do capítulo 4 já foram adicionadas ao jogo;

4) Criou-se um logo para o nome do jogo, que aparece no menu inicial, e foram realizadas mudanças gráficas, como novos planos de fundo.

5) Estrutura de fases : cada fase corresponde a um capítulo do livro, e as frases e palavras são contextualizadas a eles.

Novidades no processo : 

- As frases do jogo foram colocadas em gestão de configurações (https://docs.google.com/spreadsheet/ccc?key=0Ap_ZcwwDTFxydEtTYTg5dGRRTjNSd1pfSHIydHZUWEE&usp=drive_web#gid=0). Como elas são um aspecto importante do jogo, é importante que seja possível rastreá-las, de forma a saber quais frases pertencem a quais fases, qual a resposta correta e, no caso de ser falsa, a justificativa para tal. As palavras contextualizadas devem ser o próximo item a entrar na gestão.

- Uma vez que o Kambam possui tarefas gerais (entre elas tarefas que não são visíveis aos usuários do jogo, mas apenas à equipe), achamos que seria interessante criar uma planilha (https://docs.google.com/spreadsheet/ccc?key=0AsbvJsunXSrndF9Eb0llM3dBSlNYUDFPcVRkWk5JTVE&usp=drive_web#gid=0) para listar novas funcionalidades percebidas pelos jogadores com uma sugestão de teste dada pelo desenvolvedor, os testes realmente executados, e o resultado desses testes. Assim fica mais fácil rastrear os testes de cada nova funcionalidade, o que permite realizá-los novamente e detectar potenciais bugs. Além disso, é mais fácil rastrear as funcionalidades que compõem cada release.

Próximos passos:

-Será realizada uma reunião no dia 22/10 para definirmos as tarefas para o próximo release, e discutirmos sobre o processo utilizado.