| Home | Arquitetura | Banco de Dados | Configuração | Gerenciamento do Projeto | Instalação | Materiais de Estudo | Mockups | Requisitos | Reunioes | Sprints | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

Equipe Projeto dTool

• Fluxograma de Trabalho
• Git Branching Model
• Code Review
• Organização da Equipe
• Horarios

Fluxograma de Trabalho

Git Branching Model

O modelo de gestão das branches do Git é baseado no Git Flow "trandicional" com adaptações. Não é previsto o uso de branches hotfix/*, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.

O desenvolvimento nos repositórios app e api deve seguir o fluxo de Git aqui definido:

• uma branch master com o código atualmente em produção;
• uma branch develop com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
• feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, feature/t06-login ou feature/t24-reports-ui);
• quando uma feature é finalizada, um PR da branch feature/ relacionada é aberto com destino à branch develop.

O código da develop é integrado com a master ao final da sprint, após validação dos stakeholders do que foi desenvolvido.

Dessa forma, o fluxo usual de trabalho é o seguinte:

1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch develop e pegar as últimas atualizações (pull);
2. criar uma branch para a task com o ID da task (feature/tXX-YYYYY);
3. "enviar" a branch para o remoto (git push -u origin feature/tXX-YYYYY);
4. desenvolver, commitar mudanças e atualizar o remoto (push);
5. voltar para o item 4 até finalizar a task;
6. abrir um PR com destino à branch develop;
7. mover o card da task no Trello para a lista Code Review e avisar no Slack (canal #code-review) que a task está pronta para review;
8. fim! 😃

Padrões de commit

Quando realizar um commit, tente manter o seguinte padrão nas mensagens:

• título: número da task e breve descrição da mudança;
• se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
• se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).

Exemplo:

#48: Fix patient name field placeholder

The placeholder was clipped smartphones with small screens; reduced placeholder
length for better UX on those devices.

Co-authored-by: Marcos Silva <[email protected]>

Code Review

Após o desenvolvimento de uma task, um pull/merge request (PR) deve ser aberto com destino à branch develop do repositório relativo à task: app ou api. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.

Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até dois dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).

Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:

• app:

  • funciona obrigatoriamente em Android, preferencialmente em iOS;
  • interface funciona nos tamanhos de tela suportados;
  • interface segue especificação no Figma;
  • conforme critérios de aceitação para a tarefa;
  • passa nos testes funcionais definidos para a tarefa/story;
  • documentação atualizada;
  • código dentro dos padrões;
  • código sem warnings ou erros de linter.

• api:

  • funciona conforme especificação no Postman;
  • possui testes de unidade associados;
  • mantém cobertura de pelo menos 50%;
  • dependências externas adicionadas aprovadas pelos AGES III;
  • documentação atualizada;
  • código dentro dos padrões;
  • código sem warnings ou erros de linter.

Essas regras foram adicionadas como template de PR em cada projeto.

Organização da Equipe

SQUAD 1: Camila, Edu Micael, Fischmann SQUAD 2: Emiliano Fagundes, Alex, Bruno Marcelino, João Brentano SQUAD 3: Jessica Manoel, Felipe Silveira, Lucas Castro

Horarios

Aqui deve ser apresentado os Horários disponiveis pelos Alunos, onde o AGES IV deve verificar quando pode construir Reuniões de Daily e Reunião de Andamento.

Iremos usar alguns Emojis para poder dizer os Horários Disponiveis:

Deve possuir os Horários de Cada Aluno Deve possuir a Tabela de Horários Marcados de Reuniões

• Exemplo de Tabela dos Alunos

Aluno

• Exemplo de Tabela das Reuniões

Daily

Exemplos

• Aluno

Gabriel Fanto Stundner

• Daily