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

upGAME Group - Processos

Apesar de estarmos fazendo muitas postagens mais ao estilo ágil, é importante falarmos um pouco mais sobre os processos usados e como estão sendo aplicados.


Processo utilizado e sua aplicação

Como informamos na primeira apresentação, estamos trabalhando utilizando o Scrum, porém, com o passar do tempo, resolvemos adaptar um pouco o Scrum para se alinhar com as necessidades do grupo e com as limitações da ferramenta.

As diferenças.

Em um breve resumo, nossas principais diferenças são:

• Não temos Burndown;
• Não trabalhamos com um Backlog Global;
• A comunicação presencial é mais restrita;
• Nossas tarefas contam apenas com dois estados: To Do e Done;
• Temos um membro para cuidar exclusivamente das tarefas administrativas/gerenciais.

Em nosso processo, não temos um Burndown, isso porque o Issues Trackar não nos proporciona essa funcionalidade. Assim sendo, estamos monitorando o progresso dos pares pelos commits feitos no Github.

Podemos citar também as diferenças quanto ao Backlog. Como temos um prazo máximo de entrega a ser respeitado, um grupo grande e poucas Sprints para fazer as tarefas, resolvemos, em uma reunião, definir nossas tarefas e alocá-las nas 4 sprints necessárias para concluirmos nosso trabalho, assim sendo, não fizemos um backlog global, apenas fizemos os backlogs para cada sprint, distribuindo as Tasks previamente. Apesar disso, tarefas que ficam remanescentes das sprints anteriores, são colocadas nas próximas, assim como no Scrum padrão.

Backlog para a Sprint 3 (Atual).

Backlog da Sprint 4 (Próxima e última).

A maior parte da nossa comunicação está sendo feita por meio do github. Quando uma task é atualizada, o github envia um e-mail informando a todos os colaboradores do projeto que ela foi alterada e as informações que foram adicionadas e tudo mais, assim como quando uma tarefa é criada e excluída.

Outro problema que tivemos é que no Issues Tracker não temos como classificar as tasks como To Do, In Progress ou Done. Ele possibilita apenas To Do e Done. Para sabermos o que cada par de programação está fazendo, nos reunimos após as aulas. Neste momento todos dizem em que o seu par está trabalhando a previsão de conclusão daquela tarefa

Outro diferencial para o Scrum é que, além dos programadores, temos também um membro que cuida da parte administrativa e gerencial do projeto, ficando por conta da alocação de tarefas no Issues Tracker, documentação, atualização do blog, criação das apresentações e monitoria do andamento das tarefas. Pensamos que isso ajudaria pois os outros integrantes devem apenas se preocupar em programar e em estar atento as tarefas no Github e seus prazos. Com isso evitamos a sobrecarga de funções, o que pode atrapalhar o rendimento geral do grupo.

Modelo de Pares de programação

Com a utilização de um modelo de programação em pares estamos obtendo bons resultados. Neste modelo, os dois integrantes do grupo programam funcionalidades diferentes. 

Após terem concluído suas tarefas, o outro integrante fica responsável pela análise do código de seu parceiro.

Quanto o código passa pela análise, os dois integrantes devem fazer os testes nas aplicações criadas para garantir o funcionamento.

Assim, cada par é responsável pela qualidade e a funcionalidade dos seus códigos.

Esse modelo será desfeito na sprint final, a sprint de integração, onde todos os integrantes devem integrar as funcionalidades ao sistema final e fazer os testes (testes de caixa cinza), para certificar-se de que a integração não atrapalhou no funcionamento das aplicações.

CF70 - Apresentação 08/05

Segue o link para a apresentação do dia 08/05:

Apresentação 08/05

Também segue o link para o executavel apresentado:

Protótipo do jogo

upGAME Group - Terceira Apresentação

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/3yKSH7

Reunião Semanal 11/05 esofteacher@sHoRTcut

Decidimos que, excepcionalmente que nesta semana, não haverá a reunião por hangout em virtude da prova de Engenharia de Software.

A seguir, disponibilizaremos os artefatos exposto na apresentação do dia 08/05. Decidimos criar uma pasta pública no googleDrive para compartilhá-los goo.gl/T2x4XX.

1. Reserva do Produto
2. Reserva dos Requisitos da Iteração
3. Esforço da Equipe na Iteração
4. Gráfico da “Queimação” (Burndown)
5. Documento de Teste
6. Lista de  Falhas

Além disso, reforçamos que o acompanhamento do processo pode ser feito em trello.com/b/tv9tJsM3 e da evolução do produto em github.com/mfer/sHoRTcut.

Saiu a versão de 08-05 do esfoteacher!

Endereço para download:

 

goo.gl/I048UU

CF70 - Atualização da Planilha

Na última semana, decidimos fazer algumas alterações na planilha do Kanban. As mudanças podem ser verificadas pelo link de download disponibilizado abaixo:

https://www.dropbox.com/s/csltxnb0nbgc594/kanban_2014_05_07.xlsx

A atualização se deu principalmente devido à relação de complementaridade entre algumas das etapas de desenvolvimento, as quais fazem mais sentido serem desenvolvidas ao mesmo tempo.

Na tarefa de Fases, decidiu-se avançar a sub-etapa de Implementação para o estado de "Sendo Feito", visto que a implementação dos cenários estava se mostrando necessária para o teste das demais funcionalidades.

Na tarefa de Roteiro, é clara a ligação entre Personagens e Diálogos. Logo, achamos que seria mais fácil e lógico desenvolver as duas atividades simultaneamente.

O mesmo se aplica para a tarefa Perguntas, com as etapas de Questões e Dicas.

Além disso, a etapa de Elaboração das Mecânicas de Mini-Jogos e Eventos foi finalizada, o que permitiu a inicialização de sua Implentação.

Também cancelamos o Sistema de Alinhamento pois, apesar de acharmos a ideia interessante para um jogo, acreditamos que o fornecimento de dicas erradas por alguns personagens se mostraria contraprodutivo considerando o contexto de um jogo educativo. No lugar dessa mecânica, decidimos implementar um Glossário, contendo definição de termos importantes relacionados a Engenharia de Software que são mencionados ao longo do jogo.

upGame Group - Progresso

O par  2 conseguiu finalizar o mini-game 3.1. 

Neste mini-game, o jogador deve saber bem como discernir os requisitos.

O jogador recebe uma lista com vários requisitos e tem que separá-los em duas categorias: 

• Requisitos
• Requisitos mal definidos

Para conseguir passar por este mini-game, o jogador deve separar corretamente todos os requisitos.

Vejam a baixo alguns screenshots do mini-game funcionando:

Reunião Semanal 04/05 esofteacher@sHoRTcut

Estes foram os temas discutidos por nossa equipe durante a semana e na última reunião semanal:

Devido ao feriado da semana santa, decidimos que não haveria uma reunião semanal, consequentemente não haveria uma postagem referente ao resumo da reunião.   

A seguir apresentaremos um resumo das cenas elaboradas durante as semanas:

Pontos principais (de onde vai surgir o resumo):

• O resumo será dado pelo Scrum Master.
• Planejamento da sprint
• Levantamento de requisitos do primeiro módulo

Pontos para quiz (que vão entrar apenas na cena complexa):

• Perguntar se ele sabe o que é corrida
• Sobre como é o planejamento da sprint
• Sobre se devemos abraçar as mudanças ou exigir que o contrato seja seguido

Histórias possíveis:

1. Eu, como dono da empresa, quero cadastrar um produto, seu valor e sua quantidade em estoque
2. Eu, como dono da empresa, quero cadastrar clientes [com Nome, CPF, telefone, endereço e data de nascimento [, sendo que apenas Nome e CPF são obrigatórios]].
3. Eu, como dono da empresa, quero encontrar meus clientes [com base em qualquer campo, mas principalmente por Nome e CPF].
4. [Eu, como dono da empresa, quero ser avisado de quais clientes fazem aniversário no dia].
5. Eu, como dono da empresa, gostaria de saber quais são os produtos mais vendidos
6. Eu, como dono da empresa, gostaria de saber quais são os clientes que compram mais
7. Eu, como dono da empresa, gostaria de registrar as vendas realizadas sabendo qual cliente comprou qual produto 
   
   
   Itens em colchetes representam o que é opcional na história, ou seja, representa aquilo que o jogador só vai saber dependendo do questionamento que ele fizer.

Como o professor Rodolfo solicitou que pesquisemos mais a respeito dos procedimentos relacionados com as práticas vigentes na industria de jogos, optamos por elaborar um documento que resume os propósitos do jogo para fins de publicidade. Tal documento é conhecido na industria de entretenimento como One Sheet. Como o documento ainda esta em processo de elaboração, iremos divulga-lo na apresentação.