Igor Sgorla Brehm · f28881c9
--- a/time.md
+++ b/time.md
+| [Home](home) | [Arquitetura](arquitetura) | [Banco de Dados](banco_dados) | [Configuração](configuracao) | [Gerenciamento do Projeto](Gerenciamento_projeto) | [Instalação](instalacao) | [Materiais de Estudo](Materiais_estudo) | [Mockups](mockups) | [Requisitos](requisitos) | [Reunioes](reunioes) | [Sprints](sprints) |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+# Equipe Projeto dTool
+
+<p align = "justify">
+
+* [Fluxograma de Trabalho](#Fluxograma-de-Trabalho)
+* [Git Branching Model](#git-branching-model)
+* [Code Review](#code-review)
+* [Organização da Equipe](#Organização-da-Equipe)
+* [Horários](#Horários)
+
+## Fluxograma de Trabalho
+![Como_faço_pra_começar_](Imagens/Como_faço_pra_começar_.png)
+
+## Git Branching Model
+
+O modelo de gestão das branches do Git é baseado no [Git Flow "trandicional"](https://nvie.com/posts/a-successful-git-branching-model/) 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
+
+<p align="center">
+  <img src="Imagens/organizacao-AGES.png" width="400" height="400">  
+</p>
+
+**SQUAD 1:** Camila, Edu Micael, Fischmann
+**SQUAD 2:** Emiliano Fagundes, Alex, Bruno Marcelino, João Brentano
+**SQUAD 3:** Jessica Manoel, Felipe Silveira, Lucas Castro
+
+## Horários
+
+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:
+
+|Emoji|Código|Para que serve|
+|---|---|---|
+:star:|`:star:`| Quando aquele horário estiver disponivel
+:speech_balloon:|`:speech_balloon:`| Horário Marcado e Dia da Reunião
+:x:|`:x:`| Quando a Daily não ocorreu
+
+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
+
+Hora|Segunda|Terça|Quarta|Quinta|Sexta|Sábado|
+|---|---|---|---|---|---|---|
+10h|
+11h|
+12h|
+13h|
+14h|
+15h|
+16h|
+17h|
+18h|
+19h|
+20h|
+21h|
+22h|
+
+* Exemplo de Tabela das Reuniões
+
+# Daily
+
+Dia|Hora|Alunos Presentes|Status
+|---|---|---|---|
+
+
+## Exemplos
+
+* Aluno
+
+# Gabriel Fanto Stundner
+
+Hora|Segunda|Terça|Quarta|Quinta|Sexta|Sábado|
+|---|---|---|---|---|---|---|
+10h|||||||
+11h|:star:|:star:|:star:|:star:|:star:
+12h|:star:||||||
+13h|:star:||||||
+14h|:star:||||||
+15h||:star:||||
+16h|||:star:
+17h||||:star:
+18h|||||:star:
+19h||||||:star:
+20h|:star:|:star:|:star:|:star:|:star:|:star:
+21h|||||||
+22h||||||:star:
+
+* Daily
+
+Dia|Hora|Alunos Presentes|Status
+|---|---|---|---|
+22/03/2019|13h|Gabriel Fanto,Thomas Pozzer| :speech_balloon:
+10/04/2019|16h|| :x:
+12/04/2019|18h| Gabriel Fanto| :speech_balloon:
+
+
+
+</p>
\ No newline at end of file