G8Games

G8 Games

Ata da 9ª Reunião - 31/10

Membros:

Antônio Leite

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

- Objetivos da reunião: 4º Sprint Review e último Sprint Planning

4º Sprint Review:

No Sprint Review é feita uma revisão do que foi feito durante a interação, em relação ao produto e em relação ao processo e é apresentado para o cliente. Também é relatados os impedimentos do processo e em relação a equipe.

Para esse Sprint conseguimos fazer tudo que foi feito e identificamos alguns detalhes que tem que ser mudados no processo.

Casos Feitos no Sprint Review:

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

Foi mandado um e-mail para o cliente para que ele nos passe sua conta no dropbox, para adicionarmos ele no processo.

Vemos uma imagem dos “commits” do repositório usado:

2. Criar controle de reputação do jogador, dinheiro e salário. 13 pontos

Foram criadas métods dentro das classes do jogo para fazer os controles. Na imagem a seguir vemos um pedaço do diagrama de classes UML com os métodos citados:

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

3. Criar gerenciamento e alocação de tarefas. 13 pontos

Foram criadas classes Tarefa e uma lista de tarefas no projeto. Mais detalhes pode ser encontrado no repositório de código e/ou no diagrama de classe já apresentado.

4. Desenhar, executar e explicitar os testes desenhados. 13 pontos

Foi criado um projeto para fazer os testes de unidade do jogo. Os primeiros testes feitos podem ser mostrados acima. Para acesso ao código completo é só acessar o repositório ou pedir a um dos integrantes.

5. Terminar as telas da Interface e os objetos interativos da interface 13 pontos

Terminamos as interfaces do jogo e adicionamos poucas telas que faltavam. Agora pode ser visualizado mais dados do jogo, como funcionários, dinheiro e dados do projeto.

6. Integrar dados levantados ao jogo e Rodar dois turnos do jogo com dados reais. 13 pontos

O novo protótipo do jogo está disponivel para download no repositório.

Dentre os casos relatados o caso 5 foi adicionado durante a interação do sprint após uma reunião com o grupo. Notifamos o product owner dessa alteração e registramos ela no blog, e no Produck Backlog disponíveis para quem quiser aqui.

Total de pontos planejados: 96

Total de pontos feitos: 119

Impedimentos:

- Aprendizado do git

Solução: Pedimos ao integrante mais experiente do grupo para fazer um tutorial.

- Aprendizado dos testes de unidade

Solução: Seguimos tutorias que podem ser vistos aqui.

- Familiariação com o C#

Solução: A solução foi estudada.

- Adição de tarefas no Sprint não planejadas

Solução: Passamos mais tempo do que o planejado fazendo os casos.

- Comunicação

Solução: Será colocado na ata das reuniões somente o nome dos integrantes que participaram.

6º e Último Sprint Planning:

Sprint Planning é o planejamento do próximo Sprint. Nele é montado o Selected Backlog a partir do Product Backlog. O Product Backlog é uma lista que contém todos os possíveis casos de serem feitos no software, e nele tanto a equipe quanto o cliente pode adicionar casos. Ele pode ser encontrado aqui.

Já o Selected Backlog é um grupo de casos direcionados para um dos espaços do software, por exemplo melhora de uma funcionalidade. A partir do Selected Backlog a equipe escolhe quais destes casos podem serão feitos no Sprint, pois eles tem mais noção do tempo gasto para as coisas serem feitas.

Como nossa comunicação com o cliente não é completamente fluída, para facilitar, nós montamos o Selected Backlog e enviamos para o Sergio para ele verificar se está de acordo com seu desejo. Caso precise, faremos os ajustes.

Selected Backlog:

Colocar som

Refinar interface gráfica

Adicionar textos de créditos e como jogar.

Rodar uma partida completa do jogo

Evidenciar detalhes da implementação do processo

Interface geral com poucas animações, contendo tabelas de funcionários contratados e projetos em progresso.

Criar tela de fim de jogo. Venceu ou GameOver.

Criação de 25 testes de unidade

Fazer um gerador de Funcionários automático.

Fazer um gerador de Projetos automático.

Fazer testes da versão alfa do jogo, já funcional.

Após o aceite do cliente será feita o Poker Planning. Nesta etapa será feita a votação de quantos pontos cada um dos casos tem e quais deles estão dentro do possível de ser feito em 2 semanas. Nesta etapa apenas a equipe vota.

G8Games

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante

Na ultima quinta começamos o desenvolvimento das classes, e hoje demos uma caminhada boa nesta área. As classes fazem parte da inteligência do jogo, e ao terminadas serão integradas as telas. O jogo já está funcionando corretamente com um sistema de versão, o Git. Os arquivos são armazenados em um servidor central no DropBox. Amanhã iremos termiar as classes e integrar-las com as telas.

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.

Ata da 6ª Reunião - 17/10

Membros:

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante

- Objetivos da reunião: 3º Sprint Review e 4º Sprint Planning

3º Sprint Review:

No Sprint Review é feita uma revisão do que foi feito durante a interação, em relação ao produto e em relação ao processo e é apresentado para o cliente. Também é relatados os impedimentos do processo e em relação a equipe.

Para esse Sprint conseguimos fazer tudo que foi feito e identificamos alguns detalhes que tem que ser mudados no processo.

Casos Feitos no Sprint Review:

1. Fazer um protótipo apresentável para o cliente. 20 pontos

O design visual do jogo foi completamente estabelecido. Neste novo build, é possível visualizar como os turnos progridem e ver as telas principais do jogo. A lógica em sí, não está neste build, pois exigia ainda outras informações desenvolvidas concomitantemente. Para a proxima build, pretendemos implementar a lógica do jogo e as telas que faltam.

Pode ser acessado aqui: https://www.dropbox.com/sh/yg4ayw6q8xtxdyf/12u5LTTtrt

2. Fazer o relacionamento de tarefas a se fazer no projeto e os cargos dos funcionários.  13 Pontos
3. Fazer o relacionamento dos bônus das tarefas para as outras tarefas.  13 pontos.

As tarefas 2 e 3 podem ser acessadas aqui:

https://docs.google.com/spreadsheet/ccc?key=0AlSic6iZbQWpdEJKWnpzVVYybzZkdW5xMlhic0dTNUE&usp=drive_web

4. Criar 10 funcionários exemplos para os primeiros testes - 8 pontos.
5. Criar 5 projetos exemplo para os primeiros testes - 8 pontos.

https://docs.google.com/spreadsheet/ccc?key=0As6gwZs8ta4GdFA3cjVlRnd5cmp6N2xOandEUlBreWc&usp=drive_web#gid=2

Também foram feitos três casos que foram necessários durante a iteração. O Professor relatou que o trabalho podia ficar grande de mais, e por isso dedicamos um tempo em simplificar os dados.

Os casos são os seguintes:

1. Fazer a simplificação das tarefas classes 1 e 2 Praxis. 3 Pontos.
2. Fazer a simplificação das tarefas classes 3 e 4 Praxis. 3 Pontos.
3. Fazer a simplificação das tarefas classes 5 e 6 Praxis. 3 Pontos.

Total de pontos feitos:    71.

Total pontos projetados: 62.

Impedimentos:

- Falta de comunicação na especificação jogo, tivemos pontos de divergência entre a equipe do Scrum.

Solução: Entramos em contato com o cliente/professor Sergio Crespo que sanou nossas dúvidas.

    - Integrantes não compareceram em reuniões;

Solução: Será colocado o nome apenas dos membros presentes nas atas das reuniões.

    - Integrante que conhece o Unity, estava ficando sobrecarregado, pois o framework é complicado e não trivial.

Solução: Ele criará as classes abstratas/interfaces e a implementação dessas será dividido com o grupo.

Problema no Processo

- Reunição semanal nem sempre ocorre:

Solução: Reuniões de curto intervalo de tempo após a aula, será equivalente ao Daily Scrum; E usaremos para marcar a reunião semanal.

- Não está sendo mostrado muita coisa relativa ao processo ao cliente:

Solução: Será feita ata de toda a reunição e será postada no Blog. Os passos do processo serão mostrados claramente;

4º Sprint Planning:

Sprint Planning é o planejamento do próximo Sprint. Nele é motado o Selected Backlog a partir do Product Backlog. O Product Backlog é uma lista que contém todos os possíveis casos de serem feitos no software, e nele tanto a equipe quanto o cliente podem adicionar casos. Ele pode ser encontrado aqui.

Já o Selected Backlog é um grupo de casos direcionados para um dos espaços do software, por exemplo melhora de uma funcionalidade. A partir do Selected Backlog a equipe escolhe quais destes casos podem serão feitos no Sprint, pois eles tem mais noção do tempo gasto para as coisas serem feitas.

Como nossa comunicação com o cliente não é completamente fluída, para facilitar, nós montamos o Selected Backlog e enviamos para o Sergio para ele verificar se está de acordo com seu desejo. Caso precise, faremos os ajustes.

Selected Backlog:

Integrar a programação ao GitHub.

Rodar dois turnos do jogo com dados reais.

Criar controle de reputação do jogador.

Criar controle do dinheiro.

Criar controle do salário.

Criar gerenciamento e alocação de tarefas.

Desenhar testes (TDD)

Integrar dados levantados ao jogo

Executar e explicitar os testes desenhados

Refinar interface gráfica

Colocar mensagens para o usuário, Instruções de Uso.

Rodar uma partida do jogo.

Criar interfaces que serão responsáveis pela implementação baixo nível do jogo.

Após o aceite do cliente será feita o Poker Planning. Nesta etapa será feita a votação de quantos pontos cada um dos casos tem e quais deles estão dentro do possível de ser feito em 2 semanas. Nesta etapa apenas a equipe vota.