time.md
0 → 100644
| | [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 | |||
|  | |||
| ## 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 |