upGAME - As Sprints

 

Nós fizemos 4 sprints de 2 semanas cada. As tarefas definidas para cada sprint foram:

Sprint 1 - Preparação

Essa sprint foi uma sprint que resolvemos tirar para podermos definir os detalhes do restante do projeto e fazermos pesquisas sobre ferramentas, processos, exemplos de jogos que poderíamos nos basear. Aqui foram tomadas várias decisões sobre a história, as ferramentas, os processos, o escopo genérico para cada Sprint seguinte e várias outras decisões, como a separação dos pares, o meio de comunicação entre outras.

Por esse motivo, nessa Sprint não tivemos a produção de código, mas foi muito importante para podermos nos organizar para o restante do projeto

Sprint 2 - Desenvolvimento

Essa foi nossa primeira sprint de desenvolvimento. Ela foi pouco produtiva, porque por estarmos tentando criar um novo modelo de desenvolvimento, demorou um tempo até que todos pudessem se adaptar. Nela foi produzido um mini-game do nível 4 e um pouco do mini-game do nível 3. Os objetivos era que todos os pares entregassem pelo menos um mini-game pronto no fim dessa sprint. Apenas dois dos 3 grupos conseguiram. O par 1 não conseguiu fazer essa entrega por problemas pessoais. Apesar disso, eles conseguiram alguns avanços interessantes, definindo um estilo de Tilesets e Sprites com licença livre no DevianArt. Essas imagens foram usadas em todo os jogos que necessitassem de um mapa.

Essa Sprint foi parcialmente um sucesso, pois, apesar da produtividade do par 1 ter sido baixa quanto a codificação, eles conseguiram definir as artes que foram utilizadas no sistema.

Sprint 3 - Desenvolvimento

Nessa outra sprint de desenvolvimento, os objetivos era a conclusão dos níveis. Isso sobrecarregou um pouco o Par 1, porque tiveram tarefas remanescentes que tinham que ser feitas. Felizmente, essa sprint foi um sucesso, já que todas as nossas metas foram concluídas. Os mini-games de cada nível estavam funcionando isoladamente.

Sprint 4 – Integração e garantia de qualidade

Essa foi a nossa última sprint. Definimos ela como sendo a sprint que todos os níveis seriam integrados e testados. Nessa sprint resolvemos dar uma pausa e juntar toda a equipe para que testássemos os mini-games antes da integração. Com isso conseguimos remover alguns bugs, mas não todos, porque a biblioteca MelonJs, por ser bem nova, não temos bastantes opções para buscar resoluções de problemas. Assim sendo, alguns bugs da biblioteca não foram consertados. A maioria não interfere nos jogos.

Após isso, cada par integrou seu nível e fizeram testes. Quando a tarefa foi dada como pronta, todos os integrantes fizeram novamente testes para garantir que não ficassem erros de integração. Removemos os bugs e o sistema já estava pronto para a entrega final.

 Estas informações é um fragmento do nosso relatório. Veja o relatório completo em: http://goo.gl/9M0H79

upGAME - Relatório final

Para melhor entendimento do que foi nosso projeto, os processos trabalhados, a divisão de sprints e tudo mais, foi criado um relatório informando tudo que ocorreu durante o projeto. 

Esse relatório ficou muito extenso, então, quem tiver interesse, pode acessar o link para fazer o download ou mesmo para ver online. 

Link para download: http://goo.gl/9M0H79.

upGAME - Apresentação Final

A terceira apresentação do nosso grupo está disponível para o público. Vejam abaixo ou façam o download pelo link: http://goo.gl/1dnul8

CF70 - Apresentação Final e Revisão de Processo

Com o término do desenvolvimento jogo e a última apresentação realizada, disponibilizamos o produto para download:

Executavel

A apresentação final, realizada na aula de hoje, pode ser visualizada pelo link:

Apresentação

Decidimos também, nesta postagem, reafirmar alguns pontos do processo do trabalho, como revisão do trabalho feito.

Na postagem Nome do Grupo e Primeiras Decisões foi definido o processo a ser utilizado (Kanban), com uma explicação dos motivos que levaram a essa decisão.

Na postagem Decisões de Projeto e Requisitos, foram definidos os requisitos e foi apresentado um protótipo descartável do produto. 

Em Definição de Tarefas foram definidas e divididas as tarefas do desenvolvimento (com base nos requisitos). A postagem também cita que um membro do grupo ajuda os demais em suas tarefas esporadicamente, o que serve como inspeção.

A evolução dos requisitos foi especificado em Evolução dos Requisitos, mas já havia sido discutida em outras postagens, principalmente as que detalham as atualizações da planilha do Kanban(como em Atualização da Planilha e no fim de Detalhamento da 2ªApresentação e do que foi feito).

A postagem final, Conclusão e Considerações Finais, faz um breve apanhado das conclusões tomadas com relação ao processo do Kanban, e menciona os testes (caixa-preta) e o processo de validação utilizados.

Algo que não explicitamos em nenhuma postagem, mas foi dito nas apresentações, é o uso de testadores ao longo do trabalho para validação de ideias e conceitos, o que chegou a levar até mesmo a algumas refatorações do projeto.

Finalmente, os links das apresentações feitas em aula estão disponíveis em postagens anteriores, assim como versões anteriores da planilha de tarefas do processo.

Apresentação Final - esofteacher@sHoRTcut

 

Nesse último post gostaríamos de agradecer a oportunidade de nos organizar como uma fábrica de software e, assim, sermos expostos às diferentes escolhas/decisões que moldam a arquitetura de um software.

Apesar de não termos alcançado tudo que foi planejado, conseguimos atingir progressos notáveis. Durante o projeto do Esofteacher, conseguimos acompanhar a evolução do processo desde a sua concepção, até o seu amadurecimento.

A seguir, disponibilizaremos os artefatos expostos (inclusive aqueles apresentados no dia 29/05). Acessíveis na pasta pública goo.gl/T2x4XX.

1. Reserva do Produto
2. Reserva dos Requisitos da Iteração
3. Esforço da Equipe na Iteração
4. Burn Down
5. Documento de Teste
6. Lista de  Falhas
   
   Vale mencionar que nem todos os artefatos estão presentes na pasta, visto que alguns deles foram sobrescritos no decorrer do trabalho.

Outros assuntos que refletimos após a apresentação de hoje e que gostaríamos de levantar:

• Começamos com a ideia de fazer programação em par e acabamos desistindo de institui-la no processo. Por diversas vezes fizemos o exercício de Navegador e Piloto, percebendo de modo qualitativo que houve ganho no sentido de permitir detecção de defeitos (por exemplo, detectados pelo Navegador que passariam desapercebidos pelo Piloto) e ganho de produtividade pelo clichê: “duas cabeças pensam melhor que uma”. Porém, nem sempre isso ocorria como esperado.
• Foi realizada uma refatoração da cena inicial para se encaixar melhor nas cenas de apresentação das equipes.
• O integrante Luiz Byrro realizou a confecção do onesheet, além de ajudar com os testes.
• Especialização espontânea da equipe, emergindo pessoas que trabalharam mais com o processo, com apresentações, com roteiro, com desenvolvimento, etc.
• O tempo contabilizado pelos cartões no estado de executando serviram como entradas para o burndown.

           

Caso encontrem alguma dificuldade na interpretação das planilhas, pedimos que entrem em contato com o grupo.

O jogo se encontra na pasta pública:

 

goo.gl/I048UU

Atenciosamente,

sHoRTcut team

CF70 - Conclusão e Considerações Finais

Nessa semana, com a data limite de entrega do trabalho se aproximando, conseguimos finalizar o projeto, mas não iremos postá-lo aqui para não estragar a surpresa na hora da apresentação. A planilha correspondente ao final do projeto pode ser visualizada pelo link:

https://www.dropbox.com/s/bkbdxy7ysu8rmw5/kanban_2014_05_27.xlsx

Terminando a última fase, pudemos fazer uma avaliação dos processos realizados ao longo do semestre. O processso utilizado foi o Kanban e ele apresentou vantagens e desvantagens. A principal vantagem foi a modularização do projeto e a divisão de tarefas bem definidas, com cada integrante do grupo cumprindo suas tarefas em tempo hábil (ocorreram algumas dificuldades em algumas tarefas, como a integração das perguntas e dos diálogos mas, nesses casos, todo o grupo se mobilizou para resolver o problema, o que é previsto no Kanban). Um ponto negativo foi a não-definição de Sprints, o que proporcionou uma flexibilidade maior do que a necessária. Desse modo, em algumas semanas (principalmente aquelas com grande volume de provas e trabalhos) o trabalho realizado pelo grupo foi menor do que em outras. Porém, o comprometimento do grupo minimizou esses problemas, pois ao perceber que o progresso feito estava abaixo do previsto, era feito um esforço extra para compensar o tempo perdido.

Será feito um teste do jogo, com cada integrante do grupo convidando cinco pessoas para jogá-lo, e depois será feita uma estatística sobre o avanço dos jogadores na área de Engenharia de Software (com base no resultado de "testes"), para ver se o jogo cumpre o seu objetivo, que é auxiliar no aprendizado de ES.

CF70 - Evolução dos Requisitos

 

Ao longo do desenvolvimento do software, foram feitas algumas mudanças nos requisitos do jogo. Essas alterações ocorreram, de modo geral, devido à reconsideração do alinhamento das funcionalidades com os objetivos do jogo. Em particular, é interessante discorrer sobre os seguintes pontos:

Diversas fases, cada uma sobre um tema específico da engenharia de software (cmmi, xp, scrum, pmbok, etc)

 

Seguindo a validação da proposta do jogo, realizada com amigos e familiares dos desenvolvedores, foi determinado que a implementação de várias fases tornaria o jogo muito repetitivo e cansativo. Além disso, a divisão de temas em diferentes fases também limitaria a abordagem de alguns temas.

 

NPCs tem atributos que indicam o quanto eles irão ajudar ou atrapalhar o jogador

Esse requisito ia de encontro com a implementação do sistema de alinhamento dos personagens que, como explicado na apresentação, era contrário à proposta de um jogo educativo.

 

Glossário de termos descobertos ao longo do jogo

Para preencher a lacuna deixada pela remoção do sistema de alinhamento na mecânica do jogo, e ainda adicionar um componente mais educativo (como também foi sugerido durante a validação), decidimos implementar um glossário de termos relacionados a Engenharia de Software. Dessa forma, os termos mencionados nos diálogos do jogo teriam uma definição disponível para o jogador.

Outros

 

Os demais requisitos permaneceram os mesmos, de forma geral. As únicas exceções estão relacionadas ao requisito de "fases", onde as funcionalidades que variavam de uma fase para outra passaram a ser fixas (devido à remoção das mesmas).