Orientações da Terceira Apresentação

Amanhã teremos a terceira apresentação do trabalho, dessa forma:

• esperamos que seja apresentada uma versão funcional do jogo e
• deve-se discutir o quanto a versão atual está distante da versão que foi proposta no início do trabalho e o que será feito até a entrega final.

Além disso, os seguintes pontos também devem ser discutidos:

Processo:

- Requisitos (cerca de 20% da nota): definir os requisitos do produto e da iteração, assim como o está pronto.

- Projeto (cerca de 20% da nota): evidências de projeto no nível 2 de maturidade do cmmi.

- Outros (cerca de 20% da nota):
    - Organização do grupo: para cada aluno, qual foi seu papel/contribuição na iteração.
    - Decisões da iteração: decisões de implementação, decisões relativas ao processo.
    - Desafios encontrados: problemas com o produto/processo de desenvolvimento.
    - Testes: testes realizados e resultados obtidos.

Produto: funcionamento(cerca de 20% da nota) e outros (cerca de 20% da nota).

Grupo 3 - Segunda Sprint

Sprint 2 - Planning

Começamos a Sprint 2 no dia 06/10, com a Sprint planning logo após a revisão da primeira iteração, como manda o Scrum.

Nessa reunião de planejamento, resolvemos alterar o motor e a arquitetura do jogo devido aos problemas apontados na reunião de revisão da primeira Sprint, o que está adequado com a teoria do Scrum, já que a arquitetura emerge e eventuais mudanças podem ocorrer, isso é inclusive um dos pontos fortes do Scrum. Resolvemos mudar a arquitetura e motor gráfico para Web (Javascript+CSS+HTML) já que a nova ideia de jogo cabia muito mais num motor desse tipo do que a Unity, o que nos daria um ganho considerável na velocidade de desenvolvimento. Além disso, a maioria do time tem um conhecimento maior desse tipo de arquitetura do que com a Unity. Um ponto negativo dessa mudança seria a perda da portabilidade pois não é tão simples portar para aplicativos móveis quanto o Unity, porém como isso não era um requisito do projeto, o Product Owner concordou com a mudança.

No planejamento, resolvemos junto com o Product Owner, priorizar o Design das telas principais e algumas funcionalidades básicas de cada uma delas, como popular a base de personagens e projetos, associar um personagem a um projeto, além de criar a base da arquitetura, já que essa foi modificada. 

A Sprint 2

Seguimos com o modelo da primeira iteração, com cada membro do time desenvolvendo em suas máquinas pessoais e reuniões diárias em ambientes virtuais.

Um ponto interessante do nosso processo de desenvolvimento que vale uma breve menção é que toda issue, após desenvolvida é testada pelo desenvolvedor ou outro membro do time. Isso é feito para que o projeto se adeque ao nível 2 do CMMI e obviamente para evitar defeitos indesejados.
O principal avanço que conseguimos ao fim da iteração foi o desenvolvimento das telas principais do jogo. Abaixo, o desenho das telas, ressaltando que não se trata do produto final e eventuais alterações estão previstas.

• Tela de projetos (Início)

• Tela de um determinado projeto 

Sprint 2 Review

Concluímos a iteração no dia 20/10, novamente com a reunião de revisão.

• Tivemos algumas lições aprendidas nessa Sprint: 
• Alterar o motor e arquitetura foi uma boa escolha. 
• Ainda temos que prever melhor o tempo de cada tarefa, não conseguimos completar todas as tarefas. Porém isso é comum no mundo real, onde a previsão só fica próxima do real após algumas iterações. 
• Será necessário um gasto maior de horas na próxima iteração para que possamos concluir as tarefas 

CRUD para Sempre: Iteração 2 - Reunião Diária da Iteração

Crud para Sempre

Iteração 2 - Reunião Diária da Iteração

Requisitos

De acordo com nosso planejamento, na segunda corrida, focaremos na realização das telas: Criação da Empresa e Tutorial. Cada tela será representada por uma Tarefa principal e seus respectivos requisitos como sub-tarefas. Além dessas telas, movemos os requisitos que não foram implementados na corrida passada da tela de Criação do Personagem. A tabela a seguir descreve os requisitos da Iteração 2:

REQUISITOS DO PRODUTO
Tarefa	Descrição	Prioridade
Tela de Criação do personagem	Música de fundo	Alta
	Coleta Nome do Jogador	Alta
	Funcionamento	Alta
	Efeitos Sonoros	Média
Tela de Criação da empresa	Música de fundo	Alta
	Coleta Nome da Empresa	Alta
	Funcionamento	Alta
	Efeitos Sonoros	Média
	Menu	Média
Tela de Tutorial	Menu	Média
	Efeitos Sonoros	Média
	Música de Fundo	Alta
	Funcionamento	Alta
	Sprites	Média

1) O que já foi feito?

x Música de fundo e efeito sonoro das telas

x Sprites das telas de Criação do Personagem e Criação da Empresa

2) Decisões da interação

x Optamos por fragmentar cada tela em sub-tarefas à medida que o time de desenvolvimento terminar de implementar a tela anterior

x Para tentar resolver o problema de conflitos entre a Unity e o GitHub, decidimos dividir cada tela em cenas diferentes e independentes

x Nessa corrida, o Dono do Produto (Rafael Solli) criou story points (pontos de complexidade) para cada requisito. Dessa forma, será mais fácil para o time de desenvolvimento estimar a dificuldade, em termos de quanto tempo será usado para implementar

Print de Telas do Jogo

               

    Tela Principal       Tela de Criação do Personagem

 

Tela Criação da Empresa

Grupo 3 - Primeira Sprint

Sprint 1 - Planning

No dia 22/09 fizemos nossa primeira sprint planning. Essa primeira reunião serviu para alinhar conceitos de Scrum entre todo o time, definir alguns itens do backlog e planejar a iteração de fato.

Foi decidido nessa reunião que a nossa primeira sprint teria como foco o aprendizado e instalação das ferramentas necessárias para o desenvolvimento, bem como a definição de todo o nossa backlog, que foi postado anteriormente. Vale lembrar que tivemos que mudar completamente nossa proposta devido à uma sugestão do professor, assim levamos um tempo para definir esse novo jogo.

A primeira sprint planning demorou mais do que o normal (tempo sugerido pela teoria SCRUM), devido à passagem de conhecimentos sobre o scrum e a adaptação de todo o time ao formato.

Logo após a sprint foram criados 'issues' na nossa ferramenta de controle, o GitLab. Abaixo uma imagem ilustrativa das issues criadas:

A Sprint 1

Cada um dos membros desenvolveu suas atividades em suas máquinas pessoais, definimos que quem é responsável pela gestão do fonte é o Scrum Master, então os merges de branches e a criação do branch master foi responsabilidade do mesmo.

As eventuais dúvidas que surgiram no decorrer da sprint foram solucionadas nas nossas ferramentas de comunicação rápida (Whatsapp e Facebook), bem como as reuniões diárias que ocorreram todos os dias às 18 horas, por convite do Scrum Master.

Sprint 1 Review

Concluímos a iteração no dia 06/10, numa reunião de revisão feita logo após o término da aula.

Tivemos algumas lições aprendidas nessa Sprint:

• É difícil a coordenação de um grupo grande de desenvolvimento.
• Talvez a arquitetura usando o Unity não seja uma boa escolha para esse novo jogo.
• O nivelamento de conhecimento em um grupo tão grande é trabalhoso.
• O tempo de aprendizado para ferramentas de controle de versão e desenvolvimento, foi maior que o esperado.

Crud para Sempre - Iteração 1 - Reunião de Retrospectiva da Iteração

Crud para Sempre

Iteração 1 - Reunião de Retrospectiva da Iteração

Levantamento de Requisitos

Para o processo de levantamento de requisitos, utilizamos o DPJ (Documento de Projeto do Jogo), um documento que contém detalhadamente todas as características do jogo e do qual todos os membros da equipe irão extrair informações quando necessário. Nele são descritas as características mais importantes do jogo como: jogabilidade, arte, personagens, fases, entre outras.

O DPJ deve atender às expectativas do dono do produto, pois, é a partir dele que o jogo será construído. Com a finalização do DPJ inicial a equipe pode inicializar os processos de organização do planejamento e, logo em seguida, de desenvolvimento.

Criamos uma wiki para armazenar toda a documentação criada pelo grupo, onde podem ser encontradas todas as informações contidas no DPJ. O link para acesso é: https://github.com/CRUDParaSempre/DOCES/wiki.

Requisitos Não Funcionais

Um RNF tem como objetivo atender os requisitos do sistema que não se referem a funcionalidades do jogo, mas que fazem parte do escopo. No nosso caso, com um jogo de caráter educativo, especificamos os seguintes requisitos não funcionais:

1. Fácil acesso para o usuário
2. Ser lúdico e informativo
3. Curva de aprendizado suave 
4. Interface intuitiva

Requisitos Funcionais

Após definir os requisitos para a primeira corrida (Tabela 1) através do DPJ, decidimos fragmentá-los o máximo possível para gerar tarefas simples o bastante para serem implementadas em um prazo médio de um dia. Além disso, para não sobrecarregar a equipe, decidimos que o número de sub-tarefas por corrida deve ser entre 20 a 30 o que resultaria em 2 a 3 tarefas por integrante na média.

REQUISITOS FUNCIONAIS DO PRODUTO
Tarefa	Descrição	Prioridade
Tela de início	Logotipo	Alta
	Layout	Alta
	Botão Novo Jogo	Alta
	Botão Sair	Alta
	Botão Retornar à Tela Inicial	Alta
	Menu em Cascata	Média
	Botão para Página do Projeto	Média
	Menu	Média
	Botão Continuar Jogo	Média
	Botão Créditos	Média
	Fundo	Baixa
	Animação do Logotipo	Baixa
Tela de criação do personagem	Música de fundo	Alta
	Coleta Nome do Jogador	Alta
	Funcionamento	Alta
	Efeitos Sonoros	Média
	Roupa Personagem	Média
	Corpo Personagem	Média
	Cabeça Personagem	Média
	Fundo	Baixa
Outras	Criar Wiki	Alta

Tabela 1 - Requisitos Funcionais

Decisões da Iteração

Durante essa primeira iteração, decidimos:

1. Utilizar o GitHub como ferramenta para gerenciar os requisitos, organizar as tarefas, manter o quadro do scrum
2. Dividir as iterações por telas do jogo
3. Optamos por fazer primeiro as telas iniciais do jogo

Desafios Encontrados

Os principais desafios encontrados nessa iteração foram em relação ao não conhecimento das ferramentas por parte da equipe, tendo então um gasto de tempo muito grande em aprender a utilizá-las (GitHub e Unity).

Além disso, encontramos dificuldade em fazer uma divisão de tarefas mais equilibrada, pela quantidade grande de pessoas no time e a diferença de habilidades. Dessa forma, foi um grande desafio seguir os prazos estipulados para a primeira corrida.

Para a segunda corrida, com o time mais adaptado ao GitHub e Unity, pretendemos avançar mais no projeto e realizar todas as tarefas propostas da iteração dentro dos prazos.

Terceira postagem - Segunda apresentação

Objetivos Principais do jogo

Abordar o assunto de maneira simples e eficiente

Utilizar o método de revisão para retenção do conhecimento

Fazer com que o usuário obtenha um meio de aprendizado descontraído

Avaliar se os pontos chaves para o aprendizado foram absorvidos

Aplicar os conhecimentos sobre Engenharia de Software no desenvolvimento do produto

Gerenciamento de Requisitos (funcionais)

Como jogador, eu quero selecionar as fases de treinamento em uma tela específica.

Como jogador, eu quero que os ensinamentos do mestre sejam textuais.

Como jogador, eu quero que as perguntas da fase de teste sejam do tipo V ou F.

Como jogador, eu quero que as perguntas da fase de testes sejam aleatórias.

Como jogador, eu quero que respostas certas correspondam a um aumento da minha pontuação máxima.

Como jogador, eu quero que minha pontuação máxima seja exibida por meio de uma barra de XP.

Como jogador, eu quero que existam animações do personagem na fase de teste.

Como jogador, eu quero que o painel de seleção das fases de treinamento mostre meu desempenho nas fases concluídas no formato de 1, 2 ou 3 estrelas para pontuações mínimas, médias e máximas respectivamente.

Como jogador, eu quero enfrentar um personagem Chefão, como uma espécie de desafio máximo.

Como jogador, eu quero poder enfrentar o Chefão a qualquer momento fora das fases de teste, independentemente da quantidade de fases concluídas.

Como jogador, eu quero um mecanismo para ver minha pontuação relativa ao número de acertos.

Como jogador, eu quero um mecanismo para ver quanto tempo gastei para concluir uma fase de teste.

Como jogador, eu quero que meu progresso no jogo possa ser salvo.

Gerenciamento de Requisitos (não funcionais)

Como jogador, eu quero conseguir jogar em qualquer navegador

Como jogador, eu não quero que o jogo demore um tempo superior a alguns segundos para carregar

Planejamento do projeto

Primeira meta: Estabelecimento e a manutenção das estimativas do projeto.

Organização do grupo e decisões

Resultado da corrida

Duas atividades não foram completadas no tempo limite da primeira corrida.
Motivos:
*Sobrecarga dos programadores;
*Falta de experiência com o sistema de corridas.

Sugestões para a próxima corrida

Melhorar a divisão do trabalho;

Melhorar a administração do tempo.

Pesquisa com os usuários

Foi realizada uma pesquisa com os usuários a fim de analisar a proposta do jogo por meio de um formulário do Google. Os resultados obtidos foram disponibilizados via gráficos.

 Pesquisa de sugestões com o público-alvo

Um campo foi disponibilizado para que os usuários dessem sugestões para o grupo. Recebemos uma proposta interessante que está em fase de análise de viabilidade.

Proposta	Situação
Adicionar um tempo limite para responder as perguntas do chefão, tempo esse que se reduziria a cada perguntas, o que deixaria o jogo mais dinâmico e interessante	Sendo avaliada

 Desafios encontrados

Aplicar o conteúdo baseado no CMMI de forma didática, concisa e objetiva

Analisar e selecionar os requisitos visando uma maior qualidade e eficiência na implementação do software

Criação dos desenhos dos personagens e das telas de fundo do jogo.

Elaboração das perguntas e respostas utilizadas no jogo de forma a manter um nível desejado de dificuldade para melhor experiência e aprendizado do usuário.

Resultados obtidos

Produção parcial do conteúdo didático a ser apresentado no software e das perguntas.
Desenvolvimento da interface inicial do produto e da tela de treinamento e batalha
Interação e crescimento entre os participantes do projeto, aumentando o grau de maturidade da equipe
Possibilidade de utilização do protótipo e refinamento dos requisitos funcionais

Telas de demonstração do jogo

*Treinamento

*Teste