Metodologia

Descriçã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).

Equipe Scrum

Scrum Master: responsável por aplicar os conceitos e práticas de um projeto por meio de uma análise e avaliação contínua das práticas ágeis da equipe. Na nossa equipe, a pessoa encarregada por tal papel é a integrante Geovanna Maciel.
Product Owner: aquele que direciona o projeto de acordo com as necessidades das partes interessadas (stakeholders). Sendo assim, o responsável por interpretar esse papel é o membro Arthur de Melo.
Time de Desenvolvimento: equipe encarregada de desenvolver o planejamento definido em cada sprint, no caso, todos os membros do grupo.

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 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: Sábado às 10h.
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.

Para cada entrave que demanda um pull request, uma branch deve ser criada, sendo tal nomeada de maneira que seja possível identificar a adversidade a qual está sendo solucionada nessa. Ademais, ao finalizar o pull request e a branch perder o seu propósito naquele momento, a exclusão da branch deve ser efetivada.

Histórico de Versões

Versão	Data	Descrição	Autor(es)	Revisor(es)
`1.0`	21/04/2023	Descrição da Metodologia	Arthur de Melo	Matheus Henrique
`1.1`	21/04/2023	Adição da Política de Commits e de Issues	Arthur de Melo	Matheus Henrique
`1.2`	22/04/2023	Adição da Referência	Arthur de Melo	Matheus Henrique
`1.2.1`	23/04/2023	Detalhamento extra na Política de Commits	Arthur de Melo	Rafael Ferreira
`1.2.2`	02/05/2023	Hyperlinks e especificação da equipe	Arthur de Melo	Rafael Ferreira

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.