Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão
apresentados documentos referentes a maneira como o time se organizou e trabalha.

📅 Processos

A equipe combinou em utilizar algumas técnicas ágeis para maior organização e controle dos processos. Acreditamos que os rituais ágeis colaboram muito para formar um ambiente com comunicação e colaboração, sempre visando melhorar e facilitar o trabalho da equipe de desenvolvimento, que quando se encontra em um ambiente organizado e coeso, tem um desempenho muito melhor.

Planning

O Sprint Planning é o primeiro ritual a ser feito em um novo ciclo de Sprint. Esse ritual é importante para definirmos as User Stories a serem feitas e suas respectivas tasks.

Daily

Por termos apenas um dia presencial na semana, acabamos por fazer apenas uma daily semanal. Ela ocorre no início do encontro, onde todos se levantam e um por vez conta o que fez na semana, o que pretende fazer e quais problemas/obstáculos encontrou. Com isso, todos estão cientes do progresso do projeto e quais tasks precisam de uma maior atenção caso estejam travadas.

Sync

Para tentar resolver o problema de ter apenas uma daily semanal, fazemos uma sync através do Discord com o mesmo intuito de uma daily, onde iremos contar o nosso progresso no meio da semana em relação ao projeto visando identificar potenciais problemas. Definimos que a Sync é realizada às terças feiras.

Retrospectiva

A restrospectiva da Sprint é realizada ao final de toda Sprint com o objetivo de avaliarmos os pontos positivos e negativos, seja em relação a Sprint que passou ou ao time como um todo. Com a avaliação dos nossos AGES IV, são criados planos de ação para arrumar o que não está progredindo bem e incentivar tudo que ocorreu de bom para o time.

📊 Kanban

Utilizamos o quadro Kanban para organizar todas as tasks do projeto. Cada task tem seu próprio Card, que contém informações como quem está designado para essa task, comentários sobre ela e sua definição juntamente com o Acceptance Criteria dela:

✅ Acceptance Criteria (Critério de Aceitação)

Para que uma tarefa seja considerada pronta, ela deve preencher todos requisitos da acceptance criteria que estão no seu respectivo card no quadro de tasks, podendo ter uma foto anexada para tasks do frontend:

♾️ Git Workflow

Para mantermos os repositórios organizados, utilizaremos o Gitflow, que é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (feature) ou consertos (hotfix) a partir de duas branches primárias (Main e Development).

• Main: A branch principal, tendo todo o código final, validado e testado;
• Development: A branch de desenvolvimento (dev), onde irá organizar os trabalhos realizados.

Mais sobre o Git Workflow

🛠️ Padrões Utilizados

Idioma padrão

Todas as branches, commits e merge requests devem ser nomeados e descritos em inglês.

🔱 Branches

Cada branch relacionada a features/hotfixes será criada a partir da branch development.

Nomes:

Como padrão para nomes de branches, foi decidido que usaremos o CamelCase:

<tipoDeItem>/<nomeDoItem>

Exemplo:

feature/telaDeProcessamento, hotfix/alterTableBanco

Criação:

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch development (dev) antes de criar uma branch nova:

git checkout dev # Troca para a branch de desenvolvimento

git pull origin dev # Atualiza a branch dev para a versão mais recente

# Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch> # Cria uma nova branch.

# Assim que criar a branch, é necessário fazer um push para garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

💾 Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push.

Para garantir que apenas o código necessário para funcionamento da tarefa será commitado, lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa.

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados.

Em seguida, não esqueça de dar um push para salvar remotamente.

git add <nomeDoArquivo> # Adiciona os arquivos alterados ou criados ao Commit

git commit -m 'descrição da tarefa em ou inglês' # Salva localmente as alterações com uma descrição obrigatória

# Para commits onde teve participação de mais de um autor. Siga o exemplo abaixo:

git commit -m 'descrição da tarefa em inglês'
Co-Authored-By: Nome Sobrenome <[email protected]>

git push # Salva as alterações remotamente

Tipos de Commit:

• "feature", para descrever funcionalidades adicionadas;
• "fix", para descrever soluções de problemas;
• "docs", para identificar trabalho na documentação do projeto;
• "build", para identificar trabalho na configuração do projeto.

Exemplos de uso:

• feature: Implementation of the input button.
• fix: Correcting the submission of information to the database.
• docs: Describe commit patterns.
• build: Dependencies updates.

〽️ Merge Requests

Um merge request (MR) deve ser criado somente quando a tarefa estiver concluída, com critérios de aceitação prontos.

Criação:

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

1. Selecionar a branch de origem (sua branch de desenvolvimento);
2. Selecionar a branch de destino (branch dev);
3. Selecione Compare branches and continue;
4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
7. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
8. Em Milestone selecione a Sprint em que a tarefa foi realizada;
9. Em Labels selecione qual é o tipo de tarefa que foi realizada;
10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

❄️ Code Freezing

É estabelecido um tempo onde se encerram os trabalhos de desenvolvimento antes de uma entrega, para garantir a qualidade da entrega, evitando possíveis bugs e problemas que possam surgir.

Foi determinado às 4h da manhã da quinta-feira, antes da entrega.