terça-feira, 12 de novembro de 2013

segunda-feira, 11 de novembro de 2013

G8 Games

Ata da 10ª Reunião - 11/11

Membros:
Antônio Leite
Bruno Liberal
Rafael Fonseca
Vinícius Garcia
Vitor Paisante



- Objetivos da reunião: 5º Sprint Review

5º 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:

  1. Colocar sons e Músicas. 5 pontos

    Foram utilizadas músicas de domínio público do artista Brian Boyko para a trilha sonora do jogo.

  1. Refinar Interface Gráfica. 8 pontos
    Um novo visual para o título foi criado e novos itens foram adicionados à interface gráfica.

  1. Adicionar textos de crédito e como jogar. 3 pontos

Foram criados textos de como jogar e créditos na área adequada.

  1. Evidenciar detalhes do processo. 20 pontos

Todos os casos que estavam no Task Board foram passados para o google drive para que pudessem ser vistos pelo product owner e pode ser encontrada aqui.

  1. Interface geral com poucas animações, contendo tabelas de funcionários contratados e projetos em progresso.8 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.

  1. Criar tela de fim de jogo. Venceu ou GameOver. 13 pontos
   
Foram criadas estas tela indicando o fim do jogo. Cada uma possui um tema adequado à mensagem que querem passar.

  1. Criação de 25 testes de unidade. 13 pontos

    Fazer os testes foi uma tarefa difícil. Tentamos fazer os testes de maneira mais abrangente possível, e designamos dois integrantes da equipe para faze-lo, devido sua dificuldade.


  1. Fazer gerador de funcionários automático. 13 pontos

    Foi criado um gerador de funcionários automático em C# que pega dados de um arquivo. O objetivo é manter a diversidade dos funcionários.

  1. Fazer gerador de projetos automático. 13 pontos

Foi criado um gerador de projetos automático em C# que pega dados de um arquivo. O objetivo é manter a diversidade dos funcionários.

  1. Fazer testes da versão alfa já funcional. 20 pontos
   
Todos bugs encontrados foram relatados no BugTracker que pode ser encontrado aqui, e corrigidos.

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


Total de pontos planejados: 116
Total de pontos feitos: 116

Impedimentos:

- Encontrar sons que não tivessem copyright.
    Solução: Ir em um site que tivesse apenas músicas com domínio público.
- Fazer com que os testes fossem mais abrangentes.
    Solução: Designamos mais um integrante para tal tarefa.

quinta-feira, 7 de novembro de 2013


 
G8 Games
Ata da 9ª Reunião - 31/10

Membros:
Antônio Leite
Bruno Liberal
Rafael Fonseca
Vinícius Garcia



- Objetivos da reunião: Evidenciar o Sprint Planning;


Nosso sprint  plannig é divido em duas etapas, pois como nosso cliente não está presente na reunião, nós fazemos o selected backlog e mandamos para ele, que decide se está dentro do desejado e nos retorna. O selected backlo abaixo foi aprovado pelo cliente, e tornou-se o nosso sprintl planning:

1 - Rodar uma partida completa do jogo - Caso épico, dividido nos casos (2-6) abaixo:

2 - Colocar sons e musicas - 5 pontos
3 - Refinar interface gráfica. - 8
4 - Adicionar textos de créditos e como jogar. - 3
5 - Evidenciar detalhes da implementação do processo - 20
6 - Criar tela de fim de jogo. Venceu ou GameOver. - 13
7 - Criação de 25 testes de unidade - 13
8 - Fazer testes da versão alfa do jogo, já funcional. - 20


Quando jogamos o jogo cadastramos todos os bugs e observações no google docs, e pode ser encontrado aqui:

Bug Tracker:
https://docs.google.com/spreadsheet/ccc?key=0AlSic6iZbQWpdDVkSWIxUFBpME03d041a1lRb0REbFE&usp=drive_web#gid=0

Além disso faremos uma adição de dados descrição de funcionários para deixar o jogo mais rico.



Até o momento já foram feitos alterações no desgn do jogo, em particular a criação do título do jogo, que pode ser encontrado aqui:

https://drive.google.com/#folders/0B1Sic6iZbQWpai15ZFVkUkVsZ0U

Outro avanço a a transcrição das histórias de usuário do TaskBorad online utilizado, SeeNowDoo, para o docs para ser melhor evidenciado. Elas podem ser encontradas aqui:

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




terça-feira, 5 de novembro de 2013

CONSULTA URGENTE!!!

Pessoal, não sei se sabem, mas eu estou me transferindo para a Universidade Federal  Fluminense no RJ, fui aprovado no concurso para Prof. Adjunto. Em virtude disto minha agenda ficou um pouco bagunçada.

Eu precisaria estar dia 14 em Porto Alegre.

Seria factível vocês apresentarem e entregarem o TP na terça, dia 12/11?

Por favor, comentem se eh possível ou não.

[]s
Sergio Crespo


domingo, 3 de novembro de 2013

EE Games - Ata da reunião do dia 31/11/2013

Após o seminário, foi realizada uma reunião para consolidar os requisitos que serão atendidos no último release do nosso jogo, SoftClick. Decidimos que manteremos os requisitos sugeridos na apresentação, sendo estes:
  • Tutorial do jogo
  • Programação das fases restantes
  • Botão de pause
As atividades foram colocadas na planilha do kanban e serão desenvolvidas ao longo destas duas semanas que precedem a apresentação, marcada para dia 14 de novembro.


quinta-feira, 31 de outubro de 2013

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:

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

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

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

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


terça-feira, 29 de outubro de 2013

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. 

sexta-feira, 25 de outubro de 2013

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.

quinta-feira, 24 de outubro de 2013

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


quarta-feira, 23 de outubro de 2013

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:



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

terça-feira, 22 de outubro de 2013


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

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

  1. Desenhar testes (TDD). 13

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