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