Apresentação Final

Corrida Final e Resultados - Ganhando XP

Fase Gerencial

Nesta seção serão apresentados os planejamentos, resultados esperados, formas de controle de tarefas e outras adaptações que foram necessárias para realizar a entrega do trabalho. Ao fim do trabalho está um link contendo a versão final do jogo desenvolvido.

Entregas Esperadas:

Para essa apresentação as entregas esperadas eram:

• Módulos de treinamento completos e funcionais
• Módulos de desafio do mestre completos e funcionais
• Módulo de batalha contra o chefe final completo e funcional
• Tela final de pontuação implementada
• Todos os módulos integrados de forma a dar sequência ao jogo

Remanejamento da equipe:

Para evitar que houvessem membros da equipe trabalhando sozinhos, como ocorreu na terceira apresentação, foi preciso fazer um remanejamento das equipes e priorização das atividades de forma que todos tivessem pelo menos um par para revisar seu trabalho e vice-versa. Dessa forma, prezamos pela qualidade do produto e remoção antecipada de erros através de verificações constantes e inspeções feitas entre os parceiros de trabalho. A disposição da equipe ficou da seguinte maneira:

Criação das perguntas e conteúdo:  Lorena - Guilherme - Bernardo(Criação e revisão)
Criação dos enredos e ensinamentos:   Helbert - Márcio (Criação e revisão)
Programação em Back-End:   Jota - Matheus (Codificação e revisão)
Programação em Front-End:   Danilo - Lucas (Codificação e revisão)
Pesquisas de satisfação e qualidade:   Bernardo - Guilherme (Criação e revisão)

Telas de Controle

Durante a fase de controle foram utilizados apenas o Asana e a tabela de controle do Excel de forma que o Trello foi deixado, uma vez que nossos requisitos já eram bem definidos e estavam sendo controlados juntamente com a lista de tarefas no Asana. Nem todos os requisitos foram cumpridos, e estes serão explicitados mais a frente.

Desenvolvimento final e revisão do código de Front End

A última corrida, por parte da equipe de desenvolvimento Front-End foi focada principalmente na finalização e aprimoramento de todas as fases do jogo, ou seja, fase de aprendizagem, fase de treinamento e fase de desafio do Boss. Varias funções foram implementadas para cumprir os requisitos fundamentais e para que se conseguisse um projeto final funcional em todas as instâncias. Para que o projeto continuasse seguindo o curso planejado, continuou-se usando do artifício da programação em pares, o que proporcionou ao código uma revisão frequente. Mesmo assim, notou-se ao fim do projeto algumas falhas que passaram despercebidas em certos pontos do jogo, isso só veio a tona na revisão feita pelos membros do grupo que não eram desenvolvedores, mostrando a importância do conceito de revisão.

Também importante para o desenvolvimento da fase final do projeto foi o controle de versão, que não tinha sido utilizado na primeira corrida. Com tal recurso foi possível trabalhar em cima do projeto e estar sempre atualizado do que foi desenvolvido na última modificação do mesmo e o que ainda deveria ser feito. Foi utilizado o GitLab. Para que fosse desenvolvido um código repeitando as boas práticas de programação foi fundamental a utilização do JSHint, sempre tabulando e separando o código de maneira inteligível.

Infelizmente não foi possível entregar todas as funcionalidades previstas para última corrida ao fim do prazo estabelecido como final. Sendo assim, ficou comprometida a pontuação final do jogador e a luta com o Boss, ambas não cumpriram o que se esperava ao início do projeto.

Geração de conteúdo

Quanto à parte de geração de conteúdo, foram desenvolvidos perguntas com novos temas tanto para o treinamento quanto fase do chefe, totalizando cerca de 50 perguntas incluindo as de múltipla escolha e a de V ou F. Além disso, foi gerado o enredo para mais uma fase de treinamento. Um cuidado que foi tomado desta vez, foi com haver mais de uma pessoa em cada uma das atividades de forma a haver uma revisão e minimizar os erros. Além disso, foram realizadas revisões do conteúdo gerado por membros da equipe não diretamente envolvidos na criação do conteúdo, como Bernardo e Guilherme, de modo a localizar e resolver a maioria de problemas possível. O conteúdo desenvolvido foi baseados no livro-texto da disciplina.

Controle de Versão

O Controle de versão, prática do CMMI-DEV no nível 2 de maturidade, foi feito utilizando um repositório privado no Gitlab [1].

A lista de commits realizados pode ser verificada na seguinte figura:

Apropriamos da programação em pares, prática do XP, e o progresso de programação obtido em cada novo commit foi o seguinte:

Mostrando que o desenvolvimento do trabalho se deu forma contínua e estável, oscilando entre momentos de pausa e esforço maior, próximo do fim de cada corrida.

Controle de Qualidade do código

O código do front end foi todo escrito em Javascript, utilizando-se o editor Atom[2] devido a sua facilidade de uso, legibilidade e possibilidade de se utilizar pacotes para auxiliar no desenvolvimento de projetos.

Em nosso trabalho, visando termos algum método de controle de qualidade do código, com o intuito de minimizar os erros e seguir as boas práticas de programação, utilizamos um pacote de verificação de código chamado JSHint [3].

Esta ferramenta alerta o programador quando há algum erro de sintaxe e violação das boas práticas.

A figura a seguir, mostra um exemplo de atuação da ferramenta:

Podemos o trecho de código marcado em vermelho e na barra inferior a mensagem “[‘falas’] is better written in dot notation”, indicando a mudança adequada no código.

Testes de Unidade

No jogo, usamos como Framework a biblioteca Phaser.js [4]. Esta biblioteca facilita a criação de cenas nos jogos, através do conceito de Estados. Cada estado, corresponde a um momento do jogo, onde elementos podem ser criados e cenas podem ser rodadas. O diagrama de estados do jogo pode ser visto na figura a seguir:

Cada estado é na verdade um Objeto Javascript, portanto, os testes de unidade realizados verificaram a criação cada estado, bem como a existência de todos os métodos previstos no mesmo.

Aproveitando-se do Atom, utilizamos outro pacote para a realização de testes de unidade: o Mocha & Chai [5]. Este pacote permite a criação de código Javascript para testes através das estruturas:

• require: utilizada para criar uma variável de testes,
• describe: utilizada para descrição textual do teste corrente,
• it: utilizada para criar a função de teste,
• expect: utilizada para testar propriedades da variável de teste.

Podemos ver um exemplo de teste na figura a seguir:

Testamos se a variável bootState foi criada corretamente como um objeto e se esta possui um método (property), chamado create. O resultado do teste é mostrado a seguir:

As figuras a seguir exemplificam algumas falhas encontradas devido a reaproveitamento de código nos testes. As falhas ocorreram, pois, não seguimos o Test Driven Development (TDD), onde primeiro se criam os testes e depois se codifica para aprovação. Todas as falhas encontradas durante a programação ocorreram pela utilização de variáveis de testes diferentes. Todos os estados foram testados e todos os testes foram alcançados.

Testes de Caixa-Preta

Testes observando entradas e suas correspondentes saídas, conferindo se o resultado era mesmo o esperado (os denominados testes de caixa preta) foram realizados e bem satisfeitos. Esses testes eram importantes para a confirmação da integração correta entre front e back-end, ou seja, os testes mostraram que o requisitado pelo front era bem atendido pelo back. Uma requisição do front ao back é mostrada abaixo. A confirmação do funcionamento das requisições se dá no próprio funcionamento do jogo nas fases de teste pelo mestre e no desafio com o boss, onde todas as perguntas são resultado de requisições JQuery.Ajax ao back-end.

Conclusão

Percebemos diversas falhas cometidas na maneira como iniciamos nosso desenvolvimento do Software. Certas práticas de desenvolvimento adotadas por nós tal como inicio da programação com poucas revisões e/ou testes se mostrou rápida no inicio mas custosa a longo prazo, o que causou um atraso ao fim do projeto. Após a adoção de medidas de correção contínuas e revisões de códigos por pessoas que não haviam codificado, pudemos obter um produto satisfatório ao fim do trabalho, mas que poderia ter sido melhor caso tivéssemos adotado tais medidas logo ao início.

Link para o jogo completo

https://drive.google.com/file/d/0B3UBTm4ako88WFM1VmREdGRFLVU/view

Fontes

[1] http://gitlab.com/

[2] https://atom.io/

[3] https://atom.io/packages/jshint

[4] https://phaser.io/

[5] https://atom.io/packages/mocha-test-runner

Reflexão sobre o processo

Nessa postagem de fechamento, será feita uma reflexão sobre todo o processo de desenvolvimento e com foco nas dificuldades e desafios.

Problemas e dificuldades

No decorrer do projeto vimos o quanto é complicado trabalhar em um grupo com muitos integrantes. Uma razão que contribui para essa dificuldade é reunir dez pessoas que têm horários e compromissos completamente diferentes em um horário específico por um tempo muitas vezes indeterminado. Esse problema de horários prejudica muito o alinhamento de ideias entre os participantes já que a leitura de uma súmula ou documento não causa o mesmo entendimento que uma reunião presencial ou virtual.

Outro problema que sentimos mas que já imaginávamos que seria vivenciado é o de dividir tarefas grandes em menores independentes para uma melhor distribuição entre os membros do grupo. Poderíamos ter feito essa divisão de uma maneira melhor e mais eficiente que com certeza teríamos melhores resultados.

Tivemos ainda o problema da escolha considerada posteriormente ruim de jogo ("clicker") o que nos levou a mudar completamente o que tínhamos concebido a princípio, gerando um atraso considerável no início do projeto. Uma sugestão que temos a fazer para trabalhos em disciplinas futuras é uma pré validação da ideia de projeto pelo professor e/ou monitor antes da apresentação oficial, a fim de evitar esse tipo de contratempo. Outra sugestão nossa que também contribui para a concepção da ideia é deixar o tema livre. A restrição do tema dificulta bastante o processo criativo e, apesar de entendermos os benefícios didáticos de se produzir algo com o tema proposto, não vemos como algo necessário.

Lições aprendidas

Poderíamos resumir essa seção apenas com uma frase dita pelo grupo "CRUD para sempre" na última apresentação: "Programar é a parte fácil". Vimos de fato que escrever o código não é a parte mais difícil do desenvolvimento de software, até mesmo pelo background que temos no período que cursamos a disciplina.

Na prática, tivemos a oportunidade de aprender que um bom processo de desenvolvimento é essencial para um bom produto e perceber como decisões ruins ou erros de comunicação ou planejamento geram atrasos e problemas.

Finalizando, todos os participantes desse grupo sentiram que o trabalho foi difícil e trabalhoso, porém todos percebem a importância de fazê-lo.

Postagem Final

A Sprint final

Começamos a corrida final  numa reunião de planejamento dia 20/10. Nessa reunião, seguimos o
mesmo formato de todas, com o planning poker e levantamento de tarefas. A corrida final teve a duração de quatro semanas, com fim em  17/11, devido aos eventos peculiares desse semestre. Essa extensão da corrida, tornou ainda mais importante as reuniões diárias de acompanhamento, além do fato de que está a última corrida e deveríamos ter mais empenho e correr menos riscos de falhas de comunicação como ocorreu em momentos passados.

Como mencionado na última postagem, ela teve como foco a integração entre o back e o front end da aplicação. As tarefas no GitLab foram transferidas da última corrida para a corrida final, apenas com a observação de que deveria ser feito a integração de tal funcionalidade, não seu desenvolvimento em si pois este já estava concluído. Também nessa sprint, resolvemos cuidar um pouco mais da questão da qualidade, com a inspeção de código, planejamento e execução de um roteiro de testes, e o desenvolvimento, ainda que bem simples, de um script de teste automático. Vale lembrar que desde o início adotamos uma política de testes simples em cada tarefa, onde após concluída, a tarefa era testada por outro membro da equipe, a fim de avaliar se estava correta e obedecendo os requisitos do dono o produto. Abaixo, estão detalhados cada um desses tópicos:

• A inspeção foi realizada ao decorrer da corrida, avaliando características do código que seriam interessantes de se modificar para evitar problemas e facilitar a legibilidade. O relatório de inspeção, gerado no fim da sprint, se encontra na pasta "Qualidade", na raiz do repositório do projeto no GitLab. 
• O roteiro de testes foi planejado durante a corrida e executado quando o desenvolvimento do produto estava concluído, mas ainda restava tempo na sprint, já que adotamos a política de que se fosse detectada alguma falha que impedisse um fluxo, essa iria ser corrigida imediatamente. O roteiro está explicitado em uma planilha que também se encontra na pasta "Qualidade" na raiz do repositório, mas que também está na figura abaixo:
• O script de teste automático foi desenvolvido com intuito de demonstrar como seria um teste desse tipo para os membros do grupo que não conheciam já que o foco do trabalho deve estar sempre no conhecimento e aprendizado de novas técnicas e processos. O código fonte está na mesma pasta "Qualidade". O teste foi desenvolvido em Java, utilizando a ferramenta Selenium, para executar, a máquina deve possuir alguns arquivos instalados, um link pra um tutorial de como executar está disponível no arquivo README na pasta "Qualidade".

No dia 17/11, finalizamos oficialmente a última corrida, com a reunião de revisão e validação do dono do projeto. O produto que desenvolvemos ao final de todo o processo está, segundo o PO, adequado e suficiente com o previsto e especificado nos requisitos. Obviamente, alguns detalhes poderiam ter sido melhor executados e seriam bem-vindos se fossem desenvolvidos, como efeitos sonos, nomes mais interessantes para os projetos, tutoriais, mas nada que impeça os fluxos básicos de negócio. 

CMMI

Como era imprescindível que o processo adotado durante o desenvolvimento do trabalho, atendesse o nível 2 do CMMI, esta seção é relevante para detalhar cada uma das áreas e argumentar de que forma nós respeitamos cada uma delas.

• Gerenciamento de Requisitos - Os requisitos do projeto foram especificados e documentados no início do projeto pelo Product Owner juntamente com o restante da equipe. Eles ficaram registrados em um documento disponível a todos do projeto e que se encontra aqui.
• Planejamento de Projeto - O planejamento ocorreu no início de cada corrida, na reunião de planejamento. Fizemos um post no blog para cada reunião de planejamento e evidências das tais podem também ser encontradas no GitLab do projeto, já que nas chamadas "Milestones" se encontram a criação de cada uma das Sprints junto com as tarefas associadas.
• Acompanhamento e Controle de Projeto - O acompanhamento e controle foi realizado na ferramenta GitLab, onde é possível acompanhar o andamento de cada tarefa bem como o desenvolvimento de cada branch do código fonte e outros arquivos. Além disso, as reuniões diárias foram essenciais para um melhor acompanhamento do projeto.
• Gerenciamento de Acordo com Fornecedor - Não se aplica
• Medição e Análise - A ferramenta GitLab também nos ajudou nesse quesito já que ao final de cada Sprint realizamos a reunião de revisão, onde conseguimos analisar o desempenho baseado nas tarefas concluídas ou não.
• Garantia da Qualidade de Processo e Produto - Nessa quesito destacamos as nossas fases de teste de cada uma das tarefas, realizado por um membro diferente do desenvolvedor, a inspeção do código feita na última corrida e a criação e execução do roteiro de testes. Evidências dessas práticas estão junto ao fonte do projeto, como foi explicado anteriormente.
• Gerência de Configuração - Esse quesito foi atendido pelo uso do GitLab, gerenciado pelo mestre do Scrum, onde continha todas as informações do código fonte e tarefas. 

O produto

O nosso jogo simula uma empresa de desenvolvimento de software. A tela principal exibe os projetos disponíveis para o jogador e os personagens para compra. Para comprar um personagem, é necessário dar um duplo clique no ícone do personagem. Cada um dos personagens possui um preço específicos e são eles que vão trabalhar em cada um dos projetos do jogador. Para associar um personagem a um projeto, deve-se arrastar o ícone do personagem ao do projeto. Abaixo está tela de projetos:

Quando um projeto possui personagens associados a ele, é possível clicar no projeto e dar início a ele, clicando no botão iniciar, como na figura abaixo:

Quando um projeto está iniciado, é possível associar um personagem a uma tarefa, arrastando o ícone do personagem a uma tarefa. A princípio é possível apenas desenvolver as tarefas, quando uma tarefa é completada, o jogo é pausado automaticamente e a tarefa fica disponível para testes (Pressione 'ENTER' para 'despausar'). Ao completar todas as tarefas o projeto pode ser entregue porém, se as tarefas não forem testadas e/ou inspecionadas, o projeto será entregue com bugs e a recompensa pelo projeto será menor.

Cada personagem possui sua barra de energia e habilidade. A barra de energia reduz a medida em que o personagem trabalha e é reduzida quando ele é movido para a sala de reunião. A barra de habilidade diz o quanto o personagem é produtivo e pode ser aumentada se ele for movido para a área de treinamento.

A medida que o jogador entrega projetos e acumula reputação, novos vão sendo liberados, é possível visualizar os projetos bloqueado a partir da tela inicial clicando no ícone do cadeado.

Os botões “+” e “-” do teclado aceleram e desaceleram a velocidade do jogo, e ao pressionar “CTRL-S” o jogo é salvo e “CTRL-L” o último jogo salvo é carregado.

IMPORTANTE: Datas Finais

Alguns prazos finais, lembrando que atrasos em qualquer entrega serão penalizados!

• Data-limite para entrega dos formulários da avaliação final: 18/11 às 23:55
• Data-limite para postagem dos vídeos: 20/11 às 23:55.  
• Data-limite para envio do link do jogo: 20/11 às 23:55. Um link para a versão completa do jogo deve ser enviado por email para a monitora. 
• Data-limite para postagens: 20/11 às 23:55: postagens após essa data serão desconsideradas para a avaliação final do grupo. As postagens podem seguir o mesmo modelo da última apresentação, incluindo uma discussão reflexiva sobre o processo adotado.

IMPORTANTE: Substituição da Apresentação Final

Como já informado pelo professor Rodolfo, a apresentação final será substituída por um ou mais vídeos. O objetivo do(s) vídeo(s) é que os grupos evidenciem como o processo de desenvolvimento foi estabelecido e como esse processo conduziu o desenvolvimento do "jogo para conceitos de Engenharia de Software".

Vocês têm liberdade para montar o vídeo da forma como desejarem, desde que o objetivo mencionado acima seja alcançado. Uma sugestão seria dividir o vídeo em duas partes, uma explicitando o processo e em seguida uma apresentação do produto final. Porém, essa é apenas uma sugestão, logo os grupos podem optar por não seguir esse formato.

Algumas regras devem ser seguidas:

1) O(s) vídeo(s) devem ser postados como vídeos públicos na conta da turma no YouTube até domingo, dia 20/11. Informações sobre a conta da turma foram enviadas por email. Para receber novamente é só enviar um email para a monitora.

2) O grupo pode realizar:
- um único vídeo de 5 a 10 minutos OU
- vários vídeos com duração total máxima de 15 minutos

Conceito de Design - Minha Empresa

Iteração 3 - Reunião Diária das Iterações

Crud para Sempre

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

Requisitos Funcionais

Número	Descrição	Pontos	Situação
#193	Tela de Desenvolvimento - Criar Cartas de Ação	8	Pendente
#194	Tela de Desenvolvimento - Funcionamento das Cartas de Ação	13	Pendente
#195	Tela de Desenvolvimento - Botão Pronto	8	Pendente
#196	Tela de Desenvolvimento - Funcionamento do Canvas	5	Pendente
#174	Tela Inicial - Procurar por falhas na tela inicial	5	Pendente
#175	Tela de Personagem - Procurar por falhas na tela de criação do personagem	5	Pendente
#176	Tela Empresa - Procurar por falhas na tela de criação da empresa	5	Pendente
#177	Tela de Jogo - Procurar por falhas na tela de jogo	5	Pendente
#164	Tela de Jogo - Criar Funcionários	5	Pendente
#173	Tela de Jogo - Projetar as Habilidades do Jogador	8	Pendente
#165	Tela de Jogo - Implementar Habilidades do Jogador	13	Pendente
#161	Tela de Jogo - Funcionamento da Loja	13	Pendente
#166	Tela de Jogo - Funcionamento das Caixas de Diálogo (Projeto)	20	Pendente
#157	Tela de Jogo - Status do Jogador	8	Pendente
#159	Tela de Jogo - Botão “Porta”	5	Pendente
#62	Tela de Jogo - Efeitos sonoros	0	Pendente
#158	Tela de Jogo - Animações da tela	0	Pendente
#192	Tela de Desenvolvimento - Criar sprites	8	Em andamento
#190	Tela de Jogo - Criar um Banco de Perguntas	13	Em andamento
#160	Tela de Jogo - Criação de Projetos	5	Em andamento
#162	Tela de Jogo - Sprites de Novos Objetos	5	Em andamento
#163	Tela de Jogo - Sprites de Novos Cenários	5	Em andamento
#94	Criar tela de créditos	2	Em andamento
#172	Tela de Jogo - Funcionamento das Caixas de Diálogo (Tutorial)	8	Aguardando Revisão
#23	Tela de Jogo - Sprite	8	Concluída
#171	Tela de Jogo - Funcionamento das Caixas de Diálogo (Warning)	5	Concluída
#182	Tela de Jogo - Implementar o Tempo do Jogo	8	Concluída
#24	Tela de Jogo - Menu	8	Concluída
#25	Tela de Jogo - Fundo	5	Concluída
#169	Tela de Jogo - Atualizar sprite Personagem	8	Concluída
#63	Tela de Jogo - Música de fundo	0	Concluída

Requisitos Não Funcionais

Especificamos os seguintes requisitos não funcionais:

• Facilidade de uso
• Ser lúdico e informativo
• Tela de tutorial
• Interface gráfica

Decisões da Iteração

• Resolvemos alterar a coluna de “Em teste” para a coluna de “Aguardando Revisão”. As tarefas que estiverem nesse estágio serão inspecionadas por um integrante do time de desenvolvimento (que não seja o que tiver implementado a tarefa)
• Decidimos adicionar inspeções de código nesta corrida
• Também terminamos de definir toda a estrutura e lógica do jogo
• Um quiz com perguntas de verdadeiro e falso será implantado no jogo

Desafios Encontrados

Os principais desafios encontrados nessa iteração continuam sendo relacionados aos conflitos gerados pela integração do GitHub e a Unity.