Skip to content

GitLab

processo · Changes

Page history
Update processo, Adicionado a sessão de Código para este tópico. Também trocado o Menu Cabeçalho. authored by Giovanni Gonçalves Migon's avatar Giovanni Gonçalves Migon
Show whitespace changes
Inline Side-by-side
processo.md
View page @ 5447fe82
| [Home](home) | [Escopo e Cronograma](escopo) | [**Processo**](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Código](codigo) | [BD](banco_dados) | [Qualidade](qualidade) | [Utilização](utilizacao) |
| :----------: | :---------------------------: | :----------------------: | :--------------: | :--------------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :----------------------: |
|   [Início](home)   | [Cronograma](escopo) | Procedimentos | [Design_de_Telas](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Banco_de_Dados](banco_dados) | [Qualidade](qualidade) | [Instruções_de_Uso](utilizacao) |
| -- | -- | -- | -- | -- | -- | -- | -- | -- |
# Processo de Desenvolvimento
# Procedimentos de Trabalho
## Descrição
Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.
Esta seção é dedicada a apresentar convenções e processos de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.
## Sumário
- [Git Workflow](#git-workflow)
- [Convenções de Código](#convenções-de-código)
- [Matriz de Responsabilidade](#matriz-de-responsabilidade)
- [Plano de Comunicação](#plano-de-comunicação)
- [Plano de Riscos](#plano-de-riscos)
......@@ -20,7 +22,7 @@ Esta seção é dedicada a apresentar o processo de desenvolvimento do time, jun
#### Nomes
Como padrão para nomes de branches, foi decidido o seguinte:
Como padrão para nomes de branches, foi decidido:
```
<tipoDeTask>/<userStoryDaTask>
......@@ -43,19 +45,19 @@ page-creations
#### Criação
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:
Para garantir que o processo de desenvolvimento esteja sempre atualizado com a branch develop, lembre-se de executar o seguinte comando na sua branch antes de subir o código para o repositório:
```
git pull origin dev
git pull origin develop
```
Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:
Depois da execução desse comando é necessário criar uma branch, para isso, execute o seguinte comando:
```
git checkout -b <nomeDaBranch>
```
Assim que criar a branch, é necessário fazer um `push`para garantir que a mesma estará remota:
Assim que criar a branch, é necessário fazer um `git push` para garantir que a mesma estará criada remotamente:
```
git push --set-upstream origin <nomeDaBranch>
......@@ -65,11 +67,11 @@ 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 que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de `commit`, seguido do comando `push`.
#### Salvando Localmente
Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando `add` apenas nos arquivos **essenciais** para a tarefa:
Antes de chamar o `commit`, lembre-se de adicionar os códigos a serem "commitados", desta forma, chame o comando `add` para adicionar os arquivos **essenciais** para a tarefa:
```
git add <nomeDoArquivo>
......@@ -81,7 +83,7 @@ Depois de adicionar todos os arquivos que deseja salvar, execute o commando de c
git commit -m 'descrição da tarefa em português'
```
Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento
Não hesite em realizar vários commits, assim podemos ter documentado e salvo vários estados do desenvolvimento.
#### Salvando Remotamente
......@@ -96,7 +98,8 @@ git push
git pull origin develop
```
Esse comando irá garantir que sua branch esta sincronizada com a branch develop e que não iram surgir conflitos na hora do merge.
Esse comando irá garantir que sua branch esteja sincronizada com a branch develop, evitando conflitos na hora de subir o código para o repositório.
### Merge Requests
Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:
......@@ -124,6 +127,64 @@ Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a fu
Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.
## Convenções de Código
Nos projetos de frontend e backend, foram definidos padrões de código a serem seguidos.
Para auxiliar o programador a manter o código bem organizado, utilizamos as seguintes extensões de IDE:
- Prettier
- Conventional Commits
### Prettier
O [Prettier](https://prettier.io/) é uma ferramenta de formatação de código que permite definir convenções textuais como identação, espaçamento, etc.
As configurações do Prettier foram préviamente definidas no projeto, basta adicionar o Prettier em sua IDE de prefêrencia.
Caso esteja utilizando o VS Code (Visual Studio Code), basta abrir o painel de _Extenções_ com <kbd>Ctrl</kbd> + <kbd>Shift</kbd> + <kbd>x</kbd> , pesquisar por "Prettier" e instalar a extensão.
As configurações do Prettier no VS Code também estão em ambos os repositórios com o nome de `settings.json`. Toda vez que salvar o projeto, com o comando <kbd>Ctrl</kbd> + <kbd>s</kbd>, o editor será salvo e realizará as formatações definidas.
Os códigos que não estiverem respeitando os padrões de formatação, além de possivelmente não compilarem, não devem subir ao repositório.
Configurações definidas:
```
"semi": true --> Adiciona ponto e vírgula no final
"singleQuote": true --> Garante o uso de aspas simples
"tabWidth": 2 --> Tabulações definidas com 2 espaços
"printWidth": 100 --> Define o número máximo de caracteres de uma linha do código
```
### Conventional Commits
O Conventional Commits é um padrão de commit popularmente utilizado na indústria, inicialmente concebido em projetos da Google, [veja mais sobre aqui!](https://www.conventionalcommits.org/en/v1.0.0/)
Nesse projeto, existem ferramentas para facilitar os commits de acordo com as regras estipuladas, basta escrever:
```sh
yarn commit
```
e um menu irá guiar o usuário para realizar o commit da maneira mais adequada.
O processo de commit tradicional, feito pelo comando `git commit` também é permitido neste projeto, desde que respeite as regras acima citadas.
Todos os commits que não respeitarem os padrões de commits previamente definidos, serão rejeitados automaticamente.
### Nomenclatura de Arquivos
A nomenclatura dos arquivos de ambos os projetos, deve respeitar os padrões estipulados pelas arquiteturas dos projetos, ou seja, seguir os padrões e exemplos já estipulados no projeto. Em caso de dúvida, consultar a sessão de [Arquitetura](arquitetura) para maiores informações.
### Documentação das Rotas
Para auxiliar o desenvolvimento e documentação do projeto de backend, fizemos o uso da ferramenta Swagger.
### Swagger
O Swagger é definido como uma aplicação open source que auxilia desenvolvedores nos processos de definir, criar, documentar e consumir APIs REST. Em suma, o Swagger visa padronizar este tipo de integração, descrevendo os recursos que uma API deve possuir, como as rotas dos endpoints, o formato de dados recebidos, dados retornados, códigos HTTP e métodos de autenticação, dentre outros. Para mais informações, acesse este link: [Swagger](https://swagger.io/).
## Matriz de Responsabilidade
Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
......@@ -149,10 +210,10 @@ I: Deve ser informado; C: Deve ser consultado; R: Responsável; A: Aprova
|:------------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-----------:|:--------------------------------:|:-----------------------------------------------------------------------------------:|:----------------------------:|
| 1ª Reunião com o Cliente | Primeiro encontro entre o time e os stakeholders do projeto. Nesse encontro são apresentados os principais itens do projeto e a ideia geral. Também são realizados questionamentos sobre o que foi apresentado, com a finalidade de ajudar nas definições dos requisitos do projeto em conjunto com o cliente. | Cliente(s) | AGES I, II, III, IV e Cliente(s) | Uma vez (início do projeto) | 1 hora - 1 hora e 30 minutos |
| Daily | Cada membro da equipe atualiza os outros sobre o que produziu desde o último encontro síncrono (ou assíncrono via Discord), o que visa fazer em seguida, e se tem obstáculos, com finalidade de que possam ser discutidos e resolvidos. | AGES IV | AGES I, II, III e IV | Uma vez na semana. Síncrona na sexta e Assíncrona usando o canal de check-in | 15 minutos; |
| Sprint Review | Momento em que é apresentado o que foi desenvolvido e revisa-se o trabalho realizado. Esse envento é uma preparação para a Sprint Planning, pois podemos ver o que deu certo e o que precisamos melhorar em conjunto com o cliente. | AGES IV | AGES I, II, III, IV e Cliente(s) | Sempre no final das Sprints. Aproximadamente a cada 3 semanas. | 30 minutos - 1 hora |
| Sprint Review | Momento em que é apresentado o que foi desenvolvido e revisa-se o trabalho realizado. Esse evento é uma preparação para a Sprint Planning, pois podemos ver o que deu certo e o que precisamos melhorar em conjunto com o cliente. | AGES IV | AGES I, II, III, IV e Cliente(s) | Sempre no final das Sprints. Aproximadamente a cada 3 semanas. | 30 minutos - 1 hora |
| Sprint Planning | É realizado o planejamento do que irá ser feito durante a Sprint que se inicia. Realizada a priorização das User Stories que estão no Product Backlog para o Sprint Backlog atual do projeto. | AGES IV | AGES I, II, III e IV | No início das Sprints. Aproximadamente a cada 3 semanas. | 15 minutos - 30 minutos |
| Sprint Retrospective | Momento em que a equipe revisa como foi o processo e o trabalho do time na Sprint. Os membros são incentivados a expor o que gostaram, o que não gostaram, com quem gostaram de trabalhar e qualquer comentário construtivo sobre a Sprint que se encerra. Como output desse encontro, temos itens de ação para aprimorar e melhorar processos que não foram produtivos na Sprint seguinte. | AGES IV | AGES I, II, III e IV | No final das Sprints. Aproximadamente a cada 3 semanas. | 45 minutos - 1 hora |
| Tasks/Squads Planning | Evento realizado pela gerência, com o intuíto de dividir o time em Squads focando produtividade. A divisão é pensada para maximizar desempenho na sprint atual. Após a divisão dos squads, é realizada a quebra das User Stories priorizadas para a Sprint atual em tarefas. Essas tarefas são divididas entre os squads e, consequentemente, entre seus integrantes. As tarefas possuem o menor escopo possível e critérios de aceitação mensusáveis para cada integrante. | AGES IV | AGES IV | No início das Sprints. Aproximadamente a cada 3 semanas. | 1 hora - 1 hora e 30 minutos |
| Tasks/Squads Planning | Evento realizado pela gerência, com o intuito de dividir o time em Squads focando produtividade. A divisão é pensada para maximizar desempenho na sprint atual. Após a divisão dos squads, é realizada a quebra das User Stories priorizadas para a Sprint atual em tarefas. Essas tarefas são divididas entre os squads e, consequentemente, entre seus integrantes. As tarefas possuem o menor escopo possível e critérios de aceitação mensuráveis para cada integrante. | AGES IV | AGES IV | No início das Sprints. Aproximadamente a cada 3 semanas. | 1 hora - 1 hora e 30 minutos |
| Code Review and Deploy Meeting | Reunião para definição dos responsáveis pela revisão de código e para revisão da apresentação final da Sprint. | AGES IV | AGES IV | No final das Sprints, um final de semana antes da entrega. Aproximadamente a cada 3 | 1 hora - 1 hora e 30 minutos |
......@@ -160,8 +221,8 @@ I: Deve ser informado; C: Deve ser consultado; R: Responsável; A: Aprova
| Risco | Prevenção | Contingência | Estratégia |
|:-----------------------------------------------------:|:------------------------------------------------------------------------------------------:|:---------------------------------------------------------------------------------------------:|:----------:|
| Falha na comunicação com steakholds | Manter canal de comunição aberto com steakholders e incentivar comuniação | Revisar documentação e entrar em concenso com o time sobre estratégia a ser adotada | Mitigar |
| Falha na comunicação com stakeholders | Manter canal de comunicação aberto com stakeholders e incentivar comunicação | Revisar documentação e entrar em consenso com o time sobre estratégia a ser adotada | Mitigar |
| Atraso na entrega | Revisar constantemente as tarefas e o andamento dos épicos a cada sprint | Focar esforço no trabalho atrasado | Mitigar |
| Falta de conhecimento nas tecnologias utilizadas | Incentivar estudos dirigidos | Fornecer materias de estudo e realizar pair-programming para balacear conhecimento nas duplas | Mitigar |
| Falta de motivação na equipe | Lideranças devem acompanhar tarefas no trello e verificar constantemente a moral da equipe | Online Party no Discord | Aceitar |
| Falta de conhecimento nas tecnologias utilizadas | Incentivar estudos dirigidos | Fornecer materiais de estudo e realizar pair-programming para balancear conhecimento nas duplas | Mitigar |
| Falta de motivação na equipe | Lideranças devem acompanhar tarefas no Trello e verificar constantemente a moral da equipe | Online Party no Discord | Aceitar |
| Alterações de escopo | Fechar o escopo do projeto com os Stakeholders antes do início do desenvolvimento | Negociar com Stakeholders a troca de itens para não alterar o tamanho do escopo | Mitigar |