Metodologia

Introdução

A metodologia do projeto é a forma como o processo foi realizado, ou seja, as práticas e as estratégias utilizadas para o planejamento e a execução das etapas que as compõem. Sendo assim, para o desenvolvimento deste projeto, o grupo se baseou no método Scrum, devido à familiaridade da equipe com tal.

SCRUM

O método Scrum pode ser definido como um conjunto de boas práticas, as quais possuem como intuito o desenvolvimento um projeto no qual não precisa necessariamente do discernimento de todas as etapas. Portanto, o projeto é divido em ciclos, denominados sprints. As sprints são um conjunto de atividades que deverão ser executadas num determinado tempo (Sprint Backlog).

Eventos

Sprint: Ciclo do projeto que, no caso, é de uma semana. Tal ciclo tem como objetivo desenvolver o projeto na prática, a partir da teoria, por meio de tarefas estabelecidas na reunião de planning. Por fim, o progresso seria analisado na reunião de review. No entanto, por causa da participação do grupo em outras matérias que precisam de reuniões, 2 reuniões principais por semana se mostraram impossível com a experiência, desta forma, o grupo optou por fazer o review na mesma reunião de planning.
Status: reuniões presenciais curtas realizadas entre as duas reuniões citadas acima, as quais servem como uma troca rápida de informações sobre o andamento do projeto. No caso, nossa equipe optou também por fazer os status antes ou após as aulas e também por meio de troca de mensagens.

Reuniões

Na semana inicial do projeto, montou-se uma planilha com os horários disponíveis de todos os membros. A partir disso, foi acordado entre os participantes o seguinte:

Planning e Review: Segunda às 20h.
Status: Antes ou após as aulas da disciplina.

Política de Issues

Uma issue deve ser aberta sempre que:

Quiser relatar um problema do qual você não consegue solucionar sozinho.
Achar necessário propor uma função ou ideia nova para o projeto.
Precisar debater algum tópico em específico.

Participar de uma Issue

Caso deseje participar duma issue da qual não estiver encarregado, comente para que o criador da issue o deixe como encarregado também.
Se, por ventura, alguma issue já estiver aberta há muito tempo, provavelmente ela já está resolvida. Portanto, comente nela para confirmar que essa tarefa já está finalizada antes de começar a desenvolvê-la.
No momento que você resolver a issue por completo, finalize a issue.

Política de Commits

Quase sempre deve-se abrir um pull request, em especial, nas seguintes ocasiões:

Quando for enviar correções simples.
No momento que for dar assistência à alguma contribuição na qual já está sendo trabalhada em alguma issue.

Além disso, é importante ressaltar que um pull request não significa exatamente um trabalho finalizado. Ele também é uma forma de acompanhar o progresso do desenvolvimento de algum artefato ou ideia, ou seja, é também uma forma dos outros acompanharem aquilo que está fazendo. Um pull request antes de ser aprovado ainda recebe commits posteriores ao seu levantamento. Sendo assim, é importante que o revisor faça as alterações necessárias na branch específica e faça o merge.

Bibliografia

ALVES, Isaque, ROCHA, Carla. Qualifying Software Engineers Undergraduates in DevOps - Challenges of introducing technical and non-technical conceptss in a project-oriented course. Arxiv. [S. l.], v.1, 2021. Disponível em: <https://arxiv.org/abs/2102.06662>. Acesso em: 16/04/2023. INTERAÇÃO HUMANO-COMPUTADOR. Bilheteria Digital - Metodologia de Desenvolvimento. [S. l.], 2023.1. Disponível em: https://interacao-humano-computador.github.io/2023.1-BilheteriaDigital/planejamento/metodologia/. Acesso em: 06/04/2024.

Histórico de Versão

Versão	Data	Data Prevista de Revisão	Descrição	Autor(es)	Revisor(es)
`1.0`	06/04/2024	07/04/2024	Descrição da Metodologia	Douglas Marinho	João Artur
`1.1`	07/04/2024	08/04/2024	Arrumando o histórico de versão e Bibliografia	Eric Silveira	João Artur
`1.2`	01/05/2024	02/05/2024	Arrumando o histórico de versão	João Artur	Douglas Marinho