Resumo das Reuniões da Semana:
- Discussão sobre o uso do git:
Alguns membros do grupo encontraram dificuldades devido às múltiplas edições simultâneas do código fonte. Esses problemas levaram à discussão sobre qual seria a melhor forma de uso da ferramenta de controle de versão. Chegamos às seguintes conclusões: - Adotar o uso da seguinte sequência para evitar conflitos de merge:
- commit
- pull
- eventual resolução local de conflitos
- push
- O código será modularizado em cenas e a divisão de tarefas também será feita considerando as cenas, gerando arquivos separados que serão alterados por apenas um desenvolvedor a cada momento. Assim, cada cena pode ser desenvolvida em paralelo, diminuindo a probabilidade de conflitos.
Foi sugerido o uso do gitk para facilitar a visualização. A decisão de utilizá-lo ou não ficou por conta de cada desenvolvedor.
- Novamente foi discutido a necessidade de expandir o tema tratado no jogo. Chegamos à conclusão de que, embora existam muitas diferenças na parte de Engenharia de Requisitos entre os processos ágeis e os tradicionais, percebemos que o jogo pode ser mais interessante ao lidar também com outras situações, como a parte de testes ou da formulação das reuniões. Decidimos que essa decisão deveria ser validada com o cliente, então enviamos um e-mail para a Luciana perguntando se ela aceita a decisão.
- Avaliamos as horas da última estimativa de disponibilidade de tempo e concluímos que será necessário a refatoração da mesma, para que assim possamos determinar o tamanho da próxima corrida (sprint).- Essa necessidade surgiu da percepção do tempo gasto com tarefas extra-código, como preparação de posts no Blog, slides para apresentação, estudo da matéria, etc.
- Parte da equipe investiu na criação de um recurso automático de postagem no Blog a partir do que é feito no Trello, motivados pela grande quantidade de tempo que gasta-se formatando o texto a ser enviado. Entendemos que essa tarefa é secundária em relação ao desenvolvimento do jogo, mas que pode nos ajudar a ter mais tempo para o desenvolvimento. O desenvolvimento desse item ainda não está pronto, mas foi possível obter uma evolução.
- Discutimos como fazer os testes do nosso jogo. O nosso desejo era utilizar Testes de Unidade (Unit Tests) e Desenvolvimento Orientado aos Testes (TDD):
- Chegamos à conclusão de que não será possível aplicar Desenvolvimento Orientado aos Testes no nosso trabalho. O nosso código é feito em forma de script que é chamado pela engine do renpy e o resultado de sua execução, de forma resumida, é o aparecimento de imagens e texto na tela. Utilizar TDD no desenvolvimento de uma Visual Novel é praticamente testar todo o conteúdo da cena, sendo igual a própria cena.
- Decidimos que iremos tomar três iniciativas para o controle da qualidade do produto:
- Inspeção de código: verificação por outra pessoa, que não o desenvolvedor da tarefa, do código fonte, validando, sobretudo, o uso de condicionais e flags;
- Testes sobre o resultado final da cena: esse teste irá validar principalmente o conteúdo dos textos (como ortografia), posicionamento de botões, imagens e diálogos;
- Testes de integração: verificação dos resultados do jogo por todas as combinações possíveis de escolhas a serem feitas pelo jogados.
- Para auxiliar os testes sobre o resultado das cenas, iremos verificar a possibilidade de utilizar uma ferramenta que refaz cliques de usuários baseado em coordenadas em pixel na tela, permitindo testar uma vez e automatizar a reprodução do teste.
- Iremos também verificar a viabilidade de realizar Testes de Unidade utilizando o próprio renpy, alterando o valor de flags enquanto a cena se desenrola de acordo com as escolhas feitas, capturando o estado final e comparando com o esperado programaticamente.
- Decidimos que, excepcionalmente na semana a seguir, não haverá a primeira reunião em pé da semana em virtude da prova de Engenharia de Software.
